LibraryConsensus2020Design paperCorpus record
Combining GHOST and Casper
Gasper. Vitalik Buterin, Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Danny Ryan, Juhyeok Sin, Ying Wang and Yan X. Zhang.
An idealised proof-of-stake protocol that pairs a GHOST-style fork choice with Casper FFG finality. The paper is the design argument for Ethereum's beacon chain, not a status report on a later client or a later outage.
Gasper is a proof-of-stake rule in two layers. LMD GHOST picks a chain from validators' latest votes. Casper FFG finalises a checkpoint when a supermajority links it back to an earlier one. The paper is an idealisation of a beacon chain, not a client release.
The five-minute read
Latest vote, not every vote
LMD means only a validator's most recent attestation weighs on the fork choice. An old vote does not keep pulling the chain after the validator has moved on.
Heaviest subtree
From a justified point, the fork choice walks toward the child with the most stake behind it. That is GHOST, applied to latest messages, not to every block ever produced.
Finality is a separate object
A checkpoint becomes justified, then finalised, under the Casper FFG linking rule. Blocks between checkpoints are not final just because the fork choice currently prefers them.
One third is still the line
The safety argument needs fewer than one third of the stake to be Byzantine. A larger coalition can finalise conflicting checkpoints. The paper does not soften that bound.
One action, walked through
- Validators lock stake and are scheduled to attest.
- Each attestation is a vote for a head and for a checkpoint link.
- A node runs LMD GHOST to decide which head to build on.
- When a supermajority links two checkpoints, the earlier one can finalise under the FFG rule.
- A validator who tries to finalise two conflicting histories is the slashing case the protocol is built around.
The argument, unpacked
Fork choice is not finality
A product that shows one 'confirmed' badge for both objects is mixing them. The paper's whole point is that they are different mechanisms with different assumptions. Reorgs can still happen above the last finalised checkpoint.
Idealised is a warning
The authors describe Gasper as an idealised beacon chain. Later parameter changes, later fork-choice patches, and later client bugs are not settled by the 2020 theorems.
What has to be true
- Stake weights are the voting weights. The paper does not audit how the stake was acquired.
- Clocks and network delay sit inside the liveness assumptions. Safety of finality is the tighter claim.
- Fewer than one third of stake violates the finality rule. The complementary set follows it.
- Slashing is enforced by the clients that run the rule. A paper does not slash anyone by itself.
What happened after the paper
Ethereum's proof of stake took this shape: a GHOST-style fork choice plus FFG checkpoints. The paper remains the citation for that combination. It is not a citation for a fee level, a staking return, or any particular client's uptime.
What to check before you use the idea
- Is the badge 'head' or 'finalised'?
- What fraction of stake can finalise a conflict, according to the text?
- Which assumptions are synchrony, and which are honesty?
- Is the citation the 2020 paper or a later specification?
Terms
- LMD GHOST
- A fork-choice rule that follows the heaviest subtree of validators' latest messages.
- Finalised checkpoint
- A block that Casper FFG will not revert without a large fraction of stake provably violating the rule.
The problem the paper names
A fork-choice rule tells a node which chain to extend. A finality gadget tells a node which checkpoints it must never revert. The paper asks how to run both without the two rules contradicting each other.
What the design proposes
- Validators stake and attest. The latest attestation from each validator is the one that counts.
- LMD GHOST walks the heaviest subtree of those latest messages.
- Casper FFG finalises a checkpoint when a supermajority links it to a previous justified checkpoint.
How the mechanism is specified
- Safety of finality is the Casper argument: two conflicting checkpoints cannot both gather a supermajority if less than one third of stake is Byzantine.
- The fork choice is how the chain grows between those checkpoints. It is not itself finality.
- The paper proves safety and forms of liveness under stated synchrony and honesty assumptions. A deployed network can violate the assumptions.
What this page does not treat as proven
- This is an idealisation of a proposed beacon chain. It is not a description of every later Ethereum fork.
- A finalised checkpoint is a protocol object. It is not a legal settlement and not a price.
- Slashing rules in the paper are part of the incentive story. They are not a yield.
Why a venture studio still reads it
When a pitch says 'Ethereum consensus', ask which part is the fork choice and which part is the finality gadget, and what happens if more than one third of the stake goes offline.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.