#dusk $DUSK @Dusk
‎
‎Ich habe den kryptografischen Verifikationspfad von Dusk mit dem verglichen, was eine vollständig abgesicherte Alternative erfordern würde, seit „moved outside WASM“ in vielen der Texte, die ich gelesen habe, ohne viel numerische Grundlage behauptet wird.
‎
‎Dusk-eigene Materialien bestätigen, dass Piecrust Hashing, PLONK-Verification, Groth16-Verification und Signatur-Checks als Host-Funktionen offenlegt — nativer Code, den die Laufzeit direkt aufruft und der für diese spezifischen Operationen die WASM-Virtual-Machine vollständig umgeht. Separat habe ich herausgefunden, dass Phoenix speziell eine Variante einer doppelten Schnorr-Signatur verwendet, die in Dusk's eigenem Repository als neuartiger Beitrag beschrieben wird: Sie delegiert die Beweisberechnung, ohne den geheimen Schlüssel des Signierers offenzulegen — das heißt, nicht nur die ZK-Beweis-Ebene, sondern auch die Signatur-Ebene selbst wurde so gebaut, dass sie diesen nativen Pfad nutzt.
‎
‎Rechnet man aus, was innerhalb von WASM bleibt und was nicht. Allgemeine Vertragslogik — zustandsbezogene Änderungen, Business-Regeln — läuft im Sandbox-Modus. Jede kryptografische Primitive, von der eine Phoenix-Transaktion tatsächlich abhängt, läuft dagegen nativ.
‎
‎Das ist jedoch immer noch eine Hypothese, die man präzise so formulieren sollte: Ich habe keinen veröffentlichten Benchmark-Prozentsatz gefunden, der speziell quantifiziert, wie viel langsamer die Phoenix-Validierung laufen würde, wenn diese Checks innerhalb von WASM blieben statt als Host-Funktionen in Dusk's aktueller Konfiguration auszuführen.
‎
‎Was sich bei meinem Lesen geändert hat: Ich hatte angenommen, dass das reine eine Optimierungsentscheidung ist. Es ist aber auch eine Sicherheitsgrenzen-Entscheidung — nativer Code bringt andere Angriffsflächen mit sich als Sandboxed-WASM-Code, die allein durch die Performance-Einordnung nicht erfasst werden.