#dusk $DUSK
Der Ausdruck „Host-Funktionen“ tauchte immer wieder in Dusk’s Whitepaper auf, und ich habe ihn weiterhin als Implementierungsdetail abgetan. Als ich mir dann tatsächlich den Abschnitt zur Performance durchlas, zeigte sich jedoch, dass es sich um eine weitaus bewusstere architektonische Entscheidung handelte.
ZK in einer WASM-VM ausführen: Das Whitepaper verweist auf Forschungsergebnisse, wonach die Ausführung von WASM bei komplexen Anwendungen im Vergleich zu nativen Programmcodes um 45–255 % langsamer sein kann. Der Overhead entsteht durch virtualisiertes Speichermanagement und die zusätzliche Instruktionsabwicklung innerhalb einer gesicherten Sandbox-Umgebung. Für Hashing und Signaturvalidierung ist das lästig. Für die Verifikation von ZK-Beweisen, die bei jeder Transaktion läuft, sind 45–255 % langsamer ein erhebliches Durchsatzproblem.
Host-Funktionen: Dusk stellt eine Reihe von Funktionen bereit, die nativ auf dem Host-System laufen, außerhalb der WASM-Sandbox. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls und hash. Der Smart Contract ruft diese direkt auf; die umfangreiche kryptografische Arbeit läuft mit nativer Geschwindigkeit. Das Ergebnis wird — wie bei jeder anderen Berechnung auch — über die Knoten hinweg repliziert.
Also: Warum macht nicht jede Kette, die ZK nutzt, das?
Wenn man die Berechnung aus der VM heraus verlagert, wird die Zusicherung der Sandbox reduziert. In einem reinen WASM-Ausführungsmodell ist ein fehlerhafter oder bösartiger Vertrag innerhalb der VM-Grenze isoliert. Wenn man Host-Funktionen hinzufügt, macht man nativen Zugriff auf bestimmte Operationen sichtbar — und ein Bug oder eine Fehlkonfiguration auf der Ebene der Host-Funktion könnte Folgen haben, die ein gesandboxter Vertrag allein nicht erzeugen könnte. Man tauscht Isolation gegen Durchsatz.
Ich finde das Argument der Energieeffizienz sogar interessanter als das Geschwindigkeitsargument: Das Whitepaper rahmt Host-Funktionen teilweise als Möglichkeit, die Energiekosten pro Knoten zu senken — nicht nur die Latenz. Das ist eine ungewöhnliche Perspektive für ein Dokument zur Blockchain-Designentscheidung.
Was ich allerdings nicht erklärt gesehen habe, ist, wie Dusk die Versionierung von Host-Funktionen handhabt — also ob eine Änderung im Verhalten einer Host-Funktion eine Protokolländerung darstellt, die Konsens erfordert, oder ob Betreiber Implementierungen unabhängig aktualisieren können. @Dusk
$DUSK #dusk
Der Ausdruck „Host-Funktionen“ tauchte immer wieder in Dusk’s Whitepaper auf, und ich habe ihn weiterhin als Implementierungsdetail abgetan. Als ich mir dann tatsächlich den Abschnitt zur Performance durchlas, zeigte sich jedoch, dass es sich um eine weitaus bewusstere architektonische Entscheidung handelte.
ZK in einer WASM-VM ausführen: Das Whitepaper verweist auf Forschungsergebnisse, wonach die Ausführung von WASM bei komplexen Anwendungen im Vergleich zu nativen Programmcodes um 45–255 % langsamer sein kann. Der Overhead entsteht durch virtualisiertes Speichermanagement und die zusätzliche Instruktionsabwicklung innerhalb einer gesicherten Sandbox-Umgebung. Für Hashing und Signaturvalidierung ist das lästig. Für die Verifikation von ZK-Beweisen, die bei jeder Transaktion läuft, sind 45–255 % langsamer ein erhebliches Durchsatzproblem.
Host-Funktionen: Dusk stellt eine Reihe von Funktionen bereit, die nativ auf dem Host-System laufen, außerhalb der WASM-Sandbox. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls und hash. Der Smart Contract ruft diese direkt auf; die umfangreiche kryptografische Arbeit läuft mit nativer Geschwindigkeit. Das Ergebnis wird — wie bei jeder anderen Berechnung auch — über die Knoten hinweg repliziert.
Also: Warum macht nicht jede Kette, die ZK nutzt, das?
Wenn man die Berechnung aus der VM heraus verlagert, wird die Zusicherung der Sandbox reduziert. In einem reinen WASM-Ausführungsmodell ist ein fehlerhafter oder bösartiger Vertrag innerhalb der VM-Grenze isoliert. Wenn man Host-Funktionen hinzufügt, macht man nativen Zugriff auf bestimmte Operationen sichtbar — und ein Bug oder eine Fehlkonfiguration auf der Ebene der Host-Funktion könnte Folgen haben, die ein gesandboxter Vertrag allein nicht erzeugen könnte. Man tauscht Isolation gegen Durchsatz.
Ich finde das Argument der Energieeffizienz sogar interessanter als das Geschwindigkeitsargument: Das Whitepaper rahmt Host-Funktionen teilweise als Möglichkeit, die Energiekosten pro Knoten zu senken — nicht nur die Latenz. Das ist eine ungewöhnliche Perspektive für ein Dokument zur Blockchain-Designentscheidung.
Was ich allerdings nicht erklärt gesehen habe, ist, wie Dusk die Versionierung von Host-Funktionen handhabt — also ob eine Änderung im Verhalten einer Host-Funktion eine Protokolländerung darstellt, die Konsens erfordert, oder ob Betreiber Implementierungen unabhängig aktualisieren können. @Dusk
$DUSK #dusk
