I run a small Python script on my laptop in Islamabad that does heavy hashing for a side project, and I once tried moving it into a sandboxed environment thinking it would run just as fast since the logic didn't change. It ran noticeably slower, and until I read about Dusk's Piecrust VM I never actually understood why that happens at a technical level.
I assumed all smart contract execution inside a WASM virtual machine runs at roughly native speed, since WASM is usually marketed as near native performance.
That's not accurate for cryptographic operations specifically. Research cited in the whitepaper shows WASM execution can run 45 to 255 percent slower than native code for complex applications, mainly from virtualized memory management and extra instruction handling inside the sandbox.
That's exactly why Piecrust doesn't run things like ZK proof verification, hashing, or signature checks inside the WASM sandbox at all. It exposes host functions instead, direct native calls for operations like hash, verify_plonk, verify_groth16_bn254, verify_schnorr, and verify_bls. The contract calls out to native code for the expensive cryptographic work, then comes back into WASM for everything else. That's a deliberate architectural split, not a workaround.
What the whitepaper admits directly is that Dusk hasn't quantified actual power savings from this setup yet. So I can't tell you a real efficiency number, because Dusk itself hasn't published one.
The real test for DUSK is whether this host function approach keeps holding up as contract complexity grows on mainnet.
Has anyone benchmarked Piecrust's host function calls against pure WASM execution themselves?
@Dusk #dusk $DUSK
I assumed all smart contract execution inside a WASM virtual machine runs at roughly native speed, since WASM is usually marketed as near native performance.
That's not accurate for cryptographic operations specifically. Research cited in the whitepaper shows WASM execution can run 45 to 255 percent slower than native code for complex applications, mainly from virtualized memory management and extra instruction handling inside the sandbox.
That's exactly why Piecrust doesn't run things like ZK proof verification, hashing, or signature checks inside the WASM sandbox at all. It exposes host functions instead, direct native calls for operations like hash, verify_plonk, verify_groth16_bn254, verify_schnorr, and verify_bls. The contract calls out to native code for the expensive cryptographic work, then comes back into WASM for everything else. That's a deliberate architectural split, not a workaround.
What the whitepaper admits directly is that Dusk hasn't quantified actual power savings from this setup yet. So I can't tell you a real efficiency number, because Dusk itself hasn't published one.
The real test for DUSK is whether this host function approach keeps holding up as contract complexity grows on mainnet.
Has anyone benchmarked Piecrust's host function calls against pure WASM execution themselves?
@Dusk #dusk $DUSK
