#dusk $DUSK
Ich dachte, Piecrust, die virtuelle Maschine von Dusk, wäre nur dafür da, Smart Contracts auszuführen. Das ist doch die gleiche Aufgabe, die jede VM übernimmt – Code ausführen, Zustand beibehalten, fertig. Tatsächlich ist das vielleicht nur die Hälfte dessen, wofür sie da ist.
Beim Durchstöbern der Dokumentation habe ich gesehen, dass Piecrust eine Reihe von Host-Funktionen bereitstellt.
Operationen, die die VM an nativen Code übergibt, statt sie innerhalb der sandboxierten WASM-Umgebung auszuführen.
Hashing, über Blake2b und Poseidon.
Verifizieren von PlonK- und Groth16-Zero-Knowledge-Beweisen.
Validieren von Schnorr- und BLS-Signaturen.
Nichts davon läuft als regulärer Contract-Bytecode.
Warum würde eine VM sich extra darum kümmern, bestimmte Operationen an sich selbst vorbei zu routen, statt einfach alles auf dem normalen Weg auszuführen?
Turns out: WASM-Ausführung kann bei rechenintensiven Operationen 45–255% langsamer sein als nativer Code. Die Mehrausgaben entstehen durch virtualisiertes Speicher-Management und die zusätzliche Instruktionsbehandlung, die eine Sandbox-Umgebung mit sich bringt.
Für eine Chain, bei der ZK-Beweissprüfung nicht gelegentlich vorkommt, sondern im Grunde bei jeder Transaktion stattfindet, ist es keine kleine Abgabe, diese Mathematik nicht nativ, sondern in WASM laufen zu lassen.
Es addiert sich, Block für Block.
Dieses gleiche Prinzip gilt direkt für DuskEVM: die EVM-kompatible Schicht, die Solidity-Entwickler zu Dusk bringt.
Hedger, sein vertrauliches Ausführungsmodul, stützt sich auf homomorphe Verschlüsselung plus ZK-Beweise, um Transaktionen privat zu halten; nichts davon ist schnell genug, um wirklich ins Gewicht zu fallen, ohne dass die nativen Host-Funktionen darunter zuerst die schwere Arbeit übernehmen.
So ist Piecrust nicht nur der Ort, an dem Contracts ausgeführt werden. Es ist auch eine Schnellspur für genau die kryptografischen Operationen @Dusk , auf die am meisten angewiesen wird — bewusst aus dem langsamen Pfad herausgehalten — und genau diese Schnellspur macht die Privacy-Layer von DuskEVM überhaupt erst realisierbar, nicht nur für Dusk-native Contracts.
Das lässt mich fragen: Wie viele andere "Allzweck"-VMs fressen still und heimlich eine Beweis-Verifizierungs-Abgabe, die niemand je wirklich gemessen hat?
Ich dachte, Piecrust, die virtuelle Maschine von Dusk, wäre nur dafür da, Smart Contracts auszuführen. Das ist doch die gleiche Aufgabe, die jede VM übernimmt – Code ausführen, Zustand beibehalten, fertig. Tatsächlich ist das vielleicht nur die Hälfte dessen, wofür sie da ist.
Beim Durchstöbern der Dokumentation habe ich gesehen, dass Piecrust eine Reihe von Host-Funktionen bereitstellt.
Operationen, die die VM an nativen Code übergibt, statt sie innerhalb der sandboxierten WASM-Umgebung auszuführen.
Hashing, über Blake2b und Poseidon.
Verifizieren von PlonK- und Groth16-Zero-Knowledge-Beweisen.
Validieren von Schnorr- und BLS-Signaturen.
Nichts davon läuft als regulärer Contract-Bytecode.
Warum würde eine VM sich extra darum kümmern, bestimmte Operationen an sich selbst vorbei zu routen, statt einfach alles auf dem normalen Weg auszuführen?
Turns out: WASM-Ausführung kann bei rechenintensiven Operationen 45–255% langsamer sein als nativer Code. Die Mehrausgaben entstehen durch virtualisiertes Speicher-Management und die zusätzliche Instruktionsbehandlung, die eine Sandbox-Umgebung mit sich bringt.
Für eine Chain, bei der ZK-Beweissprüfung nicht gelegentlich vorkommt, sondern im Grunde bei jeder Transaktion stattfindet, ist es keine kleine Abgabe, diese Mathematik nicht nativ, sondern in WASM laufen zu lassen.
Es addiert sich, Block für Block.
Dieses gleiche Prinzip gilt direkt für DuskEVM: die EVM-kompatible Schicht, die Solidity-Entwickler zu Dusk bringt.
Hedger, sein vertrauliches Ausführungsmodul, stützt sich auf homomorphe Verschlüsselung plus ZK-Beweise, um Transaktionen privat zu halten; nichts davon ist schnell genug, um wirklich ins Gewicht zu fallen, ohne dass die nativen Host-Funktionen darunter zuerst die schwere Arbeit übernehmen.
So ist Piecrust nicht nur der Ort, an dem Contracts ausgeführt werden. Es ist auch eine Schnellspur für genau die kryptografischen Operationen @Dusk , auf die am meisten angewiesen wird — bewusst aus dem langsamen Pfad herausgehalten — und genau diese Schnellspur macht die Privacy-Layer von DuskEVM überhaupt erst realisierbar, nicht nur für Dusk-native Contracts.
Das lässt mich fragen: Wie viele andere "Allzweck"-VMs fressen still und heimlich eine Beweis-Verifizierungs-Abgabe, die niemand je wirklich gemessen hat?
