Ich lasse auf meinem Laptop in Islamabad ein kleines Python-Skript laufen, das für ein Nebenprojekt aufwendiges Hashing durchführt. Einmal habe ich versucht, es in eine abgeschottete (sandboxed) Umgebung zu verlagern, in der Annahme, es würde genauso schnell laufen, weil sich die Logik ja nicht ändert. Es lief spürbar langsamer, und bis ich über Dusk's Piecrust VM gelesen habe, habe ich auf technischer Ebene nie wirklich verstanden, warum das so passiert.
Ich ging davon aus, dass die Ausführung von Smart Contracts innerhalb einer WASM-virtuellen Maschine ungefähr mit nativer Geschwindigkeit abläuft, weil WASM üblicherweise als nahezu nativer Performance-Standard vermarktet wird.
Das trifft speziell für kryptografische Operationen jedoch nicht zu. In der im Whitepaper zitierten Forschung wird gezeigt, dass die WASM-Ausführung bei komplexen Anwendungen 45 bis 255 Prozent langsamer laufen kann als nativer Code – hauptsächlich aufgrund von virtualisiertem Speicher-Management und zusätzlicher Instruktionsbehandlung innerhalb der Sandbox.
Genau deshalb führt Piecrust auch keine Dinge wie ZK-Proof-Verifikation, Hashing oder Signaturprüfungen überhaupt in der WASM-Sandbox aus. Stattdessen stellt es Host-Funktionen bereit – direkte native Aufrufe für Operationen wie hash, verify_plonk, verify_groth16_bn254, verify_schnorr und verify_bls. Der Contract ruft nativen Code für die aufwendige kryptografische Arbeit auf, und danach kehrt er wieder in WASM zurück, um alles andere zu erledigen. Das ist eine bewusste architektonische Aufteilung, kein Workaround.
Was das Whitepaper ganz offen zugibt, ist, dass Dusk die tatsächlichen Einsparungen an Rechenleistung durch dieses Setup bisher noch nicht quantifiziert hat. Deshalb kann ich dir keine echte Effizienz-Zahl nennen, weil Dusk selbst noch keine veröffentlicht hat.
Der echte Test für DUSK ist, ob dieser Host-Funktion-Ansatz auch dann stabil bleibt, wenn die Vertragskomplexität auf dem Mainnet weiter wächst.
Hat jemand Piecrusts Host-Funktionsaufrufe mit reiner WASM-Ausführung selbst benchmarkt?
@Dusk #dusk $DUSK
Ich ging davon aus, dass die Ausführung von Smart Contracts innerhalb einer WASM-virtuellen Maschine ungefähr mit nativer Geschwindigkeit abläuft, weil WASM üblicherweise als nahezu nativer Performance-Standard vermarktet wird.
Das trifft speziell für kryptografische Operationen jedoch nicht zu. In der im Whitepaper zitierten Forschung wird gezeigt, dass die WASM-Ausführung bei komplexen Anwendungen 45 bis 255 Prozent langsamer laufen kann als nativer Code – hauptsächlich aufgrund von virtualisiertem Speicher-Management und zusätzlicher Instruktionsbehandlung innerhalb der Sandbox.
Genau deshalb führt Piecrust auch keine Dinge wie ZK-Proof-Verifikation, Hashing oder Signaturprüfungen überhaupt in der WASM-Sandbox aus. Stattdessen stellt es Host-Funktionen bereit – direkte native Aufrufe für Operationen wie hash, verify_plonk, verify_groth16_bn254, verify_schnorr und verify_bls. Der Contract ruft nativen Code für die aufwendige kryptografische Arbeit auf, und danach kehrt er wieder in WASM zurück, um alles andere zu erledigen. Das ist eine bewusste architektonische Aufteilung, kein Workaround.
Was das Whitepaper ganz offen zugibt, ist, dass Dusk die tatsächlichen Einsparungen an Rechenleistung durch dieses Setup bisher noch nicht quantifiziert hat. Deshalb kann ich dir keine echte Effizienz-Zahl nennen, weil Dusk selbst noch keine veröffentlicht hat.
Der echte Test für DUSK ist, ob dieser Host-Funktion-Ansatz auch dann stabil bleibt, wenn die Vertragskomplexität auf dem Mainnet weiter wächst.
Hat jemand Piecrusts Host-Funktionsaufrufe mit reiner WASM-Ausführung selbst benchmarkt?
@Dusk #dusk $DUSK
