Die Nacht war still, also öffnete ich die Brückenbekanntmachung von Dusk aus dem Januar erneut. Das Monitoring hatte eine ungewöhnliche Aktivität rund um eine teamverwaltete Wallet gemeldet; die Services wurden angehalten, und es waren keine Benutzerfonds betroffen.
Dann las ich das März-Post-Mortem.
Die Sprache wurde schwerer: Eine Signing-Wallet war kompromittiert, 10,91 Millionen DUSK wurden über vier Überweisungen entwendet,.....und ein Teil wurde vor dem Shutdown zur BSC überbrückt, bevor ein weiterer Versuch von 8,91 Millionen blockiert wurde.
Die Schlussfolgerung„Dusk wurde nicht gehackt“ ist technisch vertretbar, lässt sich aber leicht überlesen. DuskDS setzte weiterhin gültige Transaktionen in die endgültige Ausführung. Es konnte nicht wissen, dass diese gültigen Signaturen von jemandem stammten, der die operative Schlüsselrolle nicht kontrollieren dürfte.
Es prüfte die Transaktion, nicht die Legitimität des Zugriffs des Signierers.
Das löscht den Wert von DuskDS nicht......Konsens und Finalität schienen gehalten zu haben. Aber die Bridge konzentrierte die wirtschaftliche Autorität in einer einzigen Signing-Wallet und einem operativen Pfad; die Kryptografie stand neben gewöhnlicher Schlüsselverwahrung, Monitoring und Reaktion.
Ich dachte, das wäre nur eine Sprache für die Architektur. Unter Druck wird daraus die Verlustgrenze.
Das ist nicht einzigartig für Dusk. Trotzdem: Wenn ein kompromittierter Operator-Key protocolgültige Transfers erzeugen kann, sollte „kein Protokollproblem“ die erste Formulierung oder nur eine einzige Schicht davon sein?
Die Charts sind noch immer flach. Dieser Satz ist es nicht mehr.
@Dusk $DUSK #dusk
Dann las ich das März-Post-Mortem.
Die Sprache wurde schwerer: Eine Signing-Wallet war kompromittiert, 10,91 Millionen DUSK wurden über vier Überweisungen entwendet,.....und ein Teil wurde vor dem Shutdown zur BSC überbrückt, bevor ein weiterer Versuch von 8,91 Millionen blockiert wurde.
Die Schlussfolgerung„Dusk wurde nicht gehackt“ ist technisch vertretbar, lässt sich aber leicht überlesen. DuskDS setzte weiterhin gültige Transaktionen in die endgültige Ausführung. Es konnte nicht wissen, dass diese gültigen Signaturen von jemandem stammten, der die operative Schlüsselrolle nicht kontrollieren dürfte.
Es prüfte die Transaktion, nicht die Legitimität des Zugriffs des Signierers.
Das löscht den Wert von DuskDS nicht......Konsens und Finalität schienen gehalten zu haben. Aber die Bridge konzentrierte die wirtschaftliche Autorität in einer einzigen Signing-Wallet und einem operativen Pfad; die Kryptografie stand neben gewöhnlicher Schlüsselverwahrung, Monitoring und Reaktion.
Ich dachte, das wäre nur eine Sprache für die Architektur. Unter Druck wird daraus die Verlustgrenze.
Das ist nicht einzigartig für Dusk. Trotzdem: Wenn ein kompromittierter Operator-Key protocolgültige Transfers erzeugen kann, sollte „kein Protokollproblem“ die erste Formulierung oder nur eine einzige Schicht davon sein?
Die Charts sind noch immer flach. Dieser Satz ist es nicht mehr.
@Dusk $DUSK #dusk
