#dusk $DUSK @Dusk I went looking for what deterministic finality actually means inside Dusk's Succinct Attestation consensus and found two different descriptions in two official sources.
The marketing version is clean. Three steps. Proposal. Validation. Ratification. Block finalizes. Deterministic. Done.
The whitepaper version is more honest.
SA runs in rounds. Each round can have multiple iterations. Most blocks finalize in iteration 1 with full committee participation. But iterations 2, 3, 4 exist for a reason. Each subsequent iteration reduces the quorum threshold required to advance. The protocol does not give up easily. It keeps trying.
Hmm.
The whitepaper describes up to 213 possible iterations before emergency procedures can be triggered. Emergency mode involves a different signing path and ultimately a fallback that the docs acknowledge exists for network continuity.
Two things sit inside that design worth separating clearly.
First: deterministic finality is a real guarantee. Once a block is ratified it cannot be reorganized. No probabilistic confirmation counting. No waiting for 6 blocks. Final means final. That property is genuine and matters for regulated settlement.
Second: deterministic finality is a consensus outcome guarantee, not a time guarantee. The protocol guarantees the block will finalize. It does not guarantee exactly when. A block that requires multiple iterations takes longer than a block that finalizes in iteration 1. Both are deterministically final. They arrive at finality on different clocks.
Traditional securities settlement has T plus 1 and T plus 2 cycles. Predictable windows. Contractual obligations tied to specific timelines.
A regulated application on Dusk that promises settlement in seconds is promising the typical case. The protocol guarantees the outcome. The time to that outcome varies with network conditions in ways the deterministic finality language does not fully communicate.
The marketing version is clean. Three steps. Proposal. Validation. Ratification. Block finalizes. Deterministic. Done.
The whitepaper version is more honest.
SA runs in rounds. Each round can have multiple iterations. Most blocks finalize in iteration 1 with full committee participation. But iterations 2, 3, 4 exist for a reason. Each subsequent iteration reduces the quorum threshold required to advance. The protocol does not give up easily. It keeps trying.
Hmm.
The whitepaper describes up to 213 possible iterations before emergency procedures can be triggered. Emergency mode involves a different signing path and ultimately a fallback that the docs acknowledge exists for network continuity.
Two things sit inside that design worth separating clearly.
First: deterministic finality is a real guarantee. Once a block is ratified it cannot be reorganized. No probabilistic confirmation counting. No waiting for 6 blocks. Final means final. That property is genuine and matters for regulated settlement.
Second: deterministic finality is a consensus outcome guarantee, not a time guarantee. The protocol guarantees the block will finalize. It does not guarantee exactly when. A block that requires multiple iterations takes longer than a block that finalizes in iteration 1. Both are deterministically final. They arrive at finality on different clocks.
Traditional securities settlement has T plus 1 and T plus 2 cycles. Predictable windows. Contractual obligations tied to specific timelines.
A regulated application on Dusk that promises settlement in seconds is promising the typical case. The protocol guarantees the outcome. The time to that outcome varies with network conditions in ways the deterministic finality language does not fully communicate.