Tonight I was scrolling through the section of the @Dusk whitepaper about rolling finality. I only meant to skim it, but I got stuck for nearly two hours without continuing.
Most people’s understanding of “block confirmation” is pretty rough: once a block is on-chain, it’s secure, and at most you just wait for a few more confirmation counts to ease your mind. I used to think that way too—until I calculated Dusk’s Rolling Finality rules in detail, and realized that this “just wait for some confirmations” intuition may be wrong on this chain.
Dusk divides block state into four levels: accepted, attested, confirmed, and final. It sounds like a standard tiered system, but the devil is in the details. If a block can’t achieve consensus in the absence of “zero prior failure iterations” (i.e., where n>0 and there were iteration failures before), it can only be marked as accepted first, not as the sturdier attested.
An accepted state means the block could theoretically be replaced by a candidate block with a lower iteration sequence number.
To become confirmed, how many subsequent blocks do you need to wait for? The answer isn’t a fixed 1 or 3. It’s 2×n blocks. Here, n is the number of prior failed iterations. In the example given in the whitepaper—iteration sequence number 5 with 2 prior failures—you need to wait for a total of 4 subsequent attested/confirmed blocks before it’s considered solid.
I read this rule three times before I was sure I hadn’t misunderstood it.
This means two blocks that are “already on-chain” have, in fact, unequal risk. One block that succeeds without any prior failed iterations will almost immediately move into the more robust attested state. Another block that only succeeds after multiple iteration failures needs to wait for more subsequent blocks to reach the same level of resistance to replacement. On the surface, they may both look “confirmed,” but underneath, their fragility is layered.
So my current approach is: when I need to judge whether “this transaction is truly stable,” I no longer look only at the confirmation count as a single metric. Instead, I check how many iteration failures the block containing that transaction has gone through. The higher the iteration count, the more confirmation blocks I’m willing to wait for—especially in large-value settlement scenarios.
If you’re just doing small, frequent transfers, these details probably won’t matter much—the risk window is already short. But if you’re doing institutional DvP settlement or large-value OTC trades, it’s worth checking that n value yourself in Dusk node data. #dusk $DUSK @Dusk
Most people’s understanding of “block confirmation” is pretty rough: once a block is on-chain, it’s secure, and at most you just wait for a few more confirmation counts to ease your mind. I used to think that way too—until I calculated Dusk’s Rolling Finality rules in detail, and realized that this “just wait for some confirmations” intuition may be wrong on this chain.
Dusk divides block state into four levels: accepted, attested, confirmed, and final. It sounds like a standard tiered system, but the devil is in the details. If a block can’t achieve consensus in the absence of “zero prior failure iterations” (i.e., where n>0 and there were iteration failures before), it can only be marked as accepted first, not as the sturdier attested.
An accepted state means the block could theoretically be replaced by a candidate block with a lower iteration sequence number.
To become confirmed, how many subsequent blocks do you need to wait for? The answer isn’t a fixed 1 or 3. It’s 2×n blocks. Here, n is the number of prior failed iterations. In the example given in the whitepaper—iteration sequence number 5 with 2 prior failures—you need to wait for a total of 4 subsequent attested/confirmed blocks before it’s considered solid.
I read this rule three times before I was sure I hadn’t misunderstood it.
This means two blocks that are “already on-chain” have, in fact, unequal risk. One block that succeeds without any prior failed iterations will almost immediately move into the more robust attested state. Another block that only succeeds after multiple iteration failures needs to wait for more subsequent blocks to reach the same level of resistance to replacement. On the surface, they may both look “confirmed,” but underneath, their fragility is layered.
So my current approach is: when I need to judge whether “this transaction is truly stable,” I no longer look only at the confirmation count as a single metric. Instead, I check how many iteration failures the block containing that transaction has gone through. The higher the iteration count, the more confirmation blocks I’m willing to wait for—especially in large-value settlement scenarios.
If you’re just doing small, frequent transfers, these details probably won’t matter much—the risk window is already short. But if you’re doing institutional DvP settlement or large-value OTC trades, it’s worth checking that n value yourself in Dusk node data. #dusk $DUSK @Dusk