Gasper: Ethereum 2.0 Consensus

On September 15, 2022, Ethereum made The Merge - the switch from Proof of Work to Proof of Stake. In a single night, a network processing billions of dollars in transactions replaced its consensus mechanism. Not one transaction was lost. How do 400,000+ validators (now over 900,000) coordinate every 12 seconds so that a network worth hundreds of billions of dollars runs without a single second of downtime? Behind this is Gasper - a hybrid of two protocols that each solve different problems and together create a system that is practically impossible to break.

• **Ethereum The Merge** - the largest consensus migration in history of a production system with hundreds of billions of dollars at stake, running on Gasper
• **DeFi and stablecoins** - Uniswap, Aave, USDC rely on Gasper finality: after finalization a transaction cannot be reversed, which is critical for financial operations
• **Liquid staking (Lido, Rocket Pool)** - protocols allowing Gasper-consensus participation without 32 ETH, controlling more than 30% of all stake
• **L2 rollups (Arbitrum, Optimism, Base)** - Layer 2 solutions inherit Gasper's security; anchors to L1 finalized blocks provide guarantees for millions of users

Предварительные знания

• Proof of Stake
• BFT Consensus: PBFT and variants

Casper FFG: Friendly Finality Gadget

In classical blockchain systems a transaction never becomes truly irreversible - it merely becomes *less and less likely* to be reverted with each new block. **Casper FFG** solves this: it adds a **finality** mechanism on top of any fork choice rule.

Casper FFG is an **overlay protocol**. It does not produce blocks itself but works *on top of* the chain selection mechanism, periodically stamping "seals of irreversibility" on it.

How does it work? Validators vote on **checkpoint pairs**: (source, target). Source is the last finalized checkpoint; target is the current checkpoint candidate. Each vote (attestation) contains:

1. **Source checkpoint** - where we "jump" from (already justified or finalized)
2. **Target checkpoint** - where we "jump" to (candidate for justified)
3. **BLS signature** of the validator confirming their vote

When validators controlling **2/3 of total stake** vote for a pair (source → target) (a supermajority link), the target receives the **justified** status.

The threshold is exactly **2/3**, not 1/2. With 1/2, two conflicting groups could simultaneously justify different branches. With 2/3 this is impossible: two sets of 2/3 inevitably overlap by at least 1/3, and that third would be slashed for double voting.

Casper FFG defines two types of violations (**slashing conditions**):

1. **Double vote** - voting for two different targets in the same epoch
2. **Surround vote** - a vote that "surrounds" another vote by the same validator (source₁ < source₂ < target₂ < target₁)

Thanks to accountable safety, if finalized blocks conflict, you can mathematically prove that at least 1/3 of validators violated the rules and deserve slashing. This makes an attack extremely expensive: the attacker would lose at least 1/3 of all staked ETH.

LMD-GHOST: choosing the correct chain

Casper FFG provides finality, but between checkpoints the network must decide which specific chain of blocks to consider canonical. For this Ethereum uses **LMD-GHOST** - Latest Message Driven Greedy Heaviest Observed SubTree.

The name is long, but each word carries meaning:

• **Latest Message Driven** - only the latest vote (attestation) of each validator is counted, not the entire history
• **Greedy** - the algorithm greedily picks the best option at each step, descending from root to leaf
• **Heaviest Observed SubTree** - at each fork we choose the branch with the greatest total weight (stake) of attestations

Key difference from **longest chain rule** (Bitcoin):

Important property of LMD-GHOST: each validator is counted exactly once ("latest message"). If a validator voted for block X and then for block Y - only the vote for Y is counted. This prevents "flip-flopping" attacks.

In Gasper **LMD-GHOST and Casper FFG work together**: LMD-GHOST handles real-time fork choice ("which block to build next?"), while Casper FFG periodically "cements" the chain, turning justified blocks into finalized.

Epochs and Slots: Ethereum's clock mechanism

Gasper divides time into fixed intervals. This is not just an organizational structure - it is the fundamental mechanism that allows hundreds of thousands of validators to coordinate without a central authority.

Each slot follows a directly defined sequence of actions:

1. **Proposer** (one validator) proposes a block. Selected pseudorandomly via RANDAO with weights proportional to stake
2. **Committee** (a group of validators) votes for the block through attestations. Each epoch the entire validator set is split into 32 committees - one per slot
3. **Aggregators** (a subset of the committee) collect attestations into aggregated signatures (BLS aggregation)

The minimum committee size is **128 validators**. This ensures statistical security: the probability that 2/3 of a committee would be malicious is exponentially small under random assignment.

Each epoch, all ~900,000+ active validators are distributed across 32 committees. Each validator attests exactly once per epoch. This creates a predictable network load:

