@Dusk
Somewhere in Piecrust's design is a quiet admission that the sandbox isn't the right place for everything.
Contracts run as WebAssembly, which gives the VM its controlled execution environment.
What's interesting is how much of the heavy work never touches that WASM environment at all.
Hashing gets computed natively.
So does ZK proof verification, both PlonK and Groth16.
Signature checks too, Schnorr and BLS.
None of that runs inside the sandbox executing the contract.
The reason is a number, and it's a rough one.
Research Dusk cites puts WASM somewhere between 45 and 255 percent slower than native code once the operations get complex. Cryptographic verification is exactly the kind of work where that difference matters.
Running that penalty on every transaction wasn't a trade Dusk was willing to make, so those operations are handled through native host functions instead.
Here's what got me.
The operations that get pulled out aren't random.
Hashing, proof verification, signatures. that's much of the cryptographic machinery privacy-heavy applications like Phoenix and Zedger depend on.
The sandbox handles the contract logic.
The privacy math runs somewhere else.
So there isn't really one execution boundary here. There's the general VM boundary, and then there are deliberate exits for the operations where native execution matters most.
What I still want to understand is what keeps that native path deterministic across every node. WASM gives you a very explicit execution environment; once a contract calls outside it, what guarantees that every node still arrives at exactly the same result?
$DUSK gets more interesting to me once that question has a real answer behind it, not just a native function doing the work faster.
#dusk
Somewhere in Piecrust's design is a quiet admission that the sandbox isn't the right place for everything.
Contracts run as WebAssembly, which gives the VM its controlled execution environment.
What's interesting is how much of the heavy work never touches that WASM environment at all.
Hashing gets computed natively.
So does ZK proof verification, both PlonK and Groth16.
Signature checks too, Schnorr and BLS.
None of that runs inside the sandbox executing the contract.
The reason is a number, and it's a rough one.
Research Dusk cites puts WASM somewhere between 45 and 255 percent slower than native code once the operations get complex. Cryptographic verification is exactly the kind of work where that difference matters.
Running that penalty on every transaction wasn't a trade Dusk was willing to make, so those operations are handled through native host functions instead.
Here's what got me.
The operations that get pulled out aren't random.
Hashing, proof verification, signatures. that's much of the cryptographic machinery privacy-heavy applications like Phoenix and Zedger depend on.
The sandbox handles the contract logic.
The privacy math runs somewhere else.
So there isn't really one execution boundary here. There's the general VM boundary, and then there are deliberate exits for the operations where native execution matters most.
What I still want to understand is what keeps that native path deterministic across every node. WASM gives you a very explicit execution environment; once a contract calls outside it, what guarantees that every node still arrives at exactly the same result?
$DUSK gets more interesting to me once that question has a real answer behind it, not just a native function doing the work faster.
#dusk
