spent this morning going through how a duskevm transaction actually moves through the system and honestly? đ i assumed once it showed up in a block i was done watching it, turns out thats not quite right.
so duskevm is the evm compatible layer on dusk, meaning you write solidity, use normal evm wallets and standard tooling like foundry or hardhat, and pay gas in dusk throughout. but the transaction doesnt just live and die on duskevm by itself. it goes through a rollup style lifecycle. first it gets submitted to the duskevm sequencer, then included in an l2 block relatively fast. after that a batcher publishes the transaction data over to duskds, dusks actual settlement and data availability layer. state commitments and fault proofs are what connect that resulting state back to duskds so its actually settled, not just sitting in an l2 block somewhere waiting.
what i keep coming back to is a line in the docs that flags inclusion and settlement as genuinely different stages, and that apps moving value between duskevm and the dusk l1 should check protocol or wallet status instead of just assuming something is final because time has passed. thats a real distinction, not a technicality. i havent found anywhere that spells out how long that gap typically is in practice, fast inclusion clearly doesnt mean instant settlement, but i dont know the actual window someone should wait.
still, the design choice itself makes sense to me. instead of building a totally separate evm chain floating off on its own, duskevm stays anchored to duskds for settlement and data availability, so you get full solidity tooling without losing the base layers guarantees around finality.
honestly dont know if that inclusion to settlement gap is small enough to ignore day to day or something builders need to actively account for??
đ€
#dusk @Dusk $DUSK
so duskevm is the evm compatible layer on dusk, meaning you write solidity, use normal evm wallets and standard tooling like foundry or hardhat, and pay gas in dusk throughout. but the transaction doesnt just live and die on duskevm by itself. it goes through a rollup style lifecycle. first it gets submitted to the duskevm sequencer, then included in an l2 block relatively fast. after that a batcher publishes the transaction data over to duskds, dusks actual settlement and data availability layer. state commitments and fault proofs are what connect that resulting state back to duskds so its actually settled, not just sitting in an l2 block somewhere waiting.
what i keep coming back to is a line in the docs that flags inclusion and settlement as genuinely different stages, and that apps moving value between duskevm and the dusk l1 should check protocol or wallet status instead of just assuming something is final because time has passed. thats a real distinction, not a technicality. i havent found anywhere that spells out how long that gap typically is in practice, fast inclusion clearly doesnt mean instant settlement, but i dont know the actual window someone should wait.
still, the design choice itself makes sense to me. instead of building a totally separate evm chain floating off on its own, duskevm stays anchored to duskds for settlement and data availability, so you get full solidity tooling without losing the base layers guarantees around finality.
honestly dont know if that inclusion to settlement gap is small enough to ignore day to day or something builders need to actively account for??
đ€
#dusk @Dusk $DUSK