Es gab eine Zeit, in der ich fast 6 Stunden damit verbracht habe, einen Stapel im Stil einer Production-Review durchzugehen: Ich öffnete nur die Release Notes und protokollierte HTTP-Request-Body, WebSocket-Frames, GraphQL-Queries, das Node-Verhalten und die Stellen, die zu Missbrauch von Ressourcen führen könnten … je mehr ich las, desto mehr wurde mir klar, wie sich Sicherheit in den kleinsten Details zeigt.
Ich ging von Rusk v1.6 zu Rusk v1.7 über: Hard Fork, Protokoll-Upgrade, VM-Funktionen und Transaktionsformat – denn ein Audit-Bericht kann beim Signieren zwar korrekt gewesen sein, aber die Software kann sich nach ein paar Releases unterscheiden.
Dann ordnete ich PLONK, BLS, Hash-Review, Phoenix, Piecrust, Kadcast und Rusk-Konsens neben DuskEVM … ein Core-L1-Audit ist eine Sache, während OP-Stack-Ausführung, Batch-Submission an DuskDS, Fault Proof, Cross-Layer-Bridge, zentralisierter Sequencer und Hedger zusätzliches Angriffsflächen eröffnen.
Ehrlich gesagt vertraue ich der Fehlerbehandlung mehr als der Anzahl der Reports.
Wenn der Sequencer für 20 Minuten ausfällt: Wie fällt der Bridge-Contract zurück? Wer kontrolliert den Upgrade-Key? Welches Beweissystem schützt die Produktionsversion?
Ich verwende eine einfache Prüfung: Audit-Abdeckung = (Anzahl der Produktionskomponenten mit Audit-Zuordnung / Gesamtzahl der Produktionskomponenten) * 100.
2024 und 2026 liegen 2 Jahre auseinander, aber mit VM-Features, Migrations-Contract, ERC20 und BEP20 können 2 Jahre mehrere Generationen von Annahmen bedeuten.
DuskEVM Mainnet und Testnet sollten nicht unter dem Wort „auditiert“ zusammengefasst werden – wenn die bereitgestellte Version unterschiedlich ist, ist auch der Audit-Umfang unterschiedlich!
Ich achte auf Request-Limits, weil homomorphe Verschlüsselung und ZK sehr ausgefeilt sein können, aber eine unbegrenzte GraphQL-Query kann Ressourcen immer noch auf sehr gewöhnliche Weise zum Absturz bringen.
die beste Sicherheit für mich ist nicht ein System, das niemals fehlschlägt, sondern eines, das weiß, wo es fehlschlägt, wie man zurückrollt und wie viele ungeklärte Probleme noch offen sind.
Wenn du dich zwischen einem „auditierten“ Badge und einer klar aktualisierten Liste von Produktionskomponenten, bereitgestellter Version, Auditbericht, ungelösten Issues … entscheiden müsstest: Wem würdest du eher vertrauen?
#dusk $DUSK @Dusk
Ich ging von Rusk v1.6 zu Rusk v1.7 über: Hard Fork, Protokoll-Upgrade, VM-Funktionen und Transaktionsformat – denn ein Audit-Bericht kann beim Signieren zwar korrekt gewesen sein, aber die Software kann sich nach ein paar Releases unterscheiden.
Dann ordnete ich PLONK, BLS, Hash-Review, Phoenix, Piecrust, Kadcast und Rusk-Konsens neben DuskEVM … ein Core-L1-Audit ist eine Sache, während OP-Stack-Ausführung, Batch-Submission an DuskDS, Fault Proof, Cross-Layer-Bridge, zentralisierter Sequencer und Hedger zusätzliches Angriffsflächen eröffnen.
Ehrlich gesagt vertraue ich der Fehlerbehandlung mehr als der Anzahl der Reports.
Wenn der Sequencer für 20 Minuten ausfällt: Wie fällt der Bridge-Contract zurück? Wer kontrolliert den Upgrade-Key? Welches Beweissystem schützt die Produktionsversion?
Ich verwende eine einfache Prüfung: Audit-Abdeckung = (Anzahl der Produktionskomponenten mit Audit-Zuordnung / Gesamtzahl der Produktionskomponenten) * 100.
2024 und 2026 liegen 2 Jahre auseinander, aber mit VM-Features, Migrations-Contract, ERC20 und BEP20 können 2 Jahre mehrere Generationen von Annahmen bedeuten.
DuskEVM Mainnet und Testnet sollten nicht unter dem Wort „auditiert“ zusammengefasst werden – wenn die bereitgestellte Version unterschiedlich ist, ist auch der Audit-Umfang unterschiedlich!
Ich achte auf Request-Limits, weil homomorphe Verschlüsselung und ZK sehr ausgefeilt sein können, aber eine unbegrenzte GraphQL-Query kann Ressourcen immer noch auf sehr gewöhnliche Weise zum Absturz bringen.
die beste Sicherheit für mich ist nicht ein System, das niemals fehlschlägt, sondern eines, das weiß, wo es fehlschlägt, wie man zurückrollt und wie viele ungeklärte Probleme noch offen sind.
Wenn du dich zwischen einem „auditierten“ Badge und einer klar aktualisierten Liste von Produktionskomponenten, bereitgestellter Version, Auditbericht, ungelösten Issues … entscheiden müsstest: Wem würdest du eher vertrauen?
#dusk $DUSK @Dusk
