Decentralized Systems · Proof of Stake

Key Question

How does Ethereum’s Beacon Chain implement proof-of-stake for a 500,000+ validator set?

Deep Dive

Ethereum switched from PoW to PoS in September 2022 via “The Merge.” The Beacon Chain — Ethereum’s consensus layer — coordinates over 500,000 active validators without imploding. The design is a marvel of committee-based cryptography.

Validator entry: To become a validator, you deposit 32 ETH into the deposit contract. The Beacon Chain processes these deposits and activates validators in batches. There is no limit on validator count — more validators means more decentralization but slower consensus.

Time is divided into two units:

Epoch (32 slots ≈ 6.4 minutes)
┌─────────────────────────────────────────────────────────────┐
│ Slot 0  │ Slot 1  │ Slot 2  │  ...  │ Slot 30 │ Slot 31    │
│ (12s)   │ (12s)   │ (12s)   │       │ (12s)   │ (12s)      │
└─────────┴─────────┴─────────┴───────┴─────────┴────────────┘
    ▲           ▲
    │           │
  Proposer   Committee attests
  proposes    to the block
  a block

Each slot (12 seconds) is one opportunity to produce a block. One validator is pseudorandomly chosen as the slot’s proposer. A committee of validators is assigned to attest (vote) on the block. Each epoch (32 slots) shuffles the validators and reassigns committees.

Committee selection uses a public random beacon derived from RANDAO (each proposer reveals a random number, and they’re combined). This gives a source of unbiased randomness — as long as at least one proposer is honest. The validator set is split into committees of size 128 (minimum), ensuring no single committee can be dominated by a small attacker.

Casper FFG Finality: Every epoch, validators vote on a checkpoint (the first block of the epoch). If two-thirds of the total stake attests to the same checkpoint pair, that pair is “finalized” — it can never be reverted.

Checkpoint finalization:

Epoch N                 Epoch N+1
┌──────────┐            ┌──────────┐
│ Checkpoint│◄──2/3 votes──►│ Checkpoint│
│    X     │            │    Y     │
└──────────┘            └──────────┘
     │                       │
     └──── justified ────────┘
              │
        finalized (both X and Y)

If the chain fails to finalize for four epochs, the network initiates a “leak” that gradually reduces the stake of validators who are offline, allowing the chain to recover.

LMD-GHOST fork choice: When a validator needs to decide which block to build on, it runs LMD-GHOST (Latest Message Driven Greediest Heaviest Observed SubTree). Starting from the most recent finalized checkpoint, it walks the tree of attestation weights, always choosing the branch with the most accumulated attestation weight. The heaviest chain wins.

Slashing conditions exist for two specific misbehaviors:

Double vote: Signing two attestations for the same target epoch.
Surround vote: Signing an attestation whose source/target range encloses another attestation’s range (trying to change history).

The penalty for slashing is severe: the validator is forcibly ejected and loses up to 1 ETH plus a third of their effective balance.

Check Your Understanding

How many seconds are in one epoch on the Beacon Chain?
If there are 100,000 validators and each committee has 128 members, how many committees exist per slot?
What is RANDAO and why is it needed?

The “So What?”

Ethereum’s Beacon Chain is the largest production PoS system ever built. Its design — committees, finality gadgets, and fork choice rules — became the reference architecture for modern PoS. Every PoS project since 2022 either follows this model or explicitly explains why it deviates.

✏️ Exercises

Proof of Stake & Modern Consensus: Exercises

Exercise 1: Nothing-at-Stake and Slashing

Consider a proof-of-stake system with 10 validators, each with 10% of the total stake. At block height 100, a network partition occurs: 5 validators see fork A, and 5 see fork B. Under a naive (no slashing) PoS design, explain:

What each validator would do
What happens to the two forks over time
How adding a slashing condition that punishes double-signing changes the outcome

Exercise 2: Ethereum Committee Calculation

The Ethereum Beacon Chain uses a fixed committee size of 128 validators per slot. A validator is assigned to exactly one committee per epoch. Given:

Total active validators: 100,000
Slots per epoch: 32
Committee size: 128

Calculate:

