#dusk $DUSK @Dusk
Eine Sache an Dusk’s Piecrust-VM hat meine Aufmerksamkeit erregt:
Warum sollte man WASM alles übernehmen lassen, wenn manche Operationen eindeutig außerhalb davon besser aufgehoben sind?
Zunächst klingt es so, als wäre es der sicherere und sauberere Ansatz, alles in der Sandbox zu belassen.
Doch dann betrachtet man, was ein Smart Contract tatsächlich leisten muss.
Hashing.
ZK-Proof-Verifikation.
Schnorr-Signaturen.
BLS-Signaturen.
Das sind keine leichten Operationen.
Wenn man all das innerhalb von WASM ausführt, kann das eine Menge unnötigen Overhead verursachen – vor allem, wenn jeder Knoten dieselbe Arbeit wiederholen muss.
Genau hier werden die Host-Funktionen von Piecrust interessant.
Anstatt den Contract zu zwingen, teure Kryptografie innerhalb von WASM auszuführen, können ausgewählte Operationen an nativen Code übergeben werden.
Der Contract bleibt in der Sandbox.
Die aufwendige kryptografische Arbeit wird näher an native Geschwindigkeit verlagert.
Für mich ist das ein deutlich praktikablerer Ansatz, um über das Design einer VM nachzudenken.
Man muss nicht unbedingt alles in der Sandbox lassen.
Man braucht nur die richtigen Dinge dort.
Allerdings gibt es einen Kompromiss.
Entwickler erhalten weniger Freiheit, völlig benutzerdefinierte kryptografische Operationen einzubauen. Neue Primitiven brauchen Unterstützung auf VM-Ebene.
Aber wenn die unterstützten Operationen deterministisch sind und sich über alle Knoten hinweg identisch verhalten, ergibt dieser Kompromiss deutlich mehr Sinn.
Vielleicht wählt Piecrust also gar nicht wirklich zwischen WASM- und nativer Ausführung.
Es entscheidet lediglich, wo jede Art von Berechnung am meisten Sinn ergibt.
Und ehrlich gesagt, das wirkt wie der spannendere Teil des Designs.
Würdest du Priorität auf maximale Flexibilität für Contracts legen oder auf schnellere Ausführung bei kryptografieintensiven Workloads?
$NEIRO
$ENA
Eine Sache an Dusk’s Piecrust-VM hat meine Aufmerksamkeit erregt:
Warum sollte man WASM alles übernehmen lassen, wenn manche Operationen eindeutig außerhalb davon besser aufgehoben sind?
Zunächst klingt es so, als wäre es der sicherere und sauberere Ansatz, alles in der Sandbox zu belassen.
Doch dann betrachtet man, was ein Smart Contract tatsächlich leisten muss.
Hashing.
ZK-Proof-Verifikation.
Schnorr-Signaturen.
BLS-Signaturen.
Das sind keine leichten Operationen.
Wenn man all das innerhalb von WASM ausführt, kann das eine Menge unnötigen Overhead verursachen – vor allem, wenn jeder Knoten dieselbe Arbeit wiederholen muss.
Genau hier werden die Host-Funktionen von Piecrust interessant.
Anstatt den Contract zu zwingen, teure Kryptografie innerhalb von WASM auszuführen, können ausgewählte Operationen an nativen Code übergeben werden.
Der Contract bleibt in der Sandbox.
Die aufwendige kryptografische Arbeit wird näher an native Geschwindigkeit verlagert.
Für mich ist das ein deutlich praktikablerer Ansatz, um über das Design einer VM nachzudenken.
Man muss nicht unbedingt alles in der Sandbox lassen.
Man braucht nur die richtigen Dinge dort.
Allerdings gibt es einen Kompromiss.
Entwickler erhalten weniger Freiheit, völlig benutzerdefinierte kryptografische Operationen einzubauen. Neue Primitiven brauchen Unterstützung auf VM-Ebene.
Aber wenn die unterstützten Operationen deterministisch sind und sich über alle Knoten hinweg identisch verhalten, ergibt dieser Kompromiss deutlich mehr Sinn.
Vielleicht wählt Piecrust also gar nicht wirklich zwischen WASM- und nativer Ausführung.
Es entscheidet lediglich, wo jede Art von Berechnung am meisten Sinn ergibt.
Und ehrlich gesagt, das wirkt wie der spannendere Teil des Designs.
Würdest du Priorität auf maximale Flexibilität für Contracts legen oder auf schnellere Ausführung bei kryptografieintensiven Workloads?
$NEIRO
$ENA