#dusk $DUSK @Dusk
Lies diese Woche zweimal den Abschnitt zur Implementierung des Whitepapers. Beim ersten Durchgang bin ich an dem Teil zu den „Host-Funktionen“ einfach vorbeigerutscht und habe angenommen, es handle sich nur um eine technische Randnotiz dazu, wie die VM gebaut ist. Beim zweiten Durchgang hat diese Annahme nicht mehr gehalten.
Ich hatte „Smart Contracts laufen in einer VM“ und „Kryptografische Operationen laufen in einer VM“ als dieselbe Aussage behandelt. Das sind sie nicht, und die Lücke zwischen beiden ist tatsächlich die interessante Designentscheidung.
Piecrust, Dusks VM, führt Contracts in WebAssembly aus. Aber sie führt nicht die eigentliche kryptografische Schwerarbeit — Hashing, ZK-Proof-Verifikation, Signaturprüfungen — innerhalb dieser WASM-Sandbox aus. Diese Aufgaben werden herausgezogen und nativ vom Host erledigt, über freigelegte Funktionen wie verify_plonk und verify_groth16_bn254. Der Contract ruft diese Funktionen auf, aber die teure Mathematik berührt nie die virtualisierte Umgebung.
So kommt man darauf, warum das keine bloße Nebensache in der Implementierung ist. Die im Whitepaper zitierte Forschung zur WASM-Ausführung zeigt, dass virtualisierter Code bei komplexen Operationen 45–255 % langsamer laufen kann als nativer Code — der Overhead ist in die Art und Weise eingebaut, wie sandboxierter Speicher und Instruktionen funktionieren, nicht etwas, das man wegoptimieren könnte.
So würden also Confidential Transactions, die sich für im Grunde alles auf ZK-Proof-Verifikation stützen, diese „Steuer“ bei jeder einzelnen Transaktion zahlen, wenn die Verifikation innerhalb der VM liefe wie ein normaler Contract-Call.
Genau das verbindet sich zurück mit dem Datenschutzdesign. Programmierbarer Datenschutz ist nicht nur eine kryptografische Entscheidung, sondern auch eine Performance-Einschränkung — wenn Proof-Verifikation langsam ist, wird „privat und regelkonform“ still und leise zu „privat und regelkonform, irgendwann“. Kryptografie aus den Host-Funktionen herauszuziehen ist das, was verhindert, dass Datenschutz zur Belastung auf jeder einzelnen Transaktion wird, statt eine Eigenschaft davon zu sein.
Hat irgendjemand hier tatsächlich die echten Zahlen von Piecrust in der Praxis benchmarkt, oder beruht „vermeidet WASM-Overhead“ immer noch auf der allgemeinen, im Whitepaper zitierten Forschung statt auf duskspezifischen Daten?"
Lies diese Woche zweimal den Abschnitt zur Implementierung des Whitepapers. Beim ersten Durchgang bin ich an dem Teil zu den „Host-Funktionen“ einfach vorbeigerutscht und habe angenommen, es handle sich nur um eine technische Randnotiz dazu, wie die VM gebaut ist. Beim zweiten Durchgang hat diese Annahme nicht mehr gehalten.
Ich hatte „Smart Contracts laufen in einer VM“ und „Kryptografische Operationen laufen in einer VM“ als dieselbe Aussage behandelt. Das sind sie nicht, und die Lücke zwischen beiden ist tatsächlich die interessante Designentscheidung.
Piecrust, Dusks VM, führt Contracts in WebAssembly aus. Aber sie führt nicht die eigentliche kryptografische Schwerarbeit — Hashing, ZK-Proof-Verifikation, Signaturprüfungen — innerhalb dieser WASM-Sandbox aus. Diese Aufgaben werden herausgezogen und nativ vom Host erledigt, über freigelegte Funktionen wie verify_plonk und verify_groth16_bn254. Der Contract ruft diese Funktionen auf, aber die teure Mathematik berührt nie die virtualisierte Umgebung.
So kommt man darauf, warum das keine bloße Nebensache in der Implementierung ist. Die im Whitepaper zitierte Forschung zur WASM-Ausführung zeigt, dass virtualisierter Code bei komplexen Operationen 45–255 % langsamer laufen kann als nativer Code — der Overhead ist in die Art und Weise eingebaut, wie sandboxierter Speicher und Instruktionen funktionieren, nicht etwas, das man wegoptimieren könnte.
So würden also Confidential Transactions, die sich für im Grunde alles auf ZK-Proof-Verifikation stützen, diese „Steuer“ bei jeder einzelnen Transaktion zahlen, wenn die Verifikation innerhalb der VM liefe wie ein normaler Contract-Call.
Genau das verbindet sich zurück mit dem Datenschutzdesign. Programmierbarer Datenschutz ist nicht nur eine kryptografische Entscheidung, sondern auch eine Performance-Einschränkung — wenn Proof-Verifikation langsam ist, wird „privat und regelkonform“ still und leise zu „privat und regelkonform, irgendwann“. Kryptografie aus den Host-Funktionen herauszuziehen ist das, was verhindert, dass Datenschutz zur Belastung auf jeder einzelnen Transaktion wird, statt eine Eigenschaft davon zu sein.
Hat irgendjemand hier tatsächlich die echten Zahlen von Piecrust in der Praxis benchmarkt, oder beruht „vermeidet WASM-Overhead“ immer noch auf der allgemeinen, im Whitepaper zitierten Forschung statt auf duskspezifischen Daten?"
