Goldfish: the forgetful fork-choice
In a previous post, we explained how LMD-GHOST worked. This post is about its problems, and how Goldfish fixes them.
Latest Message Driven GHOST (LMD-GHOST) is the fork-choice rule of Ethereum's beacon chain. Balancing attacks were found, exploiting a lack of coordination inherent in the algorithm, so a patch was added to make it safer. However, it also made the algorithm more complex, with the consequent difficulty to understand it, implement it, and formally prove its properties.
Since the merge, multiple new algorithms were created, each one a possible replacement for LMD-GHOST. Goldfish is one of those. It comes from Goldfish: No More Attacks on Ethereum?!, designed as a drop-in replacement for LMD-GHOST: same fork-choice tree, same proposer/committee structure, two small changes to how messages are counted. The result is a protocol simpler than the unpatched original and safer than the patched version.
The state of LMD-GHOST
A slot in LMD-GHOST has two phases: a Propose phase at the start of the slot, followed by a Vote phase. Honest voters don't coordinate during the Vote phase; each one runs fork-choice on its own local view and broadcasts the result. If those views disagree, the votes split.
This lack of coordination gives way to balancing attacks. In them, an attacker delivers conflicting votes to different honest validators, splitting them fifty-fifty across two competing forks. Since each half of validators see half the network voting for their chain, they never switch, stalling consensus. By delivering more conflicting votes in the following slots, the attacker can keep this split live indefinitely.
This attack was patched in the spec, through the addition of a proposer boost. This boost tries to increase validator coordination by temporarily giving the current proposer's block extra fork-choice weight. However, the boost is large, so an attacker controlling the proposer slot gets disproportionate power. Under low participation, its weight dominates fork-choice, and the proposer can change the network's view at will.
The patched LMD-GHOST works in production. It's also hard to reason about, hard to formally verify, and hard to extend. Here's where Goldfish comes in.
Goldfish's two ideas
Goldfish keeps the GHOST fork-choice rule and the proposer/committee structure. It changes two things: how votes enter a validator's local view, and how long they stay relevant.
The first is message buffering, also known as view-merge. Incoming votes land in a buffer, not the local block-vote tree. The validator doesn't consider them yet for its view, and merges them in only when the slot's proposer relays its block. Every honest voter in a slot adopts the proposer's view through its block's body before voting, an act of active coordination.
The second is vote expiry. During a slot, only votes from the previous slot count toward fork-choice. This replaces the LMD characteristic of LMD-GHOST, in a way that makes it so the attacker can't hoard old votes and release them later, nudging the network's view.
The two ideas protect validators from the balancing attack. Message buffering lets honest voters rally behind the proposer's view, so the attacker can't split them across competing subtrees. Vote expiry keeps the attacker from revealing votes from long-past slots, because old votes don't count.
Two simple ideas make for a simple algorithm.
The proof, informally
As a proof of its simplicity, we can make an informal argument for its validity:
When an honest validator proposes, every honest voter sees the proposal and votes for the block, since they all share the proposer's view. In the next slot, fork choice counts only the previous slot's votes, and those are all on this block's chain. Honest voters outnumber the attacker, so the chain wins, and the next slot's honest voters back a descendant. The same happens the slot after, and the slot after that. Once honest voters vote for a block, they keep voting for its descendants.
Honest proposers come around often: at least one in every few slots, with high probability. Their blocks stay canonical, making the algorithm reorg-resilient. From that follows its safety and liveness.
How Goldfish works
A Goldfish slot has three phases: Propose, Vote, and Confirm. Each validator keeps two pieces of state: a buffer of received messages, and a block-vote tree.
In Propose, an eligible proposer merges its buffer into its block-vote tree, runs fork-choice using the previous slot's votes to pick a parent, and broadcasts a new block together with votes from the merged tree.
In Vote, every validator merges the proposed block with votes into its own tree. Eligible voters then run fork-choice on it (using the previous slot's votes, since nobody has cast current-slot votes yet) and broadcast a vote for the resulting tip. Here's where view-merge/message buffering shines: if the proposer is honest, every honest validator now sees the same tree and votes for the same block.
In Confirm, every awake validator merges its buffer one more time, runs fork-choice using the just-cast current-slot votes, and outputs the current chain. Here we can choose a parameter κ for finality. The outputted chain minus the last κ slots are the confirmed ledger. Anything older than κ slots can be considered final.
The simplicity of the algorithm brings us additional composability, allowing for safe subsampling and optimistic fast confirmations.
Subsampling
Goldfish doesn't require every validator to vote in every slot. Each slot's voting committee is a random subsample of the validator set, chosen by lottery. With the committee size being a smaller sample of the validator set, message complexity stays flat as the validator set grows. Subsampling also defends against adaptive corruption: the attacker can't target voters in advance, since nobody knows who's on the committee until someone reveals a winning ticket. It pairs well with vote expiry, since validators buffer at most one slot's worth of committee votes, which keeps message buffering tractable at scale.
Optimistic fast confirmation
Goldfish adds an optional fourth phase, Fast-Confirm, between Vote and Confirm. If a block collects votes from a three-quarters supermajority of voters in its own slot, validators confirm it on the spot, with no κ-slot wait. Under high participation with an attacker bounded by one-quarter, fast confirmation delivers constant-latency finality from proposal. If conditions degrade, the protocol falls back to the standard κ-deep rule.
Simpler and safer
Goldfish is simpler than the unpatched LMD-GHOST and safer than the patched version. Designing the protocol from a clear model produced both gains. Goldfish and its descendants are being considered for the future of Ethereum and leanConsensus, so expect to see more of them.
If you want to dig further:
