spent today going through how DuskEVM actually processes a transaction end to end, because i kept seeing "rollup" mentioned without the actual mechanics spelled out, so figured id trace it myself.
it starts when you submit a transaction to the DuskEVM sequencer - this is the part thats familiar if youve touched any other rollup, standard solidity/evm tx, nothing exotic yet. from there the execution layer includes it in an L2 block. so far this is just normal rollup stuff happening fast on the execution side.
wheres it gets more interesting is the next two steps. the batcher takes that transaction data and publishes it to DuskDS – this is dusk's actual consensus, settlement, and data availability layer, the thing doing the heavy lifting underneath. then state commitments and fault proofs are what actually connect the resulting DuskEVM state back to DuskDS settlement.
the part i think matters most practically - inclusion and settlement are explicitly different stages here, not the same thing wearing two names. your tx getting included in an L2 block happens fast, but that not the same as it being settled. and the docs are pretty direct about this: if your building something that moves value between DuskEVM and the Dusk L1, you should be checking actual protocol or wallet status, not just assuming something is final because some amount of time passed.
thats a distinction i think a lot of people skip past when they hear "fast rollup" and assume speed alone implies finality. it doesnt, at least not by itself.
still want to dig into what the actual typical gap looks like between inclusion and full settlement in practice, the docs describe the stages but not concrete timing.
#dusk @Dusk $DUSK
it starts when you submit a transaction to the DuskEVM sequencer - this is the part thats familiar if youve touched any other rollup, standard solidity/evm tx, nothing exotic yet. from there the execution layer includes it in an L2 block. so far this is just normal rollup stuff happening fast on the execution side.
wheres it gets more interesting is the next two steps. the batcher takes that transaction data and publishes it to DuskDS – this is dusk's actual consensus, settlement, and data availability layer, the thing doing the heavy lifting underneath. then state commitments and fault proofs are what actually connect the resulting DuskEVM state back to DuskDS settlement.
the part i think matters most practically - inclusion and settlement are explicitly different stages here, not the same thing wearing two names. your tx getting included in an L2 block happens fast, but that not the same as it being settled. and the docs are pretty direct about this: if your building something that moves value between DuskEVM and the Dusk L1, you should be checking actual protocol or wallet status, not just assuming something is final because some amount of time passed.
thats a distinction i think a lot of people skip past when they hear "fast rollup" and assume speed alone implies finality. it doesnt, at least not by itself.
still want to dig into what the actual typical gap looks like between inclusion and full settlement in practice, the docs describe the stages but not concrete timing.
#dusk @Dusk $DUSK
YES
0%
NO
0%
0 votes • Voting closed