Fork Choice Rule

The classic Proof-of-Work rule where the valid chain with the greatest cumulative difficulty (often the longest chain) is chosen. This rule incentivizes miners to extend the heaviest chain, as their rewards are only secure on the canonical fork.

• Example: Bitcoin and early Ethereum.
• Security: Relies on the assumption that honest nodes control the majority of the network's hashrate.

A rule that accounts for orphaned blocks (uncles) to improve security and reduce centralization pressures. The canonical chain is the one with the heaviest subtree, where the weight of orphaned blocks is included in the calculation.

• Purpose: Mitigates the high orphan rate and security issues of the Longest Chain rule in fast-block networks.
• Adoption: The foundation for Ethereum's original Ethash consensus.

The fork choice rule for Ethereum's Proof-of-Stake (Casper FFG). Validators broadcast attestations (votes) for the head of the chain they perceive as correct. The rule selects the chain with the greatest weight of attestations from the latest message of each validator.

• Key Feature: Accounts for validator liveness and slashing conditions.
• Result: Provides finality and is resilient to certain network partitions.

A modification to LMD-GHOST that adds a temporary weight boost to a block proposed in the current slot. This helps prevent reorgs and balancing attacks where an attacker could manipulate attestation timing.

• Mechanism: The current slot's proposed block receives an additive boost to its weight in the fork choice calculation.
• Outcome: Stabilizes chain head selection, especially during the first few seconds of a slot.

The fundamental trade-off governed by the fork choice rule. Safety means two honest nodes will never finalize conflicting blocks. Liveness means the network can always produce new blocks.

• Conflict: A rule optimized for safety (requiring more votes) may slow down finality (liveness).
• Goal: A robust fork choice rule provides the optimal balance for the network's threat model.

The fork choice rule is implemented in each network client (e.g., Geth, Prysm, Lighthouse). Client diversity—having multiple independent implementations—is critical for network resilience.

