#dusk $DUSK For the past couple of days, I’ve been browsing Dusk’s GitHub repository and found a design that isn’t explained in much depth in a document, but is actually crucial: the memory isolation model of the Piecrust VM.
Most smart contract virtual machines use shared memory, where data can be exchanged between different contracts through message calls. The advantage is flexibility, but the downside is that a bug in one contract may pollute the memory space of others. Piecrust VM takes a different route—each contract instance has its own independent linear memory space. Contracts can’t directly read or write each other’s memory; they can only pass serialized data through explicitly defined ABI interfaces.
At this level of isolation, it’s more like the sandboxing model of WebAssembly than the EVM’s shared state. For the compliance-focused finance scenarios that Dusk is targeting, this design fits very well: a bug in a security token contract won’t leak the customer balances of the neighboring payment contract, and during audits you can verify each contract independently without worrying about cross-contract implicit data flows.
Another detail I noticed is how Piecrust measures gas. Unlike the EVM, which charges gas per opcode, it uses an execution-cost weighting based on wasm instruction costs. The gas costs of addition/subtraction differ from multiplication/division, and memory reads/writes also differ from arithmetic operations. In theory, this fine-grained metering lets developers write more efficient contracts—because you can tell which operations are expensive and proactively avoid them.
Of course, this also means gas estimation becomes more complex. EVM gas estimation is already quite mature thanks to the toolchain, and Piecrust still lacks a fully established profiler. But the direction is right: exchange more precise metering for more efficient execution.@Dusk
Most smart contract virtual machines use shared memory, where data can be exchanged between different contracts through message calls. The advantage is flexibility, but the downside is that a bug in one contract may pollute the memory space of others. Piecrust VM takes a different route—each contract instance has its own independent linear memory space. Contracts can’t directly read or write each other’s memory; they can only pass serialized data through explicitly defined ABI interfaces.
At this level of isolation, it’s more like the sandboxing model of WebAssembly than the EVM’s shared state. For the compliance-focused finance scenarios that Dusk is targeting, this design fits very well: a bug in a security token contract won’t leak the customer balances of the neighboring payment contract, and during audits you can verify each contract independently without worrying about cross-contract implicit data flows.
Another detail I noticed is how Piecrust measures gas. Unlike the EVM, which charges gas per opcode, it uses an execution-cost weighting based on wasm instruction costs. The gas costs of addition/subtraction differ from multiplication/division, and memory reads/writes also differ from arithmetic operations. In theory, this fine-grained metering lets developers write more efficient contracts—because you can tell which operations are expensive and proactively avoid them.
Of course, this also means gas estimation becomes more complex. EVM gas estimation is already quite mature thanks to the toolchain, and Piecrust still lacks a fully established profiler. But the direction is right: exchange more precise metering for more efficient execution.@Dusk