Attestations & LMD-GHOST Fork Choice

The previous page — Slots, Epochs & Committees — set up the stage: time is diced into 12-second slots, 32 slots make an epoch, and each slot a small, unpredictable committee of validators is on duty. We know who speaks and when. What we have not answered is what they say and how their words add up to a decision.

This page is that decision. Every slot, the validators on duty don’t just watch the proposer — they vote, and the object they sign is called an attestation. Those votes are the raw material of two different jobs: choosing the current head of the chain (fork choice, this page) and eventually declaring blocks irreversible (finality, the next page). Here we build the first job from first principles: what a vote contains, how thousands of them compress into one signature, and how the rule called LMD-GHOST turns a pile of votes into a single answer to the only question a node building the next block actually cares about — what do I build on now?

The problem: many honest nodes, many candidate heads

Untrusting strangers running the same chain will, briefly and constantly, disagree about the tip. Not because anyone is cheating — because the network is not instantaneous. A proposer publishes a block; it reaches Tokyo before it reaches São Paulo. Two proposers in adjacent slots might each build on a different view. A validator who was offline for a second reappears with a stale picture. At any instant, the honest network holds a small tree of candidate blocks, not a single line:

            ┌─ B (slot 5) ─ D (slot 6)
   A ───────┤
   (slot 4) └─ C (slot 5) ─ E (slot 6) ─ F (slot 7)

Both B and C are valid children of A. Which subtree is the chain? In Bitcoin’s proof-of-work, the answer was mechanical: follow the branch with the most cumulative work, because work is a physical cost an attacker cannot fake. Ethereum’s proof-of-stake has no work to count. It counts something else: votes, weighted by stake. The rule that does the counting is LMD-GHOST, and the votes it counts are attestations.

What an attestation actually contains

