Fork Choice
Also called fork choice rule
Origin:
composes, HotStuff's certificate-based rule (2019), not a Nakamoto-style longest-chain rule and not a Solidus invention. Solidus status:testnet, enforced in the live engine; never yet tested against a real, adversarial fork.
A fork choice rule is how a blockchain node decides which of several competing chains to treat as canonical, whenever more than one valid-looking chain exists. Forks happen even in honest operation (two validators might briefly propose conflicting blocks at the same height before the network converges) and a node needs an unambiguous, deterministic rule for picking a winner, or different nodes could end up disagreeing forever about which chain is real.
Different consensus families answer this differently. Bitcoin's Nakamoto consensus uses "longest valid chain" (more precisely, the chain with the most accumulated proof-of-work), a probabilistic rule that gets safer the more blocks pile on top. BFT protocols like HotStuff, the family Solidus's engine implements, use a fundamentally different, deterministic approach: instead of counting blocks, they follow whichever chain is backed by the most recent Quorum Certificate (QC), a compact proof that a supermajority of the validator committee explicitly agreed on that block.
Where it comes from
The specific rule Solidus follows, extend the block certified by the highest-round QC seen so far, comes directly from the 2019 HotStuff paper by Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta, and Ittai Abraham. Solidus did not invent a new fork-choice mechanism; its consensus engine (solidus-consensus) implements this one from scratch in Rust.
How it works in Solidus's engine
Each validator tracks a highest_qc (the QC for the highest round it has seen) and a locked_qc, a safety mechanism explained further under Safety vs Liveness. A new block proposal is only accepted if it extends the block certified by highest_qc; a validator will not vote for a proposal that would fork away from that certified tip unless the proposal's own parent QC round is at least as high as its locked QC's round. In plain terms: the network converges on "whichever chain has the freshest supermajority-signed certificate," and a validator's own locked state prevents it from being tricked into voting for two conflicting histories.
Check it yourself
The public solidusnetwork/protocol repository contains a TLA+ specification of exactly this commit and fork-choice logic, along with the TLC model-checker's output, an exhaustive search across 963,033 states, including scenarios with forking and equivocating replicas, finding zero safety violations. Anyone with TLA+ tooling can re-run the check against the exact spec checked into the repo; the fork-choice code itself is in solidus-consensus::hotstuff.
Related terms: HotStuff · Quorum Certificate · View Change · Finality · BFT · Safety vs Liveness
Where it comes from
Someone else specified this. Solidus assembles it.
Every blockchain needs a rule for deciding which competing chain of blocks is "the" chain when more than one candidate exists. Nakamoto consensus (Bitcoin, 2008) answered this with the heaviest/longest-proof-of-work-chain rule. BFT protocols answer it differently, using certificates rather than accumulated work, HotStuff's rule, which Solidus's engine follows, comes from Yin, Malkhi, Reiter, Gueta, and Abraham's 2019 paper. Solidus did not design a new fork-choice rule; it implements HotStuff's.
How to check this
Running on the test network. Not mainnet.
The public solidusnetwork/protocol repository's TLA+ specification and TLC model-checker results (`tla+/TLC_RESULTS.md`) model the fork-choice and commit rule exhaustively, including forking and equivocating replicas, and report zero safety violations across 963,033 explored states. A stranger can re-run TLC against the checked-in spec.