How consensus runs
The capstone showed why proof of stake works. This is the clockwork that runs it — how a million validators with no leader take turns making one block every twelve seconds and agree on it. Slots, committees, epochs, finality, block builders, and the validator's whole life.
- proof of stake
- finality
The capstone settled why Ethereum uses proof of stake: bond real money, follow the heaviest-attested chain, and make reverting a finalized block cost a third of all staked ETH. That’s the principle. This page is the clockwork — the actual machine that turns it into running blocks.
The problem it solves is brutal: over a million validators, scattered across the planet, with no leader and no clock they share, somehow have to take turns producing exactly one block at a time and agree on which blocks count — fast enough to be usable and cheap enough that anyone can join. Watch it assemble, one fix at a time.
Chop time into slots
If any validator could publish a block whenever it liked, a million of them would constantly collide — two blocks at the same height, no way to say which came “first” without a shared clock. So invent one. Carve time into fixed slot A fixed 12-second window. Exactly one validator is assigned to propose a block in each slot; 32 slots make an epoch. s of 12 seconds, and in each slot anoint exactly one validator as the proposer — the only one allowed to make a block right then. A steady, leaderless heartbeat: one slot, one proposer, one block.
Empty slots are fine (if a proposer is offline, the slot just passes), and everyone agrees on the schedule because slots are counted from a fixed genesis time. The chain now has a tempo.
→ Step 2: pick the proposer by a lottery nobody can game.
A shared random seed: RANDAO
Generate one number the whole network trusts and can’t predict, and use it to map each slot to a proposer. That number is RANDAO A shared randomness accumulated on-chain: each proposer mixes a value (revealed from their BLS signature) into the running seed, so no single party controls the result and it can't be known far in advance. . Every proposer, as part of proposing, reveals a value derived from their signature and mixes it into a running seed. Because the final seed depends on everyone’s contribution, no single validator can steer it; because each contribution is only revealed at proposal time, it can’t be known far ahead. The seed then deterministically picks each slot’s proposer — and the committees we’re about to meet — so anyone can recompute and verify the assignment, but no one can rig it.
→ Step 3: have everyone vote on what they see.
Attestations: a vote from every validator
Agreement comes from votes, not authority. Every validator casts an attestation A validator's signed vote, cast once per epoch. It names the block it sees as the head (the LMD-GHOST/fork-choice vote) and a source-to-target checkpoint pair (the Casper-FFG/finality vote). — a signed vote that says two things at once: this is the head block I see (the fork-choice vote, which adds weight to that branch) and this is the checkpoint I consider current (the finality vote, in a moment). Fork choice then follows the branch carrying the most attesting stake, so a minority fork can never out-weigh the honest majority.
A million validators can’t all vote every slot without drowning the network, so they’re split into committee A pseudo-random subset of validators. Every validator is shuffled into exactly one committee in exactly one slot of the epoch — each slot carries one or more committees (up to 64) — so every validator attests exactly once per epoch. s — the epoch is 32 slots, and every validator is shuffled into exactly one committee in exactly one of them (a slot can carry several committees). Each validator votes exactly once per epoch, in its slot’s committee. The votes pile up as weight on the chain.
→ Step 4: turn a pile of votes into finality.
Epochs, justification, finalization
Group every 32 slots into an epoch A span of 32 slots (~6.4 minutes). Epoch boundaries carry checkpoints; finality is decided epoch to epoch. — about 6.4 minutes — and treat the block at each boundary as a checkpoint. The finality vote inside every attestation is a vote for a checkpoint. The rule (Casper-FFG) is two-step: when ≥⅔ of all staked ETH attests to a checkpoint, it becomes justified; when two checkpoints in a row are justified, the earlier one becomes finalized.
Finalized means economically irreversible: undoing it would require validators holding a third of all stake to sign two contradictory checkpoints — provable, slashable, and ruinous. In normal operation a block finalizes about two epochs (~13 minutes) after it’s proposed. That’s the number a careful merchant waits for.
→ Step 5: split proposing from building.
Proposer-builder separation
Separate the small job (propose: sign one header in your slot) from the big job (build: assemble the most valuable ordering of transactions). Specialized builders compete to construct the most profitable block they can — mempool transactions plus private order flow, optimally ordered to capture MEV Maximal Extractable Value — profit available from choosing which transactions to include and in what order. Building to capture it is specialized work, which is why it's outsourced to builders. — and bid for the right to have it proposed. A trusted relay escrows the candidate blocks and shows the proposer only the headers and bids, never the bodies. The proposer signs the highest-bid header blind — committing to it before seeing its contents — and only then does the relay release the body to the network.
A solo home staker, who could never out-build a professional shop, simply takes the best bid and earns the same. Today this runs as off-protocol MEV-Boost; folding it into the protocol — enshrined PBS — is active roadmap work, precisely because trusting relays is the soft spot.
→ Step 6: meet the validator.
Deposit, attest, exit — or get slashed
A validator is 32 ETH and a set of keys. Its life is a pipeline: deposit 32 ETH, wait in a rate-limited activation queue (so the validator set can’t lurch), then go active — attesting every epoch, proposing on the rare slot the lottery hands you. Do it correctly and on time and you earn steady rewards; miss your duties and you pay small penalties; if the chain ever stops finalizing, an inactivity leak bleeds the absent validators until the active two-thirds is restored. To leave, you request a voluntary exit, wait in the exit queue, and withdraw your stake.
And the cliff that makes all the earlier steps real: slashing The penalty for provably contradictory messages — proposing two blocks for one slot, or casting conflicting attestations. The validator is force-exited and a chunk (up to all) of its stake is burned. . Sign two blocks for one slot, or two conflicting attestations, and anyone can submit the proof; you’re force-exited and a piece of your stake — up to all of it — is burned. Every “they can’t lie without losing money” from the capstone is this: an automatic, provable, on-chain punishment.
The rest of the beacon machinery
The six steps are the spine; a handful of real mechanisms hang off them:
- The sync committee. A rotating group of 512 validators, refreshed every 256 epochs (~27 hours), signs every block header. It exists so light clients can follow the chain by checking one small, slowly-changing signature set instead of a million attestations.
- The beacon chain vs. execution. All of the above lives on the consensus layer (the beacon chain). The actual transactions and EVM execution live on the execution layer; since the Merge, each block pairs the two, and the consensus layer drives the execution layer through the engine API.
- Aggregation. Individual attestations are aggregated (BLS signatures combine into one) before going on-chain, which is what makes a million votes per epoch fit at all.
- Validator caps & consolidation. A validator’s effective balance is capped (historically 32 ETH; raised for large stakers by EIP-7251) so weight stays proportional and the set stays manageable.