In addition to the main committees, there are **Sync Committees** - special groups of 512 validators that rotate approximately every ~27 hours (256 epochs). Their purpose is to create compact signatures for light clients so they can verify the chain without downloading all attestations.

Proposer selection uses **RANDAO** - a decentralized random beacon. Each proposer adds their RANDAO reveal (a BLS signature of the epoch number), which is XOR-ed with the current RANDAO mix. The result is used to select subsequent proposers and shuffle committees.

Justification and Finalization

Attestations accumulate slot by slot, but the real magic happens at epoch boundaries. Here Casper FFG turns validator votes into **irreversible decisions**. The process has two stages: justification, then finalization.

Stage 1: Justification

A checkpoint (epoch boundary) becomes **justified** when a supermajority link (2/3+ votes) points from an already justified/finalized checkpoint to this checkpoint.

Stage 2: Finalization

Checkpoint **A** becomes **finalized** when one of two conditions is met:

1. **Standard finalization (k=1):** A is justified, and there is a supermajority link A → B, where B is the immediately next epoch after A
2. **Extended finalization (k=2):** A is justified, and there is a supermajority link A → C spanning one epoch (two consecutive epochs both justified)

After finalization a block **cannot be reverted** without slashing at least 1/3 of all validators. At the current amount of staked ETH (~32M ETH) this would require destroying ~10M ETH - an economically suicidal attack.

When finalization breaks: Inactivity Leak

If the network cannot reach 2/3 votes (mass validator offline), finalization stops. Gasper has a built-in self-healing mechanism - **inactivity leak**:

• Offline validators start **losing stake** quadratically over time (the longer they are offline, the faster the losses)
• After some time their share drops below 1/3, and the remaining online validators again constitute 2/3
• Finalization resumes from a new checkpoint

Real incident: Beacon Chain Finality Issues (May 2023)

In May 2023, the Ethereum Beacon Chain experienced finality issues twice. The chain kept producing blocks, but finalization paused for ~25 minutes and ~1 hour respectively. The cause was a bug in two major clients (Prysm and Teku) that caused some validators to temporarily stop attesting. This incident directly demonstrated:

• **Liveness vs Safety trade-off**: the chain kept running (liveness), but without finality (weakened safety)
• **Client diversity is critical**: if a single client controls >1/3 of the network, its bug can stop finality
• **Inactivity leak did not activate**: the issue resolved too quickly (needs 4+ epochs without finality)

Finalized means irreversible. Justified means "preliminarily approved". Do not confuse them: a transaction in a justified block can *still* be reverted (though it is extremely unlikely), while one in a finalized block cannot be reverted without destroying 1/3 of stake.

Key ideas

• **Gasper = Casper FFG + LMD-GHOST** - two protocols, one for finality (irreversibility), the other for real-time fork choice (chain selection)
• **Casper FFG** - an overlay protocol creating supermajority links between checkpoints; 2/3 stake for justified, two consecutive justified → finalized
• **LMD-GHOST** - fork choice rule: at each fork the branch with the greatest attestation weight is chosen, counting only the latest vote from each validator
• **Epoch = 32 slots × 12 sec = 6.4 min** - each validator attests exactly once per epoch; committees of 128+ validators provide statistical security
• **Finalization in 2 epochs (~12.8 min)** - deterministic, unlike Bitcoin's probabilistic "6 confirmations". Remember The Merge? It is exactly this deterministic finality that allowed the switch to PoS without losing a single transaction
• **Inactivity leak** - self-healing mechanism: offline validators quadratically lose stake until online participants reach a supermajority

Related topics

Gasper stands on the shoulders of giants - it synthesizes ideas from Proof of Stake, BFT consensus, and cryptography:

• Proof of Stake — Gasper is a concrete PoS implementation; staking, slashing, and validator selection from PoS are the foundation of Casper FFG
• BFT Consensus — Casper FFG is a BFT finality gadget; the 2/3 threshold and accountable safety follow directly from Byzantine Fault Tolerance theory
• The Merge and the future of Ethereum — Gasper is the Beacon Chain engine that after The Merge became the consensus for all of Ethereum; Danksharding and PBS are built on top of Gasper
• BLS signatures — Without BLS aggregation Gasper would not scale: 900K attestations per epoch are aggregated into compact signatures thanks to BLS

Вопросы для размышления

• Gasper trades finalization speed (12.8 min) for security (deterministic finality). Is there a fundamental trade-off between speed and finality security, or can a protocol with instant deterministic finality be built?
• During the May 2023 finality incident, two clients (Prysm and Teku) controlled >2/3 of the network. How would you design incentives so that no single client occupies >1/3?
• Inactivity leak "punishes" validators who may have gone offline through no fault of their own (internet outage, DDoS). Is this mechanism fair, and what alternatives could exist?

Связанные уроки

• dist-10-byzantine