#dusk $DUSK @Dusk Something about Dusk's storage design bugs me, in a good way. Piecrust, their VM, writes state to disk in 64KB chunks full WASM memory pages. Ethereum writes in 32-byte slots. That's roughly a 2,000x gap in granularity, just to update one value.

Why so coarse? Dusk skips the key value storage API entirely. A contract's whole memory is its state. Write a plain Rust struct, use a BTreeMap, and it persists automatically no SSTORE-style bookkeeping. For teams coming from traditional finance rather than Solidity, that's genuinely easier to build on.

But whole-memory persistence doesn't scale for free, and the team clearly hit that wall. They built dirty-page tracking so only changed pages get rewritten instead of the entire snapshot every time. Smart fix. Still, the unit of "changed" is a 64KB page, not a few bytes. A ledger with thousands of entries, touched by one transaction, could still dirty several scattered pages just from how the allocator lays memory out. Feels like a real tradeoff, not a solved problem.

I haven't seen load benchmarks on this yet. So genuinely curious has anyone pressure-tested Piecrust under actual high-frequency settlement traffic?