Each consensus round must add a new block. However, the whitepaper says that this round is not completed in a single pass; instead, it is carried out through multiple iterations, and each iteration is further divided into three steps. In Section 3.2, the whitepaper refers to these three steps as Proposal, Validation, and Ratification.
First step: Proposal. The DS algorithm randomly selects a provisioner as the block producer, responsible for generating candidate blocks and broadcasting them to the entire network. If no candidate block is produced or received within the specified timeout, this step outputs NIL and moves directly to the next step—but with no candidate block in hand, what is voted on afterward? The answer is: do not cast an empty vote; instead, vote NoCandidate, meaning “no candidate block is verifiable.” $DUSK
Second step: Validation. The DS algorithm randomly selects a set of voting committee members to validate the candidate block from the previous step. If the candidate block is valid, vote Valid; if invalid, vote Invalid; if there is no candidate block, vote NoCandidate. The voting committee needs an absolute majority of 2/3 to reach quorum. If quorum is not reached before the timeout, output NoQuorum. The output of this step is a ValidationResult, which includes the vote type that achieved quorum and the aggregated signature of all voters. @Dusk
Third step: Ratification. A new set of voting committee members is selected to confirm the result of the Validation. If the previous step achieves the Valid quorum, they confirm that result; if the previous step is NoQuorum or fails, they vote NoQuorum. This step ensures that the validation result is not decided by only a minority, but is recognized by a larger number of provisioners.
If the Ratification outputs Success, the candidate block is officially accepted as the new block, and the round ends. If it outputs Fail or unknown, the protocol proceeds to the next iteration: re-select the block producer and re-cast the votes. The whitepaper states that the maximum number of iterations is determined by a global parameter; the current setting is 50. If 16 consecutive iterations fail, the protocol enters emergency mode (angle 10).
The core logic of the three-step design is checks and balances: the block producer can only generate candidate blocks and cannot vote; the validation committee can only validate and cannot confirm; the confirmation committee can only confirm the validation result and cannot re-verify. No single role can decide the fate of a block on its own. #dusk
First step: Proposal. The DS algorithm randomly selects a provisioner as the block producer, responsible for generating candidate blocks and broadcasting them to the entire network. If no candidate block is produced or received within the specified timeout, this step outputs NIL and moves directly to the next step—but with no candidate block in hand, what is voted on afterward? The answer is: do not cast an empty vote; instead, vote NoCandidate, meaning “no candidate block is verifiable.” $DUSK
Second step: Validation. The DS algorithm randomly selects a set of voting committee members to validate the candidate block from the previous step. If the candidate block is valid, vote Valid; if invalid, vote Invalid; if there is no candidate block, vote NoCandidate. The voting committee needs an absolute majority of 2/3 to reach quorum. If quorum is not reached before the timeout, output NoQuorum. The output of this step is a ValidationResult, which includes the vote type that achieved quorum and the aggregated signature of all voters. @Dusk
Third step: Ratification. A new set of voting committee members is selected to confirm the result of the Validation. If the previous step achieves the Valid quorum, they confirm that result; if the previous step is NoQuorum or fails, they vote NoQuorum. This step ensures that the validation result is not decided by only a minority, but is recognized by a larger number of provisioners.
If the Ratification outputs Success, the candidate block is officially accepted as the new block, and the round ends. If it outputs Fail or unknown, the protocol proceeds to the next iteration: re-select the block producer and re-cast the votes. The whitepaper states that the maximum number of iterations is determined by a global parameter; the current setting is 50. If 16 consecutive iterations fail, the protocol enters emergency mode (angle 10).
The core logic of the three-step design is checks and balances: the block producer can only generate candidate blocks and cannot vote; the validation committee can only validate and cannot confirm; the confirmation committee can only confirm the validation result and cannot re-verify. No single role can decide the fate of a block on its own. #dusk