An attestation is a validator’s signed vote, and it is doing double duty. A single signed message carries three linked claims:

   Attestation (one validator's vote)
   ┌────────────────────────────────────────────────┐
   │ beacon_block_root : "the head I see is  X"      │  → fork choice  (this page)
   │ source            : "last justified checkpoint" │  ┐
   │ target            : "the epoch checkpoint I     │  ├ finality
   │                      vote to justify"           │  ┘  (next page)
   │ slot / committee_index : where & when I'm on duty│
   │ signature (BLS)   : proof this is really me     │
   └────────────────────────────────────────────────┘

• The head-block vote (beacon_block_root) is the fork-choice payload: “the tip of the chain, as I currently see it, is this block.” This is the vote LMD-GHOST tallies.
• The source and target checkpoints are the finality payload: a link from the last justified checkpoint (source) to the checkpoint this validator wants to justify (target). We spend the whole next page on these; here just note that the same signature carries both, so one message serves both machines.

The crucial mental model: an attestation is not a transaction and it is not a block. It changes no account balances. It is pure opinion, cryptographically stamped — a validator saying “here is what I believe the chain looks like, and I am staking my reputation (and, if I lie provably, my capital) on it.”

Aggregation: why thousands of votes fit in one signature

Here is a scaling problem that would sink the whole design if left naive. A committee can hold hundreds of validators; across a full epoch, hundreds of thousands of validators attest. If every attestation had to travel the network and be verified individually, the consensus layer would drown in signatures.

The saving grace is that most attestations in a slot are identical in content. Every honest validator on the same committee, seeing the same head, votes for the same beacon_block_root, the same source, the same target. Only their identities and signatures differ. Ethereum exploits this with BLS signatures, which have a property ordinary signatures (like Bitcoin’s ECDSA) lack: they add up.

   1000 validators, same vote content V:

   naive:      sig₁, sig₂, … sig₁₀₀₀   → 1000 signatures to ship & verify
   aggregated: sig₁ ⊕ sig₂ ⊕ … ⊕ sig₁₀₀₀ = ONE signature over V
               + a bitfield marking WHICH 1000 signed

An aggregate signature is a single ~96-byte object that a verifier checks once against the combined public keys of everyone who signed. Attached to it is a participation bitfield — one bit per committee member — recording exactly who is included. So a thousand identical votes compress to one signature plus a small bitmap, and the verifier learns both “this vote is authentic” and “these specific 1000 validators cast it” from a single check. This is what makes committee-scale voting — and, ultimately, a validator set in the hundreds of thousands — computationally feasible at all.

By the numbers — the compression aggregation buys

Suppose a committee of 400 validators all attest to the same head in a slot.

   Individual attestations
     signatures to verify : 400
     BLS pubkey ops       : ~400 pairings

   After aggregation
     signatures to verify : 1   (one aggregate)
     bitfield             : 400 bits = 50 bytes marking who signed
     pubkey ops           : combine 400 keys → 1 pairing check

The network still needs individual attestations briefly (so aggregators can collect them), but what gets gossiped widely and stored is the aggregate. With hundreds of thousands of active validators as of 2024, aggregation is not an optimization — it is the only reason the math closes. Treat exact committee sizes as protocol parameters that can change; the durable point is that BLS turns N identical votes into one check plus N bits.

LMD-GHOST: picking the head by stake-weight

Now the payoff. A node has a tree of candidate blocks and a pile of attestations, each a head-vote weighted by the attesting validator’s stake. It needs one answer: which leaf is the head? The algorithm is LMD-GHOST — Latest Message Driven, Greediest Heaviest Observed SubTree. Unpack the name and you have the whole rule.

GHOST: heaviest subtree, not longest chain

Start at a block everyone agrees on (the last justified checkpoint — the “root” of the fork choice). At each fork, do not ask which branch is longer. Ask which branch has more accumulated attestation weight in its entire subtree — the sum of the stake of every validator whose latest vote points anywhere inside that branch. Walk greedily toward the heavier subtree, fork after fork, until you reach a block with no children. That leaf is the head.

   Votes (stake-weight) sitting under each block:

                     A                    walk from A:
                   /   \                   subtree(B) weight = 40
       weight 40  B     C  weight 90       subtree(C) weight = 90  ← heavier
                 |     / \                  → go to C
                 D   E     F
              (10)  (30)  (60)             at C: subtree(E)=30, subtree(F)=60
                                            → go to F  → F is the head

Note what “heaviest” counts: all the votes in the subtree, even ones cast for E count toward C because E descends from C. That is the “GHOST” insight (borrowed and adapted from a 2013 proposal of the same name): a vote for any descendant is implicitly a vote for the ancestor. This makes the head robust — a proposer can’t win by racing out a long thin chain; it wins by having the most stake pointing into its history.

Contrast with proof-of-work sharply, because this is the heart of the difference:

	Proof-of-Work (Bitcoin)	LMD-GHOST (Ethereum PoS)
The head is…	tip of the most-cumulative-work chain	leaf of the heaviest-stake-weighted subtree
A “vote” is…	a mined block (costs energy)	an attestation (costs a signature)
What accumulates	hash work, along one chain	attestation stake, across a subtree
Attacker must…	out-compute the network’s hashpower	control a stake supermajority (and risk slashing)
Longer chain wins?	effectively yes (more work)	no — heavier subtree wins, length is irrelevant

LMD: only your latest message counts

The “Latest Message Driven” half is a rule about which of a validator’s votes to count. A validator attests every epoch; over time it produces many head-votes. Fork choice keeps only each validator’s single most recent attestation and discards the rest. Your vote in epoch 100 replaces your vote in epoch 99 — you get exactly one live opinion in the tally at any moment.

Why? Two reasons, both first-principles:

1. A stale vote is a wrong vote. The chain you saw an hour ago may no longer be the chain. Your latest message is your best current belief; older ones are noise.
2. It bounds an attacker’s leverage. If old votes stacked up, a validator could accumulate influence by voting many times. “Latest message only” caps every validator at one unit of stake-weight in the fork choice, ever — you cannot vote twice for the same branch to make it look heavier.

   validator V's attestations over time:

     epoch 98 → head X     ┐
     epoch 99 → head Y     ├ superseded, ignored by fork choice
     epoch 100 → head Z    ┘ ← only THIS counts (V's latest message)

So the full rule reads: tally each validator’s latest head-vote, weight it by that validator’s stake, and greedily follow the heaviest subtree to a leaf. That leaf is the canonical head every honest node converges on — and the block the next proposer builds on.

Under the hood — proposer boost and the reorg it prevents

There is a subtle timing gap LMD-GHOST alone leaves open. A block is proposed at the start of a slot, but its attestations don’t arrive until partway through. For those first seconds the fresh block has zero accumulated weight, so a malicious next-proposer could ignore it and build a competing block on its parent — a reorg that erases an honest block.

Ethereum patches this with proposer boost: for the duration of its slot, a timely block is granted a temporary chunk of extra fork-choice weight (a fraction of a slot’s total committee stake). That synthetic weight is enough to defend an honest, on-time block against being reorged before its real attestations land, and it evaporates once the slot ends and genuine votes have accumulated. It is a small, load-bearing example of a recurring theme: fork choice is not just “count votes,” it is “count votes while defending against an adversary who knows the counting rule.”

Fork choice is fast and probabilistic — finality is not

One boundary is worth drawing sharply, because conflating the two is the most common confusion in this Part. Fork choice and finality are different questions with different answers.

   FORK CHOICE (this page)          FINALITY (next page)
   ─────────────────────────         ─────────────────────
   "What do I build on NOW?"         "What can NEVER be reverted?"
   answered every slot (12s)         answered every ~2 epochs (~13 min)
   fast, cheap, probabilistic        slow, expensive, absolute
   can change as votes arrive        once final, only a >⅓ slashing
                                      attack could undo it

LMD-GHOST gives you a head right now, updated continuously as attestations flow in — but that head is only probabilistically settled. A block near the tip could still be reorganized if the network’s view shifts. It is the live, working answer, exactly what a proposer needs. Finality, built from the same attestations’ source/target votes via Casper FFG, is the permanent answer: a supermajority link that makes reverting a block economically suicidal. Fork choice keeps the chain moving; finality makes its past irreversible. The next page is entirely about the second machine — and you’ll see it runs on the very votes you just learned to tally here.

It actually happened — the May 2023 finality incidents

On 11–12 May 2023, the Ethereum mainnet stopped finalizing for two brief stretches (roughly 25 and 8 minutes) — the first such events since The Merge. A surge of attestation load, triggered by a bug in how some consensus clients handled old attestations, overwhelmed those clients and dropped the participating stake below the two-thirds needed to finalize. Crucially, the chain kept producing blocks the whole time — LMD-GHOST fork choice never stopped picking a head, so transactions kept confirming. What paused was finality, not liveness. The incident is the cleanest possible illustration of the boundary this page draws: fork choice (which block to build on) and finality (which block is irreversible) are separate mechanisms, and one can degrade while the other holds. Client teams shipped fixes and diversified attestation-handling logic in response. Treat the exact durations as reported figures; the lesson — fork choice ≠ finality, and they can fail independently — is durable.

The architect’s lens

• Why does it exist? Because an honest, distributed network is always briefly disagreeing about the tip, and proof-of-stake has no cumulative work to break the tie. LMD-GHOST is the tie-breaker: a deterministic rule every node runs to converge on one head from the same pile of stake-weighted votes.
• What problem does it solve? “What do I build on now?” — the fast, continuous choice of a canonical head, so the chain keeps moving and every honest proposer extends the same history instead of forking it further.
• What are the trade-offs? The head is only probabilistic — it can reorg near the tip until finality locks it in. Counting votes also demands defenses (proposer boost, slashing) against an adversary who knows the rule, and the whole thing leans on BLS aggregation to stay computationally feasible.
• When should I avoid it? Never as a substitute for finality: if you need “this payment can never be reversed,” fork choice is the wrong tool — wait for the finalized checkpoint, not the current head.
• What breaks if I remove it? The network keeps many candidate heads and never converges; proposers build on divergent tips, the chain fragments into competing forks, and there is no shared answer to “what is the current state of the world computer?” — the exact agreement this whole book is about.

Check your understanding

1. An attestation is described as doing “double duty.” What are the two jobs, and which field of the attestation serves each?
2. LMD-GHOST chooses the head by “heaviest subtree,” not “longest chain.” Explain the difference, and why a vote for a deep descendant block still counts toward its ancestor.
3. What does the “LMD” (Latest Message Driven) part of the rule discard, and give two reasons the protocol only counts each validator’s latest head-vote.
4. Why is BLS signature aggregation essential rather than merely convenient? What two things does a verifier learn from checking a single aggregate signature plus its bitfield?
5. The page insists fork choice and finality are different questions. State each question in your own words, and explain how the May 2023 incident demonstrated that one can fail while the other keeps working.

Show answers

1. Fork choice and finality. The beacon_block_root (head-block vote) serves fork choice — it’s the vote LMD-GHOST tallies. The source and target checkpoint votes serve finality — they form a link from the last justified checkpoint to the one being voted to justify. One BLS signature carries all of them, so a single message feeds both machines.
2. Longest chain counts block depth; heaviest subtree counts the total stake-weight of attestations pointing anywhere inside a branch. A vote for a descendant counts toward its ancestor because the descendant can only exist if the ancestor does — voting for the child is implicitly endorsing the whole history above it. This means a proposer can’t win by racing out a long thin chain; it wins by having the most stake behind its history.
3. LMD discards every one of a validator’s head-votes except the most recent, so each validator contributes exactly one live opinion. Reasons: (a) a stale vote reflects a chain view that may no longer hold — your latest message is your best current belief; and (b) it caps each validator at one unit of fork-choice weight ever, so no one can inflate a branch by voting for it repeatedly.
4. It’s essential because hundreds of committee members (and, across an epoch, hundreds of thousands of validators) cast identical votes; verifying them individually would drown the consensus layer. BLS lets those combine into one ~96-byte aggregate. From one check the verifier learns (a) that the combined vote is authentic, and (b) from the participation bitfield, exactly which validators signed.
5. Fork choice asks “what do I build on now?” — a fast, continuous, probabilistic choice of head. Finality asks “what can never be reverted?” — a slow, absolute guarantee. In May 2023, Ethereum stopped finalizing for a few minutes when participating stake dropped below the two-thirds threshold, yet LMD-GHOST kept picking a head and blocks kept being produced — liveness held while finality paused, proving the two mechanisms are separate and can fail independently.