#dusk $DUSK @Dusk
Warum die Verifikationsprüfung das Sandbox-Umfeld für Tempo verließ
Ich habe Dusk’ kryptografischen-Verifikations-Pfad mit dem verglichen, was eine vollständig sandboxed Alternative erfordern würde, seit „moved outside WASM“ in vielen der Stellen, die ich gelesen habe, ohne viel numerische Grundlage behauptet wird.
Dusk’ eigene Unterlagen bestätigen, dass Piecrust Hashing, PLONK-Verifikation, Groth16-Verifikation und Signaturprüfungen als Host-Funktionen bereitstellt — nativer Code, den die Laufzeit direkt aufruft und der diese spezifischen Operationen vollständig am WASM-Virtual-Machine-Kern vorbeiführt. Separat fand ich, dass Phoenix konkret eine Variante einer doppelten-Schnorr-Signatur verwendet, die in Dusk’ eigener Repository als neuartige Einführung beschrieben wird: Sie delegiert die Beweisberechnung, ohne den geheimen Schlüssel des Signierers offenzulegen — das heißt, selbst die Signatur-Ebene, nicht nur die ZK-Beweis-Ebene, wurde so gebaut, dass sie über diesen nativen Pfad läuft.
Rechnen wir aus, was innerhalb von WASM bleibt und was nicht. Allgemeine Vertragslogik — Zustandsänderungen, Geschäftsregeln — läuft sandboxed. Jede kryptografische Grundoperation, von der eine Phoenix-Transaktion tatsächlich abhängt, läuft nativerseits.
Das ist jedoch immer noch eine Hypothese, die es präzise zu formulieren gilt: Ich habe keine veröffentlichte Benchmark-Quote gefunden, die speziell quantifiziert, wie viel langsamer die Phoenix-Verifikation wäre, wenn diese Checks innerhalb von WASM blieben, statt als Host-Funktionen in Dusk’ aktueller Konfiguration zu laufen.
Was sich in meinem Leseeindruck geändert hat: Ich hatte angenommen, dass dies rein eine Optimierungsentscheidung ist. Es ist auch eine Sicherheits-Grenzentscheidung — nativer Code trägt andere Angriffsfächen-Eigenschaften als sandboxed-WASM-Code, die allein durch die Performance-Rahmung nicht erfasst werden.
Warum die Verifikationsprüfung das Sandbox-Umfeld für Tempo verließ
Ich habe Dusk’ kryptografischen-Verifikations-Pfad mit dem verglichen, was eine vollständig sandboxed Alternative erfordern würde, seit „moved outside WASM“ in vielen der Stellen, die ich gelesen habe, ohne viel numerische Grundlage behauptet wird.
Dusk’ eigene Unterlagen bestätigen, dass Piecrust Hashing, PLONK-Verifikation, Groth16-Verifikation und Signaturprüfungen als Host-Funktionen bereitstellt — nativer Code, den die Laufzeit direkt aufruft und der diese spezifischen Operationen vollständig am WASM-Virtual-Machine-Kern vorbeiführt. Separat fand ich, dass Phoenix konkret eine Variante einer doppelten-Schnorr-Signatur verwendet, die in Dusk’ eigener Repository als neuartige Einführung beschrieben wird: Sie delegiert die Beweisberechnung, ohne den geheimen Schlüssel des Signierers offenzulegen — das heißt, selbst die Signatur-Ebene, nicht nur die ZK-Beweis-Ebene, wurde so gebaut, dass sie über diesen nativen Pfad läuft.
Rechnen wir aus, was innerhalb von WASM bleibt und was nicht. Allgemeine Vertragslogik — Zustandsänderungen, Geschäftsregeln — läuft sandboxed. Jede kryptografische Grundoperation, von der eine Phoenix-Transaktion tatsächlich abhängt, läuft nativerseits.
Das ist jedoch immer noch eine Hypothese, die es präzise zu formulieren gilt: Ich habe keine veröffentlichte Benchmark-Quote gefunden, die speziell quantifiziert, wie viel langsamer die Phoenix-Verifikation wäre, wenn diese Checks innerhalb von WASM blieben, statt als Host-Funktionen in Dusk’ aktueller Konfiguration zu laufen.
Was sich in meinem Leseeindruck geändert hat: Ich hatte angenommen, dass dies rein eine Optimierungsentscheidung ist. Es ist auch eine Sicherheits-Grenzentscheidung — nativer Code trägt andere Angriffsfächen-Eigenschaften als sandboxed-WASM-Code, die allein durch die Performance-Rahmung nicht erfasst werden.
Pure optimization
0%
Also a security tradeoff
0%
0 Stimmen • Abstimmung beendet