Correction Threshold

The Correction Threshold establishes the maximum number of Byzantine (faulty or malicious) nodes a network can tolerate while still guaranteeing safety. Safety ensures all honest nodes agree on the same, valid state of the ledger, preventing double-spends and forks. In many Proof-of-Stake (PoS) systems, this is often modeled as requiring > 2/3 (or 66.6%) of the total stake to be honest to finalize blocks.

This parameter also defines the conditions for liveness, which is the network's ability to continue producing new blocks and processing transactions. If the proportion of honest participants falls below the threshold, the network may halt to preserve safety. The trade-off between safety and liveness is formalized in the CAP theorem and FLP impossibility result for distributed systems.

The threshold is derived from Byzantine Fault Tolerance (BFT) research. For a network of N nodes with f faulty ones:

• Synchronous Networks: Tolerates f < N/3 for BFT consensus.
• Partial Synchrony: Practical BFT (pBFT) protocols also typically require f < N/3.
• Asynchronous Networks: Guarantees are weaker (FLP impossibility). These bounds define the resilience of the protocol.

In Proof-of-Stake networks like Ethereum (post-merge), the correction threshold is expressed in terms of stake, not node count. Validators commit their ETH as collateral. The protocol's consensus rules (e.g., Casper FFG) are designed so that finality can only be achieved if validators controlling more than 2/3 of the total staked ETH vote honestly. A malicious coalition with > 1/3 of the stake can prevent finality.

To enforce the threshold, protocols implement slashing conditions. These are cryptographic proofs that a validator violated protocol rules (e.g., voting for two conflicting blocks). If slashing events reveal that validators controlling more than 1/3 of the stake acted maliciously, the chain may experience a catastrophic failure where a significant portion of stake is burned, but safety is preserved.

The threshold translates directly into the economic cost of attacking the network. To violate safety (e.g., double-spend), an attacker must control stake or hash power exceeding the threshold. For Ethereum, this means acquiring and risking > 1/3 of the total staked ETH (tens of billions of dollars), which would be slashed, making the attack prohibitively expensive.

The correction threshold is the minimum number of honest or correct nodes required in a distributed network to ensure both safety (no two honest nodes decide on conflicting values) and liveness (the network continues to produce new blocks). In BFT protocols, it is mathematically derived from the total number of nodes (N) and the assumed maximum number of faulty nodes (f). The classic formula is N > 3f, meaning the network can tolerate up to f faulty nodes while requiring at least 2f + 1 honest nodes to reach consensus.

In Tendermint Core, used by the Cosmos ecosystem, the correction threshold is operationalized through its voting process. For a block to be committed, it must receive pre-commits from more than two-thirds of the total voting power. If the total voting power is N, and faulty validators control f power, the condition N > 3f ensures the honest majority (2f + 1) can always finalize blocks. This makes the protocol resilient to up to one-third of validators failing or acting maliciously.

Unlike pure BFT chains, Nakamoto consensus chains (like Bitcoin) do not have a formal correction threshold for finality; probabilistic finality emerges from the longest chain rule. Finality gadgets like Ethereum's Casper FFG hybridize these models. Casper FFG imposes a BFT-style correction threshold on top of a proof-of-stake chain, requiring a two-thirds supermajority of staked ETH to finalize checkpoints. This provides explicit, accountable finality distinct from the underlying chain's fork choice rule.

Setting the correction threshold involves a fundamental security trade-off:

• Higher Threshold (e.g., N > 4f): Increases resilience but reduces liveness; the network may halt more easily if nodes are temporarily offline.
• Lower Threshold (e.g., N > 2f): Improves liveness but compromises safety, allowing conflicting blocks to be finalized. The N > 3f standard optimizes for both properties under synchronous network assumptions. This threshold directly defines the protocol's resilience to Byzantine failures, including censorship and double-signing attacks.

The correction threshold is a key consideration for validator set selection and slashing. Protocols must ensure the bonded stake or voting power controlled by potentially faulty actors never exceeds f. This is enforced through:

• Slashing conditions that penalize equivocation.
• Governance proposals to remove malicious validators.
• Dynamic validator sets that adjust based on stake, ensuring the honest majority (2f + 1) is always maintained to satisfy the safety condition, even as participants join or leave.

The Correction Threshold is the maximum proportion of Byzantine (malicious or faulty) validators a blockchain network can tolerate while still guaranteeing safety (no two honest nodes confirm conflicting blocks) and eventual liveness (the chain continues to produce new blocks). It is a fundamental parameter set in the protocol's code, often expressed as a fraction like 1/3 or 1/2. Its primary purpose is to mathematically define the network's resilience, ensuring it can automatically recover and continue operating correctly even if some participants act adversarially.

