Ich habe mir dieses Jahr den Cross-Chain-Bridge-Review zur @Dusk erneut durchgesehen. Am lohnendsten ist dabei nicht die zwei Wörter „gestohlen“, sondern wo genau der Fehler passiert ist: Am 16. Januar lag das Problem bei der Signatur-Wallet, die vom Brücken-Service genutzt wird. Nachdem der Angreifer die Ausleih-/Auszahlungsrechte erhalten hatte, hat er Assets von der Dusk-Seite abgezogen und einen Teil anschließend nach BSC geschickt.
Offiziell heißt es klar, dass das weder ein Konsens-Fehler war noch dass die L1-Protokolle „durchbrochen“ wurden.
Aber das heißt nicht, dass die darunterliegende Kette in Ordnung ist und Nutzer das Brückenrisiko ignorieren sollten. Die alte Architektur bündelte Ereignisannahme, Signierung und Mittel-Freigabe in einem einzigen Pfad. Das ist schnell – aber wenn der Signier-Teil kompromittiert wird, ist die Rechteverteilung viel zu konzentriert. Der spätere Relaunch hat drei Dinge getrennt: Erst wird das Ereignis als Aufgabe abgelegt, dann verarbeitet ein Worker nach einem Zustandsautomaten; die signierten Original-Transaktionen werden zuerst gespeichert, und bei einem Fehlschlag wird derselbe Vorgang erneut ausgeführt. Die Hot-Wallet behält nur die für den kurzen Zeitraum nötigen Beträge – fällt sie unter einen Schwellenwert, wird pausiert, und die Cold-Wallet wird manuell nachgefüllt.
Früher bin ich auch leicht darauf hereingefallen, die Brücke sei „kein Protokoll“ und deshalb eine Art Entschuldigungsformel. Heute sehe ich das lieber umgekehrt: Wenn Nutzer sie als Einstieg für Liquidität betrachten, befindet sich die Brücke bereits an der realen Sicherheitsgrenze von $DUSK . On-Chain-Konsens-Sicherheit und Sicherheit an den Ein- und Ausgängen von Vermögenswerten sind zwei Paar Prüfungsbögen, die beide bestehen müssen.
Die Richtung der Gegenmaßnahmen ist richtig – aber die Risikopunkte sind nicht verschwunden: Es muss weiterhin genau beobachtet werden, ob die Schlüssel-Isolation dauerhaft umgesetzt wird, ob die Schwellenwerte sinnvoll sind und ob das Stoppen sowie das Nachfüllen auditierbar sind. #dusk sollte die Community vor allem nicht fragen „Ob die Kette gehackt wurde“, sondern „Welche Taste/Schlüssel hält noch immer mehr Macht als unbedingt erforderlich“. Wenn ihr euch Cross-Chain-Brücken anschaut: Seht ihr zuerst den Code-Audit, oder zuerst, wie die Betriebs-/Berechtigungsrollen sauber getrennt und umgeschaltet werden?
$TREE $ETH
Offiziell heißt es klar, dass das weder ein Konsens-Fehler war noch dass die L1-Protokolle „durchbrochen“ wurden.
Aber das heißt nicht, dass die darunterliegende Kette in Ordnung ist und Nutzer das Brückenrisiko ignorieren sollten. Die alte Architektur bündelte Ereignisannahme, Signierung und Mittel-Freigabe in einem einzigen Pfad. Das ist schnell – aber wenn der Signier-Teil kompromittiert wird, ist die Rechteverteilung viel zu konzentriert. Der spätere Relaunch hat drei Dinge getrennt: Erst wird das Ereignis als Aufgabe abgelegt, dann verarbeitet ein Worker nach einem Zustandsautomaten; die signierten Original-Transaktionen werden zuerst gespeichert, und bei einem Fehlschlag wird derselbe Vorgang erneut ausgeführt. Die Hot-Wallet behält nur die für den kurzen Zeitraum nötigen Beträge – fällt sie unter einen Schwellenwert, wird pausiert, und die Cold-Wallet wird manuell nachgefüllt.
Früher bin ich auch leicht darauf hereingefallen, die Brücke sei „kein Protokoll“ und deshalb eine Art Entschuldigungsformel. Heute sehe ich das lieber umgekehrt: Wenn Nutzer sie als Einstieg für Liquidität betrachten, befindet sich die Brücke bereits an der realen Sicherheitsgrenze von $DUSK . On-Chain-Konsens-Sicherheit und Sicherheit an den Ein- und Ausgängen von Vermögenswerten sind zwei Paar Prüfungsbögen, die beide bestehen müssen.
Die Richtung der Gegenmaßnahmen ist richtig – aber die Risikopunkte sind nicht verschwunden: Es muss weiterhin genau beobachtet werden, ob die Schlüssel-Isolation dauerhaft umgesetzt wird, ob die Schwellenwerte sinnvoll sind und ob das Stoppen sowie das Nachfüllen auditierbar sind. #dusk sollte die Community vor allem nicht fragen „Ob die Kette gehackt wurde“, sondern „Welche Taste/Schlüssel hält noch immer mehr Macht als unbedingt erforderlich“. Wenn ihr euch Cross-Chain-Brücken anschaut: Seht ihr zuerst den Code-Audit, oder zuerst, wie die Betriebs-/Berechtigungsrollen sauber getrennt und umgeschaltet werden?
$TREE $ETH
