Der Wert von Piecrust liegt nicht nur im „Support von WASM“
Wer „Support von WASM“ als den gesamten Wert von Piecrust betrachtet, ist etwa so, als würde man ein Auto nur als „etwas verstehen, das Räder aufnehmen kann“. Als ich das Whitepaper und offizielle Architekturartikel von Dusk gegengeprüft habe, sehe ich zwei klare Grenzen: Der Vertrag muss in einer reproduzierbaren, isolierten Umgebung laufen, und die kryptografische Schwerarbeit darf nicht vollständig auf normales WASM ausgelagert werden, das man nicht langsam „Stück für Stück“ berechnen lässt.
Piecrust ist in Rust geschrieben, basiert auf dem Wasmer-WASM-Runtime und stellt eine leichte, modulare Ausführungsumgebung für Verträge bereit. WASM bringt Portabilität, Sandbox-Isolation und modulare Erweiterbarkeit; das piecrust-crate übernimmt die VM, piecrust-uplink unterstützt das Kompilieren, Bereitstellen, Testen und Verwalten von Verträgen.
Doch die kryptografische Schwerarbeit wird nicht vollständig an WASM übergeben. Das Whitepaper verlagert Blake2b, Poseidon, Plonk-Validierung, Groth16 BN254-Validierung sowie Schnorr- und BLS-Signaturvalidierung in „host functions“. Die VM überlässt dabei die kostspielige Arbeit einer nativen Implementierung außerhalb der VM. Der Vertrag steuert den Ausführungsablauf, während native Libraries die rechenintensiven Berechnungen übernehmen. So entstehen Vorteile in Bezug auf Performance und Sicherheitsgrenzen – allerdings verlangt das, dass Schnittstellen, Eingaben/Ausgaben, Fehlerbehandlung und Determinismus streng festgelegt sind, sonst können verschiedene Knoten zu unterschiedlichen Ergebnissen kommen.
@Dusk $DUSK #dusk
Auch die Daten müssen mit Vorsicht gelesen werden. Laut den Vergleichen im Whitepaper kann die WASM-Ausführung bei komplexen Anwendungen gegenüber nativen Codes um etwa 45%–255% langsamer sein. Das bedeutet nicht, dass alle WASM-Verträge so stark langsamer werden, und lässt sich nicht einfach in einen Durchsatzgewinn für das Dusk-Mainnet umrechnen; das Whitepaper räumt außerdem ein, dass der Energieeffizienzgewinn durch host functions damals noch nicht konkret quantifiziert war.
Außerdem bezeichnet die aktuelle offizielle Dokumentation die Umgebung, in der direkt Rust/WASM-Verträge ausgeführt werden, als DuskVM und beschreibt sie als auf Wasmtime basierend. Piecrust entspricht eher der Namensgebung in den Whitepapern und frühen Architekturmaterialien. An dieser Stelle wird klar: Der Wert von Piecrust ist nicht einfach „WASM unterstützen“, sondern das saubere Management der Trennung zwischen reproduzierbarer Ausführung und kryptografischen Hochkostenberechnungen.
Wer „Support von WASM“ als den gesamten Wert von Piecrust betrachtet, ist etwa so, als würde man ein Auto nur als „etwas verstehen, das Räder aufnehmen kann“. Als ich das Whitepaper und offizielle Architekturartikel von Dusk gegengeprüft habe, sehe ich zwei klare Grenzen: Der Vertrag muss in einer reproduzierbaren, isolierten Umgebung laufen, und die kryptografische Schwerarbeit darf nicht vollständig auf normales WASM ausgelagert werden, das man nicht langsam „Stück für Stück“ berechnen lässt.
Piecrust ist in Rust geschrieben, basiert auf dem Wasmer-WASM-Runtime und stellt eine leichte, modulare Ausführungsumgebung für Verträge bereit. WASM bringt Portabilität, Sandbox-Isolation und modulare Erweiterbarkeit; das piecrust-crate übernimmt die VM, piecrust-uplink unterstützt das Kompilieren, Bereitstellen, Testen und Verwalten von Verträgen.
Doch die kryptografische Schwerarbeit wird nicht vollständig an WASM übergeben. Das Whitepaper verlagert Blake2b, Poseidon, Plonk-Validierung, Groth16 BN254-Validierung sowie Schnorr- und BLS-Signaturvalidierung in „host functions“. Die VM überlässt dabei die kostspielige Arbeit einer nativen Implementierung außerhalb der VM. Der Vertrag steuert den Ausführungsablauf, während native Libraries die rechenintensiven Berechnungen übernehmen. So entstehen Vorteile in Bezug auf Performance und Sicherheitsgrenzen – allerdings verlangt das, dass Schnittstellen, Eingaben/Ausgaben, Fehlerbehandlung und Determinismus streng festgelegt sind, sonst können verschiedene Knoten zu unterschiedlichen Ergebnissen kommen.
@Dusk $DUSK #dusk
Auch die Daten müssen mit Vorsicht gelesen werden. Laut den Vergleichen im Whitepaper kann die WASM-Ausführung bei komplexen Anwendungen gegenüber nativen Codes um etwa 45%–255% langsamer sein. Das bedeutet nicht, dass alle WASM-Verträge so stark langsamer werden, und lässt sich nicht einfach in einen Durchsatzgewinn für das Dusk-Mainnet umrechnen; das Whitepaper räumt außerdem ein, dass der Energieeffizienzgewinn durch host functions damals noch nicht konkret quantifiziert war.
Außerdem bezeichnet die aktuelle offizielle Dokumentation die Umgebung, in der direkt Rust/WASM-Verträge ausgeführt werden, als DuskVM und beschreibt sie als auf Wasmtime basierend. Piecrust entspricht eher der Namensgebung in den Whitepapern und frühen Architekturmaterialien. An dieser Stelle wird klar: Der Wert von Piecrust ist nicht einfach „WASM unterstützen“, sondern das saubere Management der Trennung zwischen reproduzierbarer Ausführung und kryptografischen Hochkostenberechnungen.
