#dusk $DUSK @Dusk
Warum die Verifikationsprüfung das Sandbox-Limit für Geschwindigkeit verließ
Ich habe Dusk's kryptografischen-Verifikationspfad mit dem verglichen, was eine vollständig sandboxed-Alternative erfordern würde, seit „moved outside WASM“ in den meisten Artikeln gelesen wird, ohne dass dabei eine solide numerische Grundlage geliefert wird.
Die eigenen Unterlagen von Dusk bestätigen, dass Piecrust Hashing, PLONK-Verification, Groth16-Verification und Signaturprüfungen als Host-Funktionen verfügbar macht — nativer Code, den die Laufzeit für diese speziellen Operationen direkt aufruft und dabei die WASM-Virtual Machine vollständig umgeht. Zusätzlich habe ich herausgefunden, dass Phoenix speziell eine Variante einer doppelten Schnorr-Signatur verwendet, die im eigenen Repository von Dusk als neuartige Einführung beschrieben wird, welche die Proof-Berechnung delegiert, ohne den geheimen Schlüssel des Signierers offenzulegen — das bedeutet, dass nicht nur die ZK-Proof-Ebene, sondern auch die Signatur-Schicht so aufgebaut wurde, dass sie über diesen nativen Pfad läuft.
Rechnen wir aus, was in WASM bleibt und was nicht. Allgemeine Vertragslogik — Statusänderungen, Business-Regeln — läuft sandboxed. Jede kryptografische Grundoperation, von der eine Phoenix-Transaktion tatsächlich abhängt, läuft nativ.
Das ist weiterhin eine Hypothese, die man präzise formulieren sollte: Ich habe keinen veröffentlichten Benchmark-Prozentsatz gefunden, der konkret quantifiziert, wie viel langsamer die Phoenix-Verifikation laufen würde, wenn diese Prüfungen innerhalb von WASM blieben, statt als Host-Funktionen in Dusk's aktueller Konfiguration ausgeführt zu werden.
Was sich in meinem Leseeindruck geändert hat: Ich hatte angenommen, dass das eine reine Optimierungsentscheidung ist. Es ist aber auch eine Sicherheitsgrenzen-Entscheidung — nativer Code hat andere Angriffsflächen-Eigenschaften als sandboxed-WASM-Code, die allein durch die Leistungsrahmung nicht erfasst werden.
Warum die Verifikationsprüfung das Sandbox-Limit für Geschwindigkeit verließ
Ich habe Dusk's kryptografischen-Verifikationspfad mit dem verglichen, was eine vollständig sandboxed-Alternative erfordern würde, seit „moved outside WASM“ in den meisten Artikeln gelesen wird, ohne dass dabei eine solide numerische Grundlage geliefert wird.
Die eigenen Unterlagen von Dusk bestätigen, dass Piecrust Hashing, PLONK-Verification, Groth16-Verification und Signaturprüfungen als Host-Funktionen verfügbar macht — nativer Code, den die Laufzeit für diese speziellen Operationen direkt aufruft und dabei die WASM-Virtual Machine vollständig umgeht. Zusätzlich habe ich herausgefunden, dass Phoenix speziell eine Variante einer doppelten Schnorr-Signatur verwendet, die im eigenen Repository von Dusk als neuartige Einführung beschrieben wird, welche die Proof-Berechnung delegiert, ohne den geheimen Schlüssel des Signierers offenzulegen — das bedeutet, dass nicht nur die ZK-Proof-Ebene, sondern auch die Signatur-Schicht so aufgebaut wurde, dass sie über diesen nativen Pfad läuft.
Rechnen wir aus, was in WASM bleibt und was nicht. Allgemeine Vertragslogik — Statusänderungen, Business-Regeln — läuft sandboxed. Jede kryptografische Grundoperation, von der eine Phoenix-Transaktion tatsächlich abhängt, läuft nativ.
Das ist weiterhin eine Hypothese, die man präzise formulieren sollte: Ich habe keinen veröffentlichten Benchmark-Prozentsatz gefunden, der konkret quantifiziert, wie viel langsamer die Phoenix-Verifikation laufen würde, wenn diese Prüfungen innerhalb von WASM blieben, statt als Host-Funktionen in Dusk's aktueller Konfiguration ausgeführt zu werden.
Was sich in meinem Leseeindruck geändert hat: Ich hatte angenommen, dass das eine reine Optimierungsentscheidung ist. Es ist aber auch eine Sicherheitsgrenzen-Entscheidung — nativer Code hat andere Angriffsflächen-Eigenschaften als sandboxed-WASM-Code, die allein durch die Leistungsrahmung nicht erfasst werden.
Pure optimization
0%
Also a security tradeoff
0%
0 Stimmen • Abstimmung beendet