dusk has two contract environments, but the interesting part isnt that there are two.
duskvm runs directly on the l1, contract execution and dusk's settlement happen in the same place. duskevm
looks separate on the surface, solidity, evm wallets, its 0wn rpc, but a duskevm transaction actually moves through four stages before its really settled. it goes to the sequencer first, gets included in an l2 block, the.
batcher publishes that transaction data to duskds, and only then do state comitments and fault proofs connect the resulting state back to duskds settlement.
its easy to miss that inclusion and settlement are.
explicitly two different stages here, not one. a transaction can show up fast in an l2 block while the actual settlement step is stil catching up behind it.
that distinction matters more than it sounds like.
the docs specifically warn against inferring finality from elapsed time and say apps moving value between duskevm and the l1 should check protocol or wallet status instead. i didnt expect that gap betwen inclusion and.
setlement to be called out this directly, it feels like exactly the place bugs would hide if a team assumed a fast transaction was already final.
if you were building on duskevm, would you check settlement status before or after showing the user an succes screen??
#dusk @Dusk $DUSK
duskvm runs directly on the l1, contract execution and dusk's settlement happen in the same place. duskevm
looks separate on the surface, solidity, evm wallets, its 0wn rpc, but a duskevm transaction actually moves through four stages before its really settled. it goes to the sequencer first, gets included in an l2 block, the.
batcher publishes that transaction data to duskds, and only then do state comitments and fault proofs connect the resulting state back to duskds settlement.
its easy to miss that inclusion and settlement are.
explicitly two different stages here, not one. a transaction can show up fast in an l2 block while the actual settlement step is stil catching up behind it.
that distinction matters more than it sounds like.
the docs specifically warn against inferring finality from elapsed time and say apps moving value between duskevm and the l1 should check protocol or wallet status instead. i didnt expect that gap betwen inclusion and.
setlement to be called out this directly, it feels like exactly the place bugs would hide if a team assumed a fast transaction was already final.
if you were building on duskevm, would you check settlement status before or after showing the user an succes screen??
#dusk @Dusk $DUSK