Nehmen wir an, der Notfall-Schlüssel gerät in falsche Hände: Was ist dann das schlimmste Szenario—wird BTC umgeleitet, oder bleibt eine reguläre Zahlung einfach hängen? Wenn man bei Trustless Bitcoin Vaults (TBV) ein Threat Modeling durchführt, lassen sich die Ergebnisse in ein Drei-Felder-Handlungsformular eintragen.
Im Feld „Asset Loss“ kommt es zuerst auf das Auszahlungsskript an. Das Ziel bestehender Vaults ist bei der Erstellung festgelegt und umfasst nur die Depositor-Adresse oder die Adresse eines Liquidation-Arbitrageurs; der Security-Council-Schlüssel gehört nicht zur Empfängermenge. Wenn man das Council kontrolliert, kann man nicht einfach einen neuen Empfänger „herbeizaubern“ und auch keine ursprüngliche Adresse durch die Angreiferadresse ersetzen.
Im Feld „Service Interruption“ kann man jedoch nicht „keine“ eintragen. Das Council ist in der Lage, Payouts zu verhindern. Probleme mit dem Notfall-Schlüssel führen daher zu einem echten Liveness-Effekt: Die Coins werden nicht von ihm eingesammelt; das bedeutet aber nicht, dass Nutzer ihren Ausstieg wie geplant durchführen können. Diese Art von Schaden sollte als Ereignis der Verfügbarkeit behandelt werden, nicht durch das Unumadressieren von Assets verschleiert.
Im Feld „Condition Exposure“ müssen außerdem die übrigen Abhängigkeiten aufgeführt werden. TBV reduziert zwar das Risiko von Custodians und Bridges, verwendet aber weiterhin Ethereum-Verträge, Oracles, ZK/BABE, sowie eine Cross-Chain-Validierungs-Pipeline und es bestehen Anforderungen an Governance und Betreiberverfügbarkeit. Nicht alles davon fällt unter das Council, aber es beeinflusst dennoch, ob die Bedingungen wie vorgesehen erfüllt werden können.
Die zeitliche Reihenfolge lautet daher: Beim Erstellen die Empfänger-Menge prüfen; bei einem Ereignis bewerten, ob Payouts blockiert werden; und bei fortgesetzter Abwicklung die Beweise, Verträge und Betriebsbedingungen verifizieren. Die drei Felder entsprechen drei Arten von Konsequenzen und sollten nicht zu dem Satz „Mehrere Signaturen, also Treuhand“ zusammengezogen werden.
Dieses Formular liefert am Ende nur begrenzte Schlussfolgerungen: Der Notfallzugriff kann zu einer Dienstunterbrechung führen, und daraus lässt sich kein Anspruch auf Umadressierung ableiten. Die Asset-Seite ist eingeschränkt, und daraus kann man auch nicht behaupten, dass das System vollständig nicht von Governance beeinflusst wird. Indem man die schlechtesten Ergebnisse in Kategorien aufteilt, weiß man erst, ob man sich gegen Diebstahl oder gegen Stillstand schützen sollte.
@BabylonLabs_io $BABY #baby
Im Feld „Asset Loss“ kommt es zuerst auf das Auszahlungsskript an. Das Ziel bestehender Vaults ist bei der Erstellung festgelegt und umfasst nur die Depositor-Adresse oder die Adresse eines Liquidation-Arbitrageurs; der Security-Council-Schlüssel gehört nicht zur Empfängermenge. Wenn man das Council kontrolliert, kann man nicht einfach einen neuen Empfänger „herbeizaubern“ und auch keine ursprüngliche Adresse durch die Angreiferadresse ersetzen.
Im Feld „Service Interruption“ kann man jedoch nicht „keine“ eintragen. Das Council ist in der Lage, Payouts zu verhindern. Probleme mit dem Notfall-Schlüssel führen daher zu einem echten Liveness-Effekt: Die Coins werden nicht von ihm eingesammelt; das bedeutet aber nicht, dass Nutzer ihren Ausstieg wie geplant durchführen können. Diese Art von Schaden sollte als Ereignis der Verfügbarkeit behandelt werden, nicht durch das Unumadressieren von Assets verschleiert.
Im Feld „Condition Exposure“ müssen außerdem die übrigen Abhängigkeiten aufgeführt werden. TBV reduziert zwar das Risiko von Custodians und Bridges, verwendet aber weiterhin Ethereum-Verträge, Oracles, ZK/BABE, sowie eine Cross-Chain-Validierungs-Pipeline und es bestehen Anforderungen an Governance und Betreiberverfügbarkeit. Nicht alles davon fällt unter das Council, aber es beeinflusst dennoch, ob die Bedingungen wie vorgesehen erfüllt werden können.
Die zeitliche Reihenfolge lautet daher: Beim Erstellen die Empfänger-Menge prüfen; bei einem Ereignis bewerten, ob Payouts blockiert werden; und bei fortgesetzter Abwicklung die Beweise, Verträge und Betriebsbedingungen verifizieren. Die drei Felder entsprechen drei Arten von Konsequenzen und sollten nicht zu dem Satz „Mehrere Signaturen, also Treuhand“ zusammengezogen werden.
Dieses Formular liefert am Ende nur begrenzte Schlussfolgerungen: Der Notfallzugriff kann zu einer Dienstunterbrechung führen, und daraus lässt sich kein Anspruch auf Umadressierung ableiten. Die Asset-Seite ist eingeschränkt, und daraus kann man auch nicht behaupten, dass das System vollständig nicht von Governance beeinflusst wird. Indem man die schlechtesten Ergebnisse in Kategorien aufteilt, weiß man erst, ob man sich gegen Diebstahl oder gegen Stillstand schützen sollte.
@BabylonLabs_io $BABY #baby