#dusk $DUSK
The numbers 2/3 and 1/2 kept appearing in separate parts of the consensus documentation and I kept treating them as the same threshold with different notation. They're not. They're two different quorum rules for two different outcomes.
Block approval threshold: ≥2/3 of committee credits must vote Valid. That's a supermajority. For a 64-credit committee, that means at least 43 credits need to agree that the block is correct before it gets accepted.
Block rejection threshold: >1/2 of committee credits — strictly more than half, plus one — must vote Invalid, NoCandidate, or NoQuorum. That's a simple majority. For 64 credits, that's at least 33.
Same committee. Different bar. Reaching approval is harder than triggering a failure.
So why doesn't the rejection threshold also require 2/3.
The asymmetry is deliberate. The design rationale is that approving a block requires high confidence — you don't want a block to get accepted unless a strong majority agrees it's correct. But closing out a failing iteration doesn't carry the same risk. If the block generator was offline, or sent something invalid, you want the network to move on quickly rather than waiting for a higher threshold to confirm the failure. A lower rejection threshold means the network fails faster and tries again sooner.
I actually find the threshold asymmetry more interesting from a security standpoint than from a speed standpoint. The harder approval threshold makes it significantly more expensive for an attacker to get a malicious block accepted than it is for honest validators to reject a bad one.
What I haven't seen explained is how the committee weighting interacts with these thresholds — whether a single provisioner holding 20 of the 64 credits can meaningfully block approval or accelerate rejection by themselves, or whether the credit distribution across the committee makes that kind of concentration practically impossible. @Dusk
$DUSK #dusk
The numbers 2/3 and 1/2 kept appearing in separate parts of the consensus documentation and I kept treating them as the same threshold with different notation. They're not. They're two different quorum rules for two different outcomes.
Block approval threshold: ≥2/3 of committee credits must vote Valid. That's a supermajority. For a 64-credit committee, that means at least 43 credits need to agree that the block is correct before it gets accepted.
Block rejection threshold: >1/2 of committee credits — strictly more than half, plus one — must vote Invalid, NoCandidate, or NoQuorum. That's a simple majority. For 64 credits, that's at least 33.
Same committee. Different bar. Reaching approval is harder than triggering a failure.
So why doesn't the rejection threshold also require 2/3.
The asymmetry is deliberate. The design rationale is that approving a block requires high confidence — you don't want a block to get accepted unless a strong majority agrees it's correct. But closing out a failing iteration doesn't carry the same risk. If the block generator was offline, or sent something invalid, you want the network to move on quickly rather than waiting for a higher threshold to confirm the failure. A lower rejection threshold means the network fails faster and tries again sooner.
I actually find the threshold asymmetry more interesting from a security standpoint than from a speed standpoint. The harder approval threshold makes it significantly more expensive for an attacker to get a malicious block accepted than it is for honest validators to reject a bad one.
What I haven't seen explained is how the committee weighting interacts with these thresholds — whether a single provisioner holding 20 of the 64 credits can meaningfully block approval or accelerate rejection by themselves, or whether the credit distribution across the committee makes that kind of concentration practically impossible. @Dusk
$DUSK #dusk
