Ein einziges Vault-Konzept, das nur davon ausgeht, dass Nutzer jederzeit online sein und jederzeit signieren können, setzt stillschweigend eine unrealistische Voraussetzung: Der Vermögensinhaber wird niemals verschwinden.
Langfristige BTC-Halter könnten ihre Geräte wechseln, ihre Schlüssel verlieren oder aufgrund plötzlicher Umstände vorübergehend nicht in der Lage sein, ihre Vermögenswerte zu verwalten. In so einem Fall darf das System die Kontrolle nicht ohne Weiteres an Dritte übergeben – und es darf auch nicht zulassen, dass BTC für immer in einem Zustand bleibt, in dem niemand sie bedienen kann.
Deshalb denke ich, während ich mir <t-2/> @BabylonLabs_io bei der Erforschung von TBV anschaue, auch darüber nach, wie ein Wiederherstellungsmechanismus gestaltet sein sollte. Können Nutzer im Voraus Ersatzbedingungen festlegen? Muss der Wiederherstellungsprozess über eine ausreichend lange Wartezeit verfügen? Wenn der ursprüngliche Inhaber wieder auftaucht, gibt es dann noch die Möglichkeit, eine nicht erwartete Ausführung zu verhindern? Diese Regeln sollten klar definiert werden, bevor das Vermögen in das Vault gelangt – nicht erst, wenn Probleme auftreten und man sie dann ad hoc festlegt.
Für die Ecosystem <c-1/> #baby ist Wiederherstellungsfähigkeit ebenso wichtig wie die tägliche Nutzung. Eine zu großzügig gestaltete Wiederherstellungsroute würde Self-Custody schwächen; eine Wiederherstellungsmöglichkeit, die es vollständig nicht gibt, könnte dazu führen, dass ein einmaliges Versehen zu einem permanenten Verlust wird.
Der sinnvollere Ansatz besteht darin, dass Nutzer ihre Sicherheitsgrenzen im Voraus selbst definieren: Wer darf Wiederherstellung beantragen, welche Nachweise sind erforderlich und nach wie viel Zeit die Gültigkeit eintritt.
Wenn die zugehörigen Anwendungen <t-2/> $BABY zunehmend langfristige Vermögenswerte tragen, muss das System nicht nur beantworten, „wer kontrolliert aktuell BTC“, sondern auch: „Wie kann die Kontrolle sicher weitergeführt werden, wenn der ursprüngliche Inhaber nicht in der Lage ist, zu handeln“.
Langfristige BTC-Halter könnten ihre Geräte wechseln, ihre Schlüssel verlieren oder aufgrund plötzlicher Umstände vorübergehend nicht in der Lage sein, ihre Vermögenswerte zu verwalten. In so einem Fall darf das System die Kontrolle nicht ohne Weiteres an Dritte übergeben – und es darf auch nicht zulassen, dass BTC für immer in einem Zustand bleibt, in dem niemand sie bedienen kann.
Deshalb denke ich, während ich mir <t-2/> @BabylonLabs_io bei der Erforschung von TBV anschaue, auch darüber nach, wie ein Wiederherstellungsmechanismus gestaltet sein sollte. Können Nutzer im Voraus Ersatzbedingungen festlegen? Muss der Wiederherstellungsprozess über eine ausreichend lange Wartezeit verfügen? Wenn der ursprüngliche Inhaber wieder auftaucht, gibt es dann noch die Möglichkeit, eine nicht erwartete Ausführung zu verhindern? Diese Regeln sollten klar definiert werden, bevor das Vermögen in das Vault gelangt – nicht erst, wenn Probleme auftreten und man sie dann ad hoc festlegt.
Für die Ecosystem <c-1/> #baby ist Wiederherstellungsfähigkeit ebenso wichtig wie die tägliche Nutzung. Eine zu großzügig gestaltete Wiederherstellungsroute würde Self-Custody schwächen; eine Wiederherstellungsmöglichkeit, die es vollständig nicht gibt, könnte dazu führen, dass ein einmaliges Versehen zu einem permanenten Verlust wird.
Der sinnvollere Ansatz besteht darin, dass Nutzer ihre Sicherheitsgrenzen im Voraus selbst definieren: Wer darf Wiederherstellung beantragen, welche Nachweise sind erforderlich und nach wie viel Zeit die Gültigkeit eintritt.
Wenn die zugehörigen Anwendungen <t-2/> $BABY zunehmend langfristige Vermögenswerte tragen, muss das System nicht nur beantworten, „wer kontrolliert aktuell BTC“, sondern auch: „Wie kann die Kontrolle sicher weitergeführt werden, wenn der ursprüngliche Inhaber nicht in der Lage ist, zu handeln“.