#dusk $DUSK Eine Sicherheitspanne offenbart etwas, das eine Roadmap nie kann: wie sich ein Team verhält, wenn das System tatsächlich ausfällt.
Am 16. Januar erlangte ein Angreifer unbefugten Zugriff auf einen Signatur-Wallet, der von Dusk's Bridge-Dienst verwendet wird. Wichtig ist: Laut Dusk's Post-Mortem handelte es sich um eine Kompromittierung eines Bridge-Wallets – nicht um einen Konsensfehler oder um einen Exploit des Kernprotokolls.
Was meine Aufmerksamkeit nicht auf sich zog, war nicht der Vorfall selbst. Es war das, was danach geschah.
Dusk ersetzte das kompromittierte Wallet nicht einfach. Stattdessen überarbeitete Dusk die Bridge-Architektur. Die Signierung wurde von der Ereignisverarbeitung getrennt. Die Freigabe von Geldern wurde von der Ereignisaufnahme entkoppelt. Das neue System nutzt einen expliziten Transaktionslebenszyklus, während die Aussetzung durch Hot-Wallets reduziert und der Bridge-Host gehärtet wurde.
Das ist eine weitaus interessantere Antwort als „Wir haben den Bug gefixt“.
Die Lehre geht über $DUSK hinaus. Bridges waren über Jahre hinweg der am häufigsten ausgenutzte Teil der Krypto-Infrastruktur – genau weil sie so viel wirtschaftliche Autorität an einem einzigen Ort bündeln.
Eine Bridge hat wirtschaftliche Autorität, daher wird ihr operatives Design Teil des Sicherheitsmodells. Wenn ein kompromittierter Schlüssel zu weit reichen kann, ist das Problem nicht nur der Schlüssel. Es ist, wie viel Autorität die Architektur dem Schlüssel von Anfang an gegeben hat.
Für ein Projekt, das auf reguliertes On-Chain-Finance abzielt, ist das besonders relevant. Institutionen werden nicht nur fragen, ob die Infrastruktur unter normalen Bedingungen funktioniert. Sie werden irgendwann fragen, was passiert, wenn etwas schiefgeht.
Genau dort verdient Dusk's Neudesign meiner Meinung nach Aufmerksamkeit.
Sicherheitsaussagen lassen sich leicht veröffentlichen. Die Architektur nach einem Scheitern zu ändern, ist schwieriger.
Würdest du mehr Gewicht darauf legen, wie eine Blockchain nach einem Zwischenfall reagiert, als auf alles, was sie zuvor versprochen hat?
@Dusk_Foundation $DUSK #dusk
$EDEN
Am 16. Januar erlangte ein Angreifer unbefugten Zugriff auf einen Signatur-Wallet, der von Dusk's Bridge-Dienst verwendet wird. Wichtig ist: Laut Dusk's Post-Mortem handelte es sich um eine Kompromittierung eines Bridge-Wallets – nicht um einen Konsensfehler oder um einen Exploit des Kernprotokolls.
Was meine Aufmerksamkeit nicht auf sich zog, war nicht der Vorfall selbst. Es war das, was danach geschah.
Dusk ersetzte das kompromittierte Wallet nicht einfach. Stattdessen überarbeitete Dusk die Bridge-Architektur. Die Signierung wurde von der Ereignisverarbeitung getrennt. Die Freigabe von Geldern wurde von der Ereignisaufnahme entkoppelt. Das neue System nutzt einen expliziten Transaktionslebenszyklus, während die Aussetzung durch Hot-Wallets reduziert und der Bridge-Host gehärtet wurde.
Das ist eine weitaus interessantere Antwort als „Wir haben den Bug gefixt“.
Die Lehre geht über $DUSK hinaus. Bridges waren über Jahre hinweg der am häufigsten ausgenutzte Teil der Krypto-Infrastruktur – genau weil sie so viel wirtschaftliche Autorität an einem einzigen Ort bündeln.
Eine Bridge hat wirtschaftliche Autorität, daher wird ihr operatives Design Teil des Sicherheitsmodells. Wenn ein kompromittierter Schlüssel zu weit reichen kann, ist das Problem nicht nur der Schlüssel. Es ist, wie viel Autorität die Architektur dem Schlüssel von Anfang an gegeben hat.
Für ein Projekt, das auf reguliertes On-Chain-Finance abzielt, ist das besonders relevant. Institutionen werden nicht nur fragen, ob die Infrastruktur unter normalen Bedingungen funktioniert. Sie werden irgendwann fragen, was passiert, wenn etwas schiefgeht.
Genau dort verdient Dusk's Neudesign meiner Meinung nach Aufmerksamkeit.
Sicherheitsaussagen lassen sich leicht veröffentlichen. Die Architektur nach einem Scheitern zu ändern, ist schwieriger.
Würdest du mehr Gewicht darauf legen, wie eine Blockchain nach einem Zwischenfall reagiert, als auf alles, was sie zuvor versprochen hat?
@Dusk_Foundation $DUSK #dusk
$EDEN