In practical Byzantine Fault Tolerance (pBFT) and its derivatives (e.g., Tendermint, HotStuff), the standard correction threshold is f < n/3, where 'n' is the total number of validators and 'f' is the number of faulty ones. This means the network can withstand up to one-third of validators being Byzantine.

• Safety Proof: Requires 2f + 1 honest validators to guarantee that only one block can be finalized for a given height.
• Liveness Proof: Requires at least 2f + 1 validators to be honest and responsive to progress to the next round. Exceeding this threshold can lead to safety failures like double-signing or network halts.

The correction threshold is directly tied to the concept of finality. In BFT chains, once a block is finalized (requires pre-commits from >2/3 of voting power), it is irreversible under the threshold assumption. If the proportion of Byzantine power exceeds the correction threshold, finality can be broken, leading to deep chain reorganizations (reorgs). This is a catastrophic failure mode where previously confirmed transactions can be reversed, undermining the blockchain's core guarantee of immutability.

Setting the correction threshold involves a key trade-off between resilience and performance/decentralization.

• Higher Threshold (e.g., 1/2): Allows more tolerance for faults but makes achieving consensus more difficult, potentially slowing block production or requiring more communication rounds.
• Lower Threshold (e.g., 1/4): Makes consensus easier and faster but reduces the network's tolerance for malicious actors. Protocol designers must choose this parameter based on their validator set size, desired security model, and performance requirements.

The correction threshold defines the boundary for slashing conditions in Proof-of-Stake (PoS) networks. Validator actions that could only succeed if the threshold were violated are considered attacks and are slashed.

• Example - Double Signing: If a validator signs two different blocks at the same height, this is detectable evidence of malice. The protocol relies on the assumption that less than 1/3 of stake would perform this attack simultaneously; otherwise, slashing alone cannot protect the chain.

In Nakamoto Consensus (used by Bitcoin), there is no explicit, instant correction threshold for safety. Instead, security is probabilistic and based on the honest majority of hashing power assumption. Transactions become increasingly irreversible as more blocks are mined on top of them (through proof-of-work). This contrasts with BFT systems, where the correction threshold provides instant, deterministic finality as long as the adversarial stake remains below the defined limit (e.g., 33%).

Byzantine Fault Tolerance (BFT) is the property of a distributed system to reach consensus correctly even if some participants act maliciously or arbitrarily. The Correction Threshold is a specific parameter within BFT protocols, defining the maximum proportion of faulty or adversarial nodes the system can tolerate while still guaranteeing safety and liveness. Key protocols include:

• Practical BFT (PBFT): The foundational protocol for permissioned systems.
• Tendermint BFT: Powers Proof-of-Stake chains like Cosmos.
• HotStuff: The basis for DiemBFT and its variants.

Finality is the guarantee that a committed block cannot be reverted or changed. The Correction Threshold is intrinsically linked to finality, as it mathematically defines the point at which a block is considered irreversibly finalized. In BFT-based Proof-of-Stake (PoS) chains:

• Blocks achieve instant finality once pre-commits exceed the threshold.
• This differs from probabilistic finality in Proof-of-Work, where reversals are possible but become exponentially unlikely.

The Validator Set is the group of nodes responsible for proposing and committing new blocks in a Proof-of-Stake network. The security of the Correction Threshold depends entirely on the composition and economic security of this set. Key considerations include:

• Voting Power: Often tied to the amount of stake bonded.
• Slashing: Penalties for validators who violate protocol rules (e.g., double-signing).
• Liveness vs. Safety: The threshold ensures safety (no conflicting blocks) is maintained even if liveness (ability to produce new blocks) is temporarily halted.

A 2/3 + 1 majority (or >2/3) is the most common expression of the Correction Threshold in BFT consensus. It represents the minimum supermajority of honest validator voting power required for safety. The math ensures:

• Two conflicting blocks cannot both achieve this threshold.
• The network can tolerate up to f faulty validators out of 3f + 1 total.
• This creates a clear cryptographic boundary between a "proposal" and a finalized "decision."

The Fork Choice Rule is the algorithm nodes use to select the canonical chain when multiple valid forks exist. In BFT protocols with a Correction Threshold:

• The rule is simple: choose the chain with the first block that received a commit signature from >2/3 of the validator set.
• This contrasts with the longest-chain rule used in Nakamoto Consensus (Bitcoin), where the "heaviest" chain is determined by accumulated Proof-of-Work.

Accountable Safety is a strong security property enabled by the Correction Threshold and cryptographic signatures. If the protocol's safety is broken (e.g., two conflicting blocks are finalized), it is possible to cryptographically identify the malicious validators who signed both blocks. This enables:

• Slashing: Automatic punishment of provably malicious actors.
• Transparent Security: The exact set of faulty validators is exposed, strengthening the system's trust assumptions.