• Risk: A bug in a single client's fork choice logic could cause a catastrophic chain split.
• Verification: Rules are formally specified (e.g., in Ethereum's consensus specs) and clients must adhere strictly to ensure interoperability.

The canonical chain is the one with the greatest cumulative proof-of-work. Used by Bitcoin and early Ethereum. It is a probabilistic rule where security grows with the number of confirmations.

• Mechanism: Nodes always extend the chain with the highest total difficulty.
• Key Property: Provides eventual consistency but is vulnerable to certain attacks if an attacker controls >51% of the network's hash rate.

A fork choice rule that accounts for orphaned blocks (uncles) to improve security and reduce centralization pressures in fast blockchains. It selects the chain with the heaviest subtree, weighting both main-chain and stale blocks.

• Purpose: Mitigates the security loss from high orphan rates in high-throughput chains.
• Adoption: A variant is used in Ethereum's pre-merge proof-of-work consensus.

The fork choice rule for Ethereum's proof-of-stake consensus (the Beacon Chain). It combines the GHOST concept with validator votes.

• Mechanism: Starts from the genesis block and iteratively chooses the child block with the greatest weight of attestations from the latest messages (votes) of validators.
• Goal: Provides fast finality and resilience against certain attacks, even with many validators offline.

An enhancement to LMD-GHOST implemented to defend against balancing attacks. It adds a temporary weight boost to a block proposed in the current slot.

• Function: The correctly proposed block for the current slot receives a bonus score, making it the heaviest branch and guiding honest validators to build on it immediately.
• Impact: This modification strengthens the consensus resilience of Ethereum, making it significantly harder to orchestrate certain splits.

A mechanism layered on top of a fork choice rule to provide economic finality. It uses validator deposits and slashing conditions to punish nodes that violate specific rules.

• How it works: Validators periodically vote to justify and finalize checkpoints. A block finalized by Casper FFG can only be reverted by burning at least one-third of the total staked ETH.
• Synergy: In Ethereum, LMD-GHOST is the "fork choice" that picks the head of the chain, while Casper FFG provides the finality overlay.

A classical consensus algorithm used in permissioned blockchains (e.g., Hyperledger Fabric) and as inspiration for proof-of-stake. It provides immediate, deterministic finality.

• Fork Choice: All honest nodes agree on a single chain after a three-phase voting process within a known validator set.
• Key Difference: Unlike Nakamoto consensus, it does not use longest-chain rules or proof-of-work. It requires a known, fixed set of validators and tolerates up to one-third of them being Byzantine.

The simplest fork choice rule, used by Proof-of-Work chains like Bitcoin. The valid chain with the greatest cumulative proof-of-work (i.e., the longest chain) is selected as canonical. This creates a probabilistic guarantee of finality as work accumulates.

• Mechanism: Clients always extend the chain tip with the highest total difficulty.
• Example: If two forks exist, one 6 blocks long and another 5 blocks long, all honest nodes will build on the 6-block chain.

A fork choice rule that accounts for orphaned blocks (uncles) to improve security and reduce centralization pressures. Used by Ethereum's execution layer.

• Mechanism: The chain with the heaviest subtree is chosen, weighting both main-chain blocks and valid blocks in competing forks.
• Purpose: It penalizes withholding blocks, as miners get rewards for uncles, making selfish mining less profitable. This leads to faster confirmation times and higher throughput than the simple longest chain rule.

A mechanism layered on top of a fork choice rule to provide economic finality. It uses validator deposits and slashing to punish nodes that finalize conflicting blocks.

• Relationship to Fork Choice: Fork choice (like LMD-GHOST) proposes the chain head, while the finality gadget justifies and finalizes checkpoints (every 32 blocks in Ethereum).
• Outcome: Creates two finality types: probabilistic finality from the fork choice and absolute economic finality from the gadget, making chain reorganizations beyond finalized checkpoints prohibitively expensive.

A consensus algorithm where the fork choice is determined by a voting process among a known set of validators. Used in permissioned blockchains and as inspiration for Proof-of-Stake.

• Mechanism: A leader proposes a block, and validators vote in multiple rounds. The chain advances once a super-majority (2/3+) of votes is reached for a block.
• Fork Choice Implication: Forks are rare because the protocol requires explicit agreement before proceeding. The canonical chain is simply the one with the valid super-majority commitment.

The fork choice rule directly defines a chain's security assumptions and performance characteristics.

• Time to Finality: Rules like GHOST provide faster probabilistic finality than longest chain.
• Reorg Resistance: Stronger fork choice rules (e.g., LMD-GHOST with finality) make deep chain reorganizations (reorgs) virtually impossible, protecting users and exchanges.
• Client Complexity: Implementing advanced rules like LMD-GHOST is more complex for node software but is essential for the security of modern Proof-of-Stake networks.

The property that a block or transaction is permanently settled and cannot be reverted. Fork Choice Rules are mechanisms to achieve probabilistic finality (e.g., in longest-chain PoW) or absolute finality (e.g., in BFT-style protocols).

• Probabilistic: Reversion probability decreases exponentially as more blocks are added on top (e.g., Bitcoin's 6-confirmation rule).
• Absolute: A block is finalized by a supermajority of validators, and reverting it would require slashing their stake (e.g., Ethereum's Casper FFG).

A theoretical vulnerability in Proof-of-Stake (PoS) systems where validators have no cost to validate on multiple competing chains during a fork, potentially preventing consensus. A robust Fork Choice Rule must be designed to disincentivize this behavior.

• Problem: Validators could vote for every fork to guarantee rewards, hindering chain finalization.
• Solution: Implemented via slashing conditions that penalize validators for equivocating (signing conflicting blocks/attestations), making malicious fork support economically irrational.

The process where nodes switch to a new canonical chain, abandoning blocks from the previously accepted chain. This occurs when the Fork Choice Rule identifies a heavier, competing chain.

• Cause: Typically due to network latency, a powerful mining pool, or a deliberate attack.
• Impact: Transactions in orphaned blocks become invalid, leading to potential double-spend risks. Modern protocols aim to minimize reorg depth for user experience and security.

The two fundamental guarantees of a consensus protocol, which a Fork Choice Rule must balance.

• Liveness: The protocol continues to produce new blocks (the chain makes progress).
• Safety: All honest nodes agree on the same canonical history (no two honest nodes accept conflicting blocks).

A rule favoring liveness might adopt blocks quickly, risking temporary forks. A rule favoring safety might delay decisions, risking chain halt. The design aims for optimal resilience under adversarial conditions.