Consensus Threshold

The threshold directly defines the trade-off between safety (preventing conflicting blocks) and liveness (the ability to produce new blocks).

• A supermajority threshold (e.g., 2/3) prioritizes safety, requiring strong agreement to finalize.
• A simple majority threshold (e.g., 50%+1) prioritizes liveness, making progress easier but at a higher risk of forks.
• The CAP theorem is the underlying computer science principle: a distributed system cannot simultaneously guarantee all three of Consistency, Availability, and Partition tolerance.

Thresholds are designed to tolerate Byzantine faults, where nodes may act maliciously or arbitrarily. The classic requirement for Practical Byzantine Fault Tolerance (PBFT) and its derivatives is:

• Fault Tolerance: The network can tolerate f faulty nodes out of N total nodes.
• Threshold Formula: For safety, the agreement threshold must be greater than (N + f) / 2. For N=100 and f=33, the threshold is >66.5%.
• This ensures honest nodes maintain a majority even if all faulty nodes vote dishonestly.

The threshold determines the type of finality a blockchain provides.

• Probabilistic Finality: Used in Nakamoto Consensus (Proof-of-Work). A block is considered final after a sufficient number of confirmations, as the probability of a deeper reorganization decreases exponentially. There is no absolute threshold for reversal.
• Absolute Finality: Used in BFT-style consensus (Proof-of-Stake, Tendermint). Once a block receives votes from a supermajority (e.g., 2/3 of stake or validators), it is irreversibly finalized. The threshold is a hard, cryptographic guarantee.

Different consensus mechanisms encode their threshold in distinct rules:

• Tendermint / Cosmos: Requires >2/3 of the total voting power for pre-commit to finalize a block.
• Ethereum (Casper FFG): Finalizes epochs (groups of blocks) when 2/3 of the total staked ETH attests to a checkpoint.
• Polkadot (GRANDPA): Finalizes a chain once 2/3 of authorities approve it.
• Proof-of-Work: Implicitly uses the longest chain rule; the threshold is the cumulative hashing power needed to overtake the honest chain.

Thresholds can be fixed or adjust based on network conditions.

• Static Thresholds: A fixed percentage (e.g., 66.67%) defined in the protocol code. Simple and predictable but inflexible.
• Dynamic Thresholds: Adjust based on metrics like validator set size or total stake online. This can improve resilience if participation fluctuates.
• Quorum Intersection: In DAG-based protocols (e.g., some Avalanche consensus), thresholds are used to ensure that any two decision quorums of honest nodes have a non-empty intersection, guaranteeing agreement.

The security of the network is only as strong as its threshold assumption.

• 1/3 Attack Threshold: In a BFT system with a 2/3 supermajority requirement, an attacker controlling >1/3 of the voting power can halt the network (prevent finality).
• 51% Attack: In Nakamoto consensus, an attacker with >50% of hashing power can double-spend and rewrite recent history.
• Nothing-at-Stake: In early Proof-of-Stake, without a proper threshold penalty (slashing), validators had an incentive to vote on multiple chains. Modern protocols use slashing conditions tied to threshold violations to secure the network.

The most common threshold in Proof-of-Stake (PoS) and Byzantine Fault Tolerance (BFT) systems. It requires more than half of the validators (or their voting power) to agree. For a network with N validators, the threshold is N/2 + 1. This ensures liveness and safety as long as fewer than one-third are malicious (for BFT).

• Example: Ethereum's consensus requires attestations from a majority of the staked ETH.
• Key Property: Provides finality; once reached, the block cannot be reverted.

A stricter threshold requiring a larger predefined majority, such as two-thirds (66.6%) or three-quarters (75%). This is critical for network upgrades (hard forks) and governance proposals to ensure broad support.

• Example: Cosmos Hub governance requires a quorum of 40% turnout and a majority of Yes votes exceeding two-thirds of total votes.
• Use Case: Mitigates the risk of contentious splits and ensures high security for protocol changes.

Requires agreement from 100% of participants. While theoretically the most secure, it is highly impractical for large, permissionless networks due to liveness problems (a single offline node can halt the network).

• Practical Use: Found in small, permissioned consortium blockchains or specific multi-signature wallet configurations.
• Drawback: Extremely vulnerable to denial-of-service (DoS) attacks or simple participant failure.

The threshold is calculated based on a weighted metric, not a simple node count. In Proof-of-Work (PoW), the longest chain with the most cumulative hashpower wins. In Proof-of-Stake (PoS), it's the chain with the majority of staked value.

• Example: Bitcoin's consensus follows the Nakamoto Consensus where the valid chain is the one with the greatest total proof-of-work.
• Key Insight: Aligns security with economic investment, making attacks prohibitively expensive.

A dynamic threshold that adjusts based on network conditions, such as validator set size or participation rate. This maintains security properties even as the validator pool changes.

• Example: Some BFT-derived protocols adjust the N/2 + 1 threshold in real-time as validators join or leave the active set.
• Benefit: Enhances resilience and flexibility, preventing a fixed number of offline nodes from halting the network.

Combines a participation requirement (quorum) with a decision threshold. First, a minimum percentage of the voting body must participate. Then, a separate threshold (e.g., majority) of those votes decides the outcome.

