#dusk $DUSK @Dusk A Citadel license proof takes about 16 seconds to generate. < cite index="62-1">Checking that same proof takes 0.007 seconds.</cite> That's roughly a 2,300x gap between proving and verifying the identical statement.
I went back to the original Citadel paper to see why. < cite index="62-1">The full circuit runs about 34,861 constraints, and just over half of that, 17,807, goes toward proving your license sits inside a Merkle tree 17 levels deep.</cite> Layer in a double-key signature check for ownership and a nullifier hash to block reuse, and you land only about 10% heavier than < cite index="62-1">what a standard private Phoenix transfer already costs on its own, roughly 31,486 constraints.</cite> Compliance rides mostly on privacy machinery Dusk was already paying for.
What's genuinely elegant is the verifier side. That 7 millisecond check barely moves no matter how complex the underlying attributes get, so a validator confirming a million of these a day pays close to the same cost each time. That part scales the way people assume ZK systems scale.
The 16 seconds doesn't. That cost sits with whoever's proving, and < cite index="58-1,59-1">Citadel is built around generating a fresh on-chain proof each time a user opens a session with a service, not once at signup.</cite> < cite index="62-1">Dusk's own workaround is proof delegation, letting a semi-trusted helper do the heavy computation for you.</cite> Which quietly reopens the third party this system exists to remove.
Every one of those proof calls still pays gas in DUSK. So the real question isn't whether compliance can stay private on Dusk. It's whether people keep proving it themselves, or eventually just pay someone else to.
🛢️ Oil Holds Losses as Markets Weigh Iran Risks #OilHoldsLosses Oil prices are struggling to recover after Monday’s sharp decline, with Brent hovering around $92 and WTI near $85. Investors are weighing the impact of expanded U.S. sanctions on Iran against the possibility of reduced disruption to Middle East supplies.
With the Strait of Hormuz still a major supply-risk factor, volatility could remain high. 📉🌍
#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?
#dusk $DUSK @Dusk Dusk caps blocks at 1MB.....Sounds almost quaint next to chains bragging about gigabyte blocks until you run the math on what actually fits inside.👀
That ceiling holds roughly 250 Phoenix transactions . Divide it out and each confidential transfer eats close to 4KB, while a plain UTXO transfer elsewhere fits in a few hundred bytes. The gap is the ZK proof itself nullifiers, commitments, PLONK verification data the literal cost of hiding sender, receiver, and amount.
Run the throughput math against Dusk's roughly 10-second block time and confidential capacity lands around 25 TPS. Fine for early institutional pilots. Less fine if XSC securities settlement ever hits real volume alongside public Moonlight activity competing for the same block space.
Raising the cap is the obvious fix, and it's configurable. But bigger blocks mean more bandwidth every Kadcast peer relays and more storage every provisioner holds a cost that falls hardest on smaller node operators, not the institutions the chain is courting.
Privacy has a byte cost, and byte cost has a centralization cost. DUSK's value depends on absorbing real settlement volume without quietly outsourcing block production to whoever can afford the pipe.
Does the current design scale that far, or just far enough to look good on testnet?