How many validators are actively attesting in each slot?
How many committees exist per slot?
How often does each validator attest per epoch (on average)?
What fraction of total validators attests per slot?

Exercise 3: Comparing Committee Selection

Consider three protocols:

Ethereum: Committees selected via RANDAO (public randomness, all validators partitioned into fixed-size committees each epoch)
Tendermint: No committees — every validator votes on every block
Algorand: Committees selected via VRF (private randomness, each user independently computes their eligibility)

Answer:

Which protocol has the lowest communication overhead for selecting a committee? Why?
Which protocol is most vulnerable to adaptive corruption (attacker can corrupt validators mid-consensus)? Why?
For each protocol, estimate the fraction of total validators that participate in each block’s consensus. Is it all validators, a random subset, or a fixed subset?

👁️ View Solutions

Proof of Stake & Modern Consensus: Solutions

Exercise 1 Solution

Without slashing:

Each validator would sign blocks on whichever fork they see. The 5 on fork A sign A’s blocks; the 5 on fork B sign B’s blocks.
Both forks grow at the same rate (5 validators each). Neither fork outpaces the other. When the partition heals, all 10 validators see both forks. Since there’s no cost to signing both, each validator could sign on both forks, collecting rewards from whichever one ultimately wins. The forks never naturally resolve — the system is deadlocked.
Additionally, if validators can “hedge” by signing both, they have no incentive to pick one fork over the other.

With slashing (penalty for signing conflicting blocks at the same height):

During the partition, validators on fork A sign A’s blocks. Validators on fork B sign B’s blocks.
When the partition heals, each validator sees both forks. They MUST pick one. If they sign a block on both forks at the same height, they get caught (the two signatures prove equivocation) and lose their entire stake.
Since each validator will only sign one fork, the fork with more validators (or more accumulated stake-weight) will pull ahead. The smaller fork is abandoned, and consensus is restored.

Exercise 2 Solution

Given:

Total validators: 100,000
Slots per epoch: 32
Committee size: 128

Step 1 — Validators attesting per slot: Each slot has multiple committees of 128 validators. The total validators attesting per slot is: Total validators / Slots per epoch = 100,000 / 32 = 3,125 validators per slot

Step 2 — Committees per slot: Validators per slot / Committee size = 3,125 / 128 = 24.4

So there are approximately 24-25 committees per slot, each with 128 validators.

Since committees must be whole numbers: Ethereum assigns exactly 24 or 25 committees per slot depending on the epoch. Some validators may not be assigned every epoch (they “skip” a slot).

Step 3 — Attestation frequency per validator: Each validator attests exactly once per epoch (they’re assigned to one specific slot and one committee). Average: 1 attestation per epoch = 1 per 32 slots

Step 4 — Fraction attesting per slot: 3,125 / 100,000 = 3.125% of all validators attest each slot

Exercise 3 Solution

1. Lowest communication overhead for committee selection:

Algorand has the lowest overhead. Committee selection is done locally via VRF — each user computes a VRF with their secret key and the seed. No messages are exchanged to form the committee. The user simply knows they’re selected and includes their VRF proof in their first message.

Ethereum requires a distributed random beacon (RANDAO) which involves all validators contributing randomness over an entire epoch. Tendermint doesn’t select committees (everyone votes), so the overhead is zero for selection but maximal for voting.

2. Most vulnerable to adaptive corruption:

Tendermint is most vulnerable. Since the validator set is fixed for a long period, an attacker can observe who the validators are and corrupt them between rounds. In Algorand, each committee is freshly selected by VRF, so an attacker cannot predict who will be on the next committee until they reveal themselves. Ethereum is intermediate: committees rotate per epoch, giving a window for corruption.

3. Fraction of validators participating per block:

Protocol	Fraction participating	Type
Tendermint	100%	All validators, every block
Ethereum	~3.125% (see Ex 2)	Fixed-size committee per slot
Algorand	~0.1-1% (adjustable via threshold)	Random VRF-selected subset

Tendermint uses all validators for maximum security at the cost of O(n²) communication. Ethereum uses fixed-size committees to scale to 500K+ validators. Algorand uses VRF-based random subsets to get the best of both worlds: scalable but unpredictably selected.