I kept coming back to one distinction in Dusk’s consensus section: an iteration that didn’t produce the block you’re building on is not necessarily an iteration that failed.
That sounds pedantic until you read how attestations and fallback interact.
In Dusk’s Succinct Attestation, validation and ratification votes can produce a success attestation for a Valid quorum, or a fail attestation for Invalid, NoCandidate, or NoQuorum. But there is a third state: unknown, where the required quorum was not observed.
My first read treated “unknown” as basically dead. The round moved on, another iteration produced a block.
Dusk doesn’t.
If a block is produced at iteration I > 0, the protocol looks backward. If every earlier iteration has a fail attestation, the block is marked attested. Those earlier paths cannot later claim consensus.
If even one earlier iteration lacks that fail proof, the block is only accepted.
That difference does more work than the labels suggest.
Dusk’s fallback rules allow a higher-iteration block to be replaced if a lower-iteration block also reaches consensus. The whitepaper notes that delayed or lost messages can produce this kind of fork. So an earlier iteration that merely went quiet is still unresolved.
Rolling finality turns that uncertainty into waiting time. In Dusk, let n be the number of previous non-attested iterations. An accepted block needs 2×n consecutive attested or confirmed successors before becoming confirmed. It becomes final only once confirmed and its parent is final.
So Dusk isn’t just counting blocks here. It is effectively counting unresolved history.
That made the fail attestation more interesting to me. In Dusk, it does more than say “this attempt failed.” It closes a branch of ambiguity. If that proof is missing, part of the past stays open, and later blocks have to accumulate enough evidence before Dusk treats the chain as settled.
@Dusk #dusk $DUSK $TMX $TAC
That sounds pedantic until you read how attestations and fallback interact.
In Dusk’s Succinct Attestation, validation and ratification votes can produce a success attestation for a Valid quorum, or a fail attestation for Invalid, NoCandidate, or NoQuorum. But there is a third state: unknown, where the required quorum was not observed.
My first read treated “unknown” as basically dead. The round moved on, another iteration produced a block.
Dusk doesn’t.
If a block is produced at iteration I > 0, the protocol looks backward. If every earlier iteration has a fail attestation, the block is marked attested. Those earlier paths cannot later claim consensus.
If even one earlier iteration lacks that fail proof, the block is only accepted.
That difference does more work than the labels suggest.
Dusk’s fallback rules allow a higher-iteration block to be replaced if a lower-iteration block also reaches consensus. The whitepaper notes that delayed or lost messages can produce this kind of fork. So an earlier iteration that merely went quiet is still unresolved.
Rolling finality turns that uncertainty into waiting time. In Dusk, let n be the number of previous non-attested iterations. An accepted block needs 2×n consecutive attested or confirmed successors before becoming confirmed. It becomes final only once confirmed and its parent is final.
So Dusk isn’t just counting blocks here. It is effectively counting unresolved history.
That made the fail attestation more interesting to me. In Dusk, it does more than say “this attempt failed.” It closes a branch of ambiguity. If that proof is missing, part of the past stays open, and later blocks have to accumulate enough evidence before Dusk treats the chain as settled.
@Dusk #dusk $DUSK $TMX $TAC