• Common in: Decentralized Autonomous Organization (DAO) governance and off-chain voting mechanisms.
• Purpose: Prevents a small, active minority from making decisions for the entire network, ensuring legitimacy.

A consensus threshold defines the attack cost. In Proof of Work (PoW), the 51% threshold for block creation enables double-spend attacks if an attacker controls majority hash power. In Proof of Stake (PoS) with finality (e.g., Tendermint's 2/3+), exceeding the threshold allows an attacker to finalize conflicting blocks, causing a safety failure. The trade-off is that a higher threshold (e.g., 67% vs. 51%) increases security but requires more validators to be online for the network to progress.

This is the fundamental dilemma in Byzantine Fault Tolerance (BFT).

• High Threshold (e.g., 67%): Favors safety. The network cannot finalize incorrect blocks unless >1/3 of validators are malicious. However, if >1/3 are offline (non-malicious), the network halts (liveness failure).
• Lower Threshold: Favors liveness. The network can progress with more validators offline, but is more vulnerable to malicious validators finalizing bad states. Protocols like Casper FFG explicitly formalize this trade-off, requiring a 2/3 supermajority for finality.

In PoS, the threshold is enforced by slashing conditions. If a validator signs two conflicting blocks, proving they violated the consensus rules, their staked assets are destroyed. The security budget is the total value of all staked assets. An attacker must acquire and risk slashing of stakes worth at least the threshold (e.g., 2/3 of the total stake) to attack finality. This makes attacks economically prohibitive, directly linking the consensus threshold to the crypto-economic security model.

The practical security impact of a threshold depends on the fork choice rule. In Nakamoto Consensus (PoW), the 'longest chain' rule means the 51% threshold is probabilistic; older blocks become exponentially more secure over time (confirmed by subsequent work). In BFT-style PoS (e.g., Tendermint), once a block passes the 2/3 pre-commit threshold, it is instantly and absolutely final. There is no reorganization. The threshold's role is therefore interpreted differently based on the underlying consensus mechanism.

A high supermajority threshold (e.g., 67%) can inadvertently promote centralization. To ensure liveness and avoid penalties, stakers are incentivized to delegate to large, reliable validator operators. This can lead to a concentration of voting power among a few entities, creating a single point of failure and ironically reducing the censorship-resistance the threshold is meant to protect. Networks must balance the threshold with mechanisms like minimum commission rates or active set rotation to mitigate this risk.

Some advanced protocols use dynamic thresholds for different actions. For example:

• Substrate/Polkadot: A simple majority of the Technical Committee can fast-track emergency referenda, while a supermajority of all stakeholders is needed for normal upgrades.
• Cosmos Governance: Proposal passing thresholds are a percentage of total staked tokens that vote, not total supply, which adjusts based on participation.
• Quorum-based Voting: Thresholds may require a minimum participation (quorum) and a supermajority of that quorum, protecting against apathy attacks.

The irreversible confirmation that a block and its transactions are permanently settled. A consensus threshold is the specific validator vote requirement that, once met, guarantees finality.

• Probabilistic Finality: Used in Nakamoto Consensus (Proof of Work), where confidence increases with chain depth but absolute thresholds are not formally defined.
• Absolute (Instant) Finality: Achieved in BFT-style protocols the moment the voting threshold is surpassed, as seen in Ethereum's Casper FFG or Algorand.

The minimum number of participating members required for a governing body to make valid decisions. In blockchain consensus, the quorum is often synonymous with the active validator set, while the consensus threshold is the specific fraction of that quorum needed to approve a block.

• Example: A network with 100 active validators might require a quorum of 67 (a 2/3 threshold) to finalize a block.
• Distinction: A quorum ensures participation; the threshold ensures the correctness of the decision.

Protocol-enforced penalties applied to validators who violate consensus rules. The consensus threshold defines the boundary between honest and malicious behavior that triggers slashing.

• Double Signing: Signing two different blocks at the same height, which is detectable once the honest threshold is met.
• Downtime: Failing to participate in consensus, which can be measured against the required participation threshold for liveness.
• These conditions are critical for securing Proof of Stake networks like Cosmos and Ethereum.

The deterministic algorithm nodes use to select the canonical chain from competing blockchain forks. The consensus threshold is a key input to this rule.

• Longest Chain Rule (Proof of Work): The threshold is implicit in the computational work required to extend a chain.
• GHOST / LMD-GHOST (Ethereum): Weights forks by the accumulated votes of validators, with the threshold defining what constitutes a valid vote.
• The rule ensures all honest nodes converge on the same chain once the threshold is achieved.

The two fundamental guarantees of a consensus protocol, which are in tension. The consensus threshold directly balances this trade-off.

• Safety: Nothing bad happens (no two conflicting blocks are finalized). A higher threshold (e.g., >2/3) maximizes safety.
• Liveness: Something good eventually happens (the network can produce new blocks). A lower threshold can improve liveness under poor network conditions.
• The classic result (FLP Impossibility) states that in an asynchronous network, a protocol cannot achieve both perfect safety and perfect liveness.