@Dusk
Irgenwo im Design von Piecrust steckt ein stilles Eingeständnis, dass die Sandbox nicht der richtige Ort für alles ist.
Contracts laufen als WebAssembly, wodurch die VM ihre kontrollierte Ausführungsumgebung erhält.
Spannend ist, wie viel von der schweren Arbeit diese WASM-Umgebung überhaupt nicht berührt.
Hashing wird nativ berechnet.
Das gilt auch für die ZK-Überprüfung, sowohl für PlonK als auch für Groth16.
Auch Signaturprüfungen, Schnorr und BLS.
Nichts davon läuft in der Sandbox, während der Contract ausgeführt wird.
Der Grund dafür ist eine Zahl – und eine grobe.
Research Dusk verweist darauf, dass WASM irgendwo zwischen 45 und 255 Prozent langsamer als nativer Code ist, sobald die Operationen komplex werden. Krypto-Verifikation ist genau die Art von Arbeit, bei der dieser Unterschied entscheidend ist.
Diesen Malus bei jeder Transaktion in Kauf zu nehmen, war kein Trade, den Dusk eingehen wollte – deshalb werden diese Operationen stattdessen über native Host-Funktionen abgewickelt.
Das hat mich aufhorchen lassen.
Die Operationen, die herausgezogen werden, sind nicht zufällig.
Hashing, Proof-Verifikation, Signaturen. Das ist ein großer Teil des kryptografischen Mechanismus, auf den privacy-lastige Anwendungen wie Phoenix und Zedger angewiesen sind.
Die Sandbox übernimmt die Contract-Logik.
Die Privacy-Mathematik läuft woanders.
Es gibt also nicht wirklich eine einzige Ausführungsgrenze. Da ist die allgemeine VM-Grenze – und dann gibt es gezielte Ausstiege für die Operationen, bei denen native Ausführung am wichtigsten ist.
Was ich allerdings noch verstehen möchte, ist, was diesen nativen Pfad über jeden Node hinweg deterministisch hält. WASM gibt dir eine sehr explizite Ausführungsumgebung. Sobald ein Contract außerhalb davon aufruft, was garantiert dann, dass jeder Node am Ende immer noch exakt dasselbe Ergebnis erhält?
$DUSK wird für mich noch interessanter, sobald diese Frage eine echte Antwort hat – nicht nur eine native Funktion, die die Arbeit schneller erledigt.
#dusk
Irgenwo im Design von Piecrust steckt ein stilles Eingeständnis, dass die Sandbox nicht der richtige Ort für alles ist.
Contracts laufen als WebAssembly, wodurch die VM ihre kontrollierte Ausführungsumgebung erhält.
Spannend ist, wie viel von der schweren Arbeit diese WASM-Umgebung überhaupt nicht berührt.
Hashing wird nativ berechnet.
Das gilt auch für die ZK-Überprüfung, sowohl für PlonK als auch für Groth16.
Auch Signaturprüfungen, Schnorr und BLS.
Nichts davon läuft in der Sandbox, während der Contract ausgeführt wird.
Der Grund dafür ist eine Zahl – und eine grobe.
Research Dusk verweist darauf, dass WASM irgendwo zwischen 45 und 255 Prozent langsamer als nativer Code ist, sobald die Operationen komplex werden. Krypto-Verifikation ist genau die Art von Arbeit, bei der dieser Unterschied entscheidend ist.
Diesen Malus bei jeder Transaktion in Kauf zu nehmen, war kein Trade, den Dusk eingehen wollte – deshalb werden diese Operationen stattdessen über native Host-Funktionen abgewickelt.
Das hat mich aufhorchen lassen.
Die Operationen, die herausgezogen werden, sind nicht zufällig.
Hashing, Proof-Verifikation, Signaturen. Das ist ein großer Teil des kryptografischen Mechanismus, auf den privacy-lastige Anwendungen wie Phoenix und Zedger angewiesen sind.
Die Sandbox übernimmt die Contract-Logik.
Die Privacy-Mathematik läuft woanders.
Es gibt also nicht wirklich eine einzige Ausführungsgrenze. Da ist die allgemeine VM-Grenze – und dann gibt es gezielte Ausstiege für die Operationen, bei denen native Ausführung am wichtigsten ist.
Was ich allerdings noch verstehen möchte, ist, was diesen nativen Pfad über jeden Node hinweg deterministisch hält. WASM gibt dir eine sehr explizite Ausführungsumgebung. Sobald ein Contract außerhalb davon aufruft, was garantiert dann, dass jeder Node am Ende immer noch exakt dasselbe Ergebnis erhält?
$DUSK wird für mich noch interessanter, sobald diese Frage eine echte Antwort hat – nicht nur eine native Funktion, die die Arbeit schneller erledigt.
#dusk
