#dusk $DUSK @Dusk I anfangs dachte ich, dass Sicherheits-Audits vor allem dazu dienen, vor dem Launch einen formalen Stempel der Zustimmung zu bekommen. Je genauer ich mir Dusk angesehen habe, desto fragwürdiger wurde diese Annahme. Seine Audits decken sehr unterschiedliche Ebenen ab – von Konsens und Networking bis hin zur Piecrust-VM, dem PLONK-Beweisverfahren und Token-Contracts. Die Ergebnisse fließen dabei in die Entwicklung zurück, statt lediglich in Berichten zu enden.

Was meine Aufmerksamkeit geweckt hat, war, wie konkret manche dieser Erkenntnisse sind. Frühere PLONK-Forschung hatte herausgefunden, dass öffentliche Inputs nicht korrekt in den Proof-Hash einbezogen wurden, was einen Weg zu gefälschten Beweisen eröffnete. Die Korrektur war zwar technisch, aber konzeptionell relativ einfach: diese öffentlichen Inputs in den Hashing-Prozess einbinden.

Ich begann zu denken, dass der eigentliche Wert externer Sicherheitsarbeit darin liegt, nicht Perfektion zu beweisen, sondern Annahmen sichtbar zu machen, die Entwickler möglicherweise übersehen.

Das ist wichtig, weil Blockchain-Sicherheit selten nur von einem einzigen Smart Contract abhängt. Eine Schwäche in der Ausführung, im Konsens, in der Kryptografie oder in der Infrastruktur kann ganz unterschiedliche Arten von Ausfällen verursachen, während koordinierte Offenlegung und wiederholte Überprüfung dem Entwicklungsprozess zusätzlich Kosten und Zeit auferlegen.

Auch die Bug-Bounty-Frage ist interessant. Dusk hatte zuvor eingeräumt, dass es noch kein Bounty-Programm gibt. Spätere Sicherheitsarbeiten und die öffentliche Audit-Berichterstattung zeigen jedoch eine breitere Ausrichtung auf kontinuierliche Prüfung.

Für ein Netzwerk, das auf regulierte Finanzanwendungen abzielt, denke ich, dass diese Denkweise entscheidend ist. Aber Audits bleiben Momentaufnahmen – keine Garantien. Die reale Nutzung, die Akzeptanz, zukünftige Upgrades und der Druck eines laufenden Mainnets werden letztlich testen, wie belastbar Dusk’ Sicherheits-These wirklich ist.