Kinders ins Bett gebracht ist schon halb zwölf, ich will für die restliche halbe Stunde nicht aufs Handy schauen. Ich habe kurz in Dusk in den Dokumenten der Execution-Layer gestöbert. Eigentlich wollte ich nur mal eben reinschauen und dann schlafen, aber ich bin an einem Detail hängen geblieben und bin nicht eingeschlafen.

Piecrust ist die virtuelle Maschine für Smart Contracts in Dusk, basiert auf WASM – das ist bei vielen neuen öffentlichen Ketten ähnlich und nicht wirklich etwas Besonderes. Das Besondere liegt darin, wie sie kryptografische Berechnungen behandeln: Rechenintensive Dinge wie Hashes oder die Verifikation von Zero-Knowledge-Beweisen werden nicht an WASM-Bytecode übergeben, um sie laufen zu lassen, sondern als Host-Funktionen umgesetzt. Diese rufen dann direkt die zugrunde liegende Rust-Implementierung auf, um die Berechnungen durchzuführen. Der Contract-Code läuft also ganz normal in der VM-Sandbox, aber sobald es zu schweren kryptografischen Berechnungen kommt, springt man aus der Sandbox heraus und übergibt an nativen Code – das Ergebnis wird danach wieder zurück in die VM übertragen.

Diese Aufteilung wirkt auf den ersten Blick wie eine reine Optimierung der Technik, aber bei genauerem Hinsehen ist sie zwingend so. Wenn man die Zero-Knowledge-Beweis-Verifikation in einer interpretierenden virtuellen Maschine laufen lässt, ist der Performance-Verlust im Vergleich um Größenordnungen größer – vor allem bei einer Kette wie Dusk, die standardmäßig über einen kryptografischen Transaktionspfad läuft. Dann muss fast jede Transaktion diese Verifikation durchlaufen; wenn das bremst, wird der Durchsatz der gesamten Kette direkt abgewürgt. Den ressourcenintensivsten Teil aus der Sandbox herauszuholen und stattdessen nativ zu laufen, ist im Kern ein Kompromiss zwischen „Contract-Turing-Vollständigkeit“ und „Privacy Computing darf die Performance nicht zerstören“.

Woran ich festhänge, ist: Wer definiert die Schnittstellen dieser Host-Funktionen, und kann das in Zukunft erweitert werden? Wenn man für jedes neue kryptografische Primitive den VM-Backend-Code ändern müsste, dann wären die Arten von Privacy-Primitiven, die Entwickler nutzen können, in gewissem Maß durch den Update-Rhythmus des Kernteams eingeschränkt. Das wäre nicht offen für eine freie Weiterentwicklung im Ökosystem. Das widerspricht eigentlich ein bisschen dem Narrativ von öffentlichen Ketten: „Turing-vollständig, Entwickler können frei entfalten“ – nur ist dieser Widerspruch unten in der Tiefe versteckt, sodass man ihn im Alltag kaum spürt.

Und dann hatte ich keine Lust mehr, weiter zu blättern. Ich merke es mir erst einmal und suche später eine Gelegenheit, um zu prüfen, wie weit die Host-Funktionen wirklich offen sind.

Wie seht ihr das: Wenn man die wichtigsten kryptografischen Berechnungen aus der Sandbox herausnimmt und nativen Code laufen lässt – diese „Performance zuerst“-Entscheidung – ist der Preis dann am Ende nicht größer, als es auf den ersten Blick scheint?

@Dusk #dusk $DUSK