Skip to content
Blockchain LabBlockchain LabTHE VENTURE STUDIO

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.
Evidence
Primary paper
Re-measured
No
Assumptions
4
Records linked
9

Code

Source, repository, and what is actually hosted

  • arXiv:2003.03052https://arxiv.org/abs/2003.03052
  • The source URL is not a GitHub repository. No code remote is invented.
  • Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
  • Add to a reading list

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

  1. Claim 01 · Paper model

    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.

  2. Claim 02 · Paper model

    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.

  3. Claim 03 · Paper model

    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.

  4. Claim 04 · Paper model

    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.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

  1. 01 Latest vote, not every vote

    Observation

    What the study says

    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.

    Model

    What has to hold

    Stake weights are the voting weights. The paper does not audit how the stake was acquired.

    Falsifier

    What would retire it

    Is the badge 'head' or 'finalised'?

  2. 02 Heaviest subtree

    Observation

    What the study says

    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.

    Model

    What has to hold

    Stake weights are the voting weights. The paper does not audit how the stake was acquired.

    Falsifier

    What would retire it

    What fraction of stake can finalise a conflict, according to the text?

  3. 03 Finality is a separate object

    Observation

    What the study says

    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.

    Model

    What has to hold

    Clocks and network delay sit inside the liveness assumptions. Safety of finality is the tighter claim.

    Falsifier

    What would retire it

    Is the badge 'head' or 'finalised'?

  4. 04 One third is still the line

    Observation

    What the study says

    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.

    Model

    What has to hold

    Stake weights are the voting weights. The paper does not audit how the stake was acquired.

    Falsifier

    What would retire it

    What fraction of stake can finalise a conflict, according to the text?

03 Sequence

One action, as an operating tape

  1. 01Validators lock stake and are scheduled to attest.
  2. 02Each attestation is a vote for a head and for a checkpoint link.
  3. 03A node runs LMD GHOST to decide which head to build on.
  4. 04When a supermajority links two checkpoints, the earlier one can finalise under the FFG rule.
  5. 05A validator who tries to finalise two conflicting histories is the slashing case the protocol is built around.

04 Load-bearing

The argument, and where a pitch drops it

  1. Fork choice is not finality

    The cut

    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.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    A finalised checkpoint is a protocol object. It is not a legal settlement and not a price.

  2. Idealised is a warning

    The cut

    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.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    This is an idealisation of a proposed beacon chain. It is not a description of every later Ethereum fork.

05 Register

What has to be true

  • Stake and threshold · Not re-measured

    Stake weights are the voting weights. The paper does not audit how the stake was acquired.

  • Network · Not re-measured

    Clocks and network delay sit inside the liveness assumptions. Safety of finality is the tighter claim.

  • Stake and threshold · Not re-measured

    Fewer than one third of stake violates the finality rule. The complementary set follows it.

  • Model · Not re-measured

    Slashing is enforced by the clients that run the rule. A paper does not slash anyone by itself.

06 Divergence

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.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

  5. 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

The problem it 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 the desk 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.

09 Lexicon

Terms, opened into the record

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.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

Protocols

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.