Slots, Epochs & Committees
The previous page explained who the validators are: strangers who each locked 32 ETH to earn the right to help decide the chain’s history, and to lose that stake if they cheat. But a crowd of validators is not yet a consensus mechanism. Half a million people with equal votes, all shouting at once, is a mob — not agreement. Something has to give the crowd a structure: a shared clock that says when each validator acts, and a fair procedure that says which validator does what at each moment.
That structure is the subject of this page. Proof-of-stake Ethereum runs on a strict, unforgiving metronome — slots and epochs — and on each tick it hands out duties: exactly one validator is told “propose a block now,” and everyone else is sorted into committees and told “attest to what you see.” Get this scaffolding right and the next two pages — attestations and fork choice and finality — are just “what the votes mean.” This page builds the timetable those votes ride on.
The clock: slots and epochs
Section titled “The clock: slots and epochs”Everything in Ethereum consensus is measured against a clock that never stops. There are two units.
- A slot is 12 seconds. It is one opportunity to add a block to the chain — one tick of the heartbeat. In each slot, exactly one validator is given the right (and the duty) to propose a block.
- An epoch is 32 slots, so 384 seconds ≈ 6.4 minutes. The epoch is the unit over which duties are dealt out, rewards are accounted, and — as the next pages show — the chain reaches finality.
one epoch = 32 slots = 6.4 minutes ┌──────────────────────────────────────────────────────────────────┐ │ slot0 slot1 slot2 slot3 ... slot30 slot31 │ │ 12s 12s 12s 12s 12s 12s │ └──────────────────────────────────────────────────────────────────┘ │ │ │ ▼ ▼ ▼ proposer proposer proposer #A #B (one, and only one, per slot) #ZWhy these numbers? Neither is arbitrary, but neither is sacred either — they are a tuned compromise, and naming the trade is the whole point of a first-principles book:
- Why not shorter slots (faster blocks)? A block a proposer builds must physically reach the whole validator set — spread across the planet, on ordinary connections — before the attesters in that slot are due to vote on it. Twelve seconds buys enough time for a block to propagate globally, for tens of thousands of attesters to see it, and for their votes to propagate back. Shrink the slot and validators on slow or distant links start voting before they’ve seen the block, or miss the deadline entirely — the same propagation squeeze the scalability trilemma warned about, now measured in the time budget of a single slot.
- Why not longer slots? Longer slots mean the chain confirms transactions more slowly and feels sluggish. Twelve seconds is the point where “fast enough to be usable” meets “slow enough that a home validator anywhere on Earth can keep up.” It’s a decentralization dial wearing a stopwatch.
The clock is anchored to a fixed genesis time. Every node computes the current slot number purely from
its wall clock: slot = (now − genesis_time) / 12. No one announces what slot it is; every honest node
derives it independently from the same arithmetic. That shared, computed-not-declared clock is what lets
untrusting strangers agree on when it is without trusting a timekeeper.
Two duties: propose and attest
Section titled “Two duties: propose and attest”At any moment a validator is doing at most one of two jobs. Keep them cleanly separate, because the entire rest of the consensus part is built on the distinction.
- Proposing — building a block. In each slot, exactly one validator is the proposer. It gathers pending transactions (from the execution layer), packages them into a block, signs it, and broadcasts it to the network. Proposing is a rare privilege: with a million validators there are only 32 proposal slots per epoch, so most validators propose only once every few weeks.
- Attesting — voting on what you see. Every active validator attests exactly once per epoch. An attestation is a signed statement: “in slot N, the head of the chain I see is block X, and here is the checkpoint I consider justified.” Attesting is the common duty — it is how the crowd’s collective opinion about the canonical chain is measured. (What that vote means mechanically is the next page.)
PER SLOT (12s): ┌── 1 proposer ─────────► builds & broadcasts a block │ └── a slice of the validator set ──► attests (votes on the head)
PER EPOCH (32 slots): · 32 proposers total (one per slot) · EVERY active validator attests exactly once — its one vote is assigned to exactly one of the 32 slots, so the electorate is spread evenly across the whole epoch, not dumped into one slot.That last property is worth pausing on. If all million validators tried to attest in the same slot, that slot would drown in a million signatures — impossible to propagate in 12 seconds. Instead, the protocol deals each validator into exactly one slot of the epoch. Every validator votes once per epoch; the epoch’s 32 slots each carry roughly 1/32 of the electorate. The load is smeared across 6.4 minutes so no single 12-second window has to move the whole crowd’s worth of votes.
Committees: slicing the electorate
Section titled “Committees: slicing the electorate”Even 1/32 of a million validators is tens of thousands of attesters in a single slot — still too many to handle as one undifferentiated blob. So within each slot, the attesters assigned to it are further partitioned into committees.
A committee is just a subset of validators grouped together for one slot’s attestation. Ethereum aims for a fixed number of committees per slot (up to 64, one conceptually per potential shard in the original design) and a minimum committee size of 128 validators. Committees exist for two reasons, both about scaling the vote:
- Aggregation. Every validator in a committee that agrees on the same vote signs the same message. Because Ethereum uses BLS signatures, those identical signatures can be aggregated into a single signature that proves “all these validators signed this” — one signature to verify instead of hundreds. Committees are the natural grouping over which aggregation happens: a few designated aggregators per committee collect and combine their peers’ signatures.
- Bounded work. A committee is small enough that the aggregation and verification for it is cheap, and there are a bounded number of committees, so total consensus bandwidth stays within what a home node can sustain — the decentralization budget again.
ONE SLOT's attesters, partitioned into committees:
slot N attesters (~31k validators) ├── committee 0 [~488 validators] ─► aggregate ─► 1 combined attestation ├── committee 1 [~488 validators] ─► aggregate ─► 1 combined attestation ├── ... └── committee 63 [~488 validators] ─► aggregate ─► 1 combined attestation
Result: up to 64 aggregated attestations per slot instead of ~31,000 raw ones. The next proposer packs these aggregates into its block as the record of the vote.So the hierarchy top to bottom is: epoch → slots → committees → individual validators. The epoch is the accounting window; the slot is the block opportunity; the committee is the aggregation unit; the validator is the atom that signs. Every active validator sits in exactly one committee, in exactly one slot, once per epoch.
Under the hood — how a duty is actually assigned
Section titled “Under the hood — how a duty is actually assigned”Concretely, at the start of an epoch each validator can compute — for itself and everyone else — the answer
to three questions: Which slot do I attest in? Which committee am I in? Am I the proposer of any slot?
The inputs are entirely public: the list of active validator indices and a shared random seed (below). The
assignment is a deterministic function of those inputs, so every node computes the same schedule
without anyone broadcasting it. In the spec this is the shuffling — a fixed algorithm
(compute_shuffled_index, a swap-or-not shuffle) that permutes the validator indices using the seed, then
slices the permutation into slots and committees. Determinism is essential: if nodes disagreed about who
was assigned what, they’d disagree about whether a block or vote was even valid.
Pseudo-random assignment: why you can’t be targeted
Section titled “Pseudo-random assignment: why you can’t be targeted”Here is the security heart of the page. If duty assignment were predictable and controllable, the whole scheme would collapse. Consider what an attacker could do if they knew the schedule far in advance, or could choose it:
- Target the proposer. Knowing weeks ahead exactly which validator proposes slot 12,345,678, an attacker could DDoS that specific node offline right before its slot, forcing a missed block — and if they can do it slot after slot, they can grind the chain’s progress down.
- Stack a committee. If an attacker with many validators could arrange for all of their validators to land in the same committee, they could dominate that committee’s vote and aggregate a misleading attestation.
- Grind the outcome. If the party who selects the randomness could cheaply try many seeds and keep the one that favors them, they could bias every future assignment toward themselves.
The defense is that assignments are pseudo-random, derived from a seed that is (a) unpredictable far enough in advance, and (b) expensive to bias. That seed comes from RANDAO.
RANDAO — collective, hard-to-bias randomness
Section titled “RANDAO — collective, hard-to-bias randomness”The chain has no oracle it can ask for a random number, and it can’t trust any single validator to supply one honestly — a single source could always pick a number that favors itself. RANDAO builds randomness the same way the whole system builds everything else: out of many mutually-distrusting participants, so no one of them controls the result.
The mechanism, in essence:
Each proposer, when it proposes, must include a fresh RANDAO reveal (a BLS signature over the current epoch number — unpredictable until signed).
The chain mixes that reveal into the running randomness accumulator:
randao_mix ← randao_mix XOR hash(proposer's reveal)
Over an epoch, 32 different proposers each stir the pot once. The final mix seeds the shuffling that assigns duties a couple of epochs LATER.Two properties make this hard to abuse:
- Unpredictable in advance. A proposer’s reveal is a signature it cannot compute until the moment arrives (it’s a signature over the epoch number with its secret key), so no one can know the future seed ahead of time. And because the seed used for a given epoch’s assignments is only finalized shortly before that epoch — with a deliberate delay so proposers can’t see the assignments they’re influencing — you cannot plan an attack far in the future against a specific validator’s duty.
- Hard to bias. Because the mix XORs together contributions from many different proposers across the epoch, no single proposer controls the output. To meaningfully steer the seed, you’d need to control a large fraction of an epoch’s proposers and be willing to pay for it.
RANDAO is not perfect randomness, and an honest book must say so. The one real lever an attacker has is last-revealer bias: the final proposer of the epoch, having seen everyone else’s contribution, can compute what the seed will be if it reveals versus what it will be if it skips its slot (forgoing its block reward). By choosing to propose-or-skip, it effectively gets to pick between two possible seeds. With several consecutive end-of-epoch slots under its control, an attacker gets 2, 4, 8… choices — a grinding attack whose power grows with how many tail slots it controls. This is a known, bounded weakness: skipping costs real rewards, the influence is small for a minority staker, and it is the reason research on stronger unbiasable randomness (VDFs — verifiable delay functions) has long been on Ethereum’s roadmap. The takeaway for this page: assignment is unpredictable and expensive-to-bias enough to stop targeting and stacking, without claiming to be a perfect coin flip.
Empty slots: a missed proposal doesn’t stall the clock
Section titled “Empty slots: a missed proposal doesn’t stall the clock”A crucial and easy-to-miss property: not every slot has to produce a block. The proposer for a slot might be offline, slow, censored off the network, or simply choosing not to propose. When that happens, the slot is empty — no block for slot N — and the chain simply moves on to slot N+1 with its own, different proposer.
slot: 100 101 102 103 104 105 block: [B100] ( — ) [B102] [B103] ( — ) [B105] ▲ ▲ proposer 101 proposer 104 was offline missed its slot → EMPTY slot, chain continues to slot 102This is the difference between a wall clock and a turn-based game. The slot clock is a wall clock: it advances every 12 seconds no matter what, because it’s computed from genesis time, not from block production. A missed proposal is a missed opportunity, not a stuck chain. Contrast this with a naive “pass the baton” scheme where each node must wait for the previous one to finish — there, one offline node would freeze everyone behind it. Ethereum’s clock refuses to wait on anyone.
Why this matters for liveness and for security:
- Liveness. With hundreds of thousands of validators, some are always offline. If every empty slot stalled the chain, a chain this size could never make progress. Instead, the honest majority’s slots keep producing blocks, and the attesters in the next slot simply build their view on the most recent block they can see. Progress is robust to a scattering of no-shows.
- Security. Because the proposer can’t be predicted or reliably targeted (thanks to RANDAO), an attacker can’t cheaply force a long run of empty slots — they’d have to knock out an unpredictable, rotating set of proposers, most of whom they can’t identify in advance. And a proposer who habitually skips its slots simply forfeits its rewards (and under the inactivity leak, much worse if the whole chain is failing to finalize).
The empty slot is the clock asserting its independence: the heartbeat belongs to the protocol, not to any proposer. Blocks are events that may happen on a tick; the tick happens regardless.
The architect’s lens
Section titled “The architect’s lens”The slot/epoch/committee schedule is a major piece of machinery — the scaffolding every later consensus mechanism stands on — so it earns the lens.
- Why does it exist? To turn an undifferentiated crowd of half a million equal validators into an organized electorate: a shared clock that says when to act, and a fair, unpredictable procedure that says who does what on each tick. Without it there is no way to coordinate hundreds of thousands of strangers into a single sequence of blocks and votes.
- What problem does it solve? Two at once. Coordination — a genesis-anchored 12-second clock every node computes independently, so strangers agree on when without a timekeeper. And scale — committees and BLS aggregation compress tens of thousands of votes per slot into a handful of aggregated attestations a home node can verify.
- What are the trade-offs? The 12-second slot and 6.4-minute epoch are a decentralization dial: fast enough to be usable, slow enough that a home validator anywhere can keep up. Faster would centralize validation toward datacenters; slower would make the chain sluggish. RANDAO likewise trades perfect randomness for a practical, hard-to-bias seed (accepting bounded last-revealer bias) rather than waiting on more complex machinery like VDFs.
- When should I avoid it? As a duty-holder, don’t treat the schedule as a suggestion — assignments are deadlines, and missing your slot (as proposer) or your assigned slot (as attester) costs rewards. As a designer, don’t lean on RANDAO where you need cryptographically strong, unbiasable randomness (e.g. a high-stakes on-chain lottery) — its last-revealer bias, though small, is real and exploitable at the margin.
- What breaks if I remove it? Remove the clock and there’s no agreed when — proposals and votes have no shared timeline to attach to, and the chain can’t order itself. Remove committees/aggregation and each slot drowns in hundreds of thousands of individual signatures no home node could process — decentralization collapses toward datacenter-only verification. Remove RANDAO’s unpredictability and duties become targetable: attackers DDoS the known next proposer and stack committees at will.
Check your understanding
Section titled “Check your understanding”- State the length of a slot and an epoch in seconds, and how many slots make an epoch. What is the one thing that happens at most once per slot, and the one duty every active validator performs exactly once per epoch?
- Every active validator attests once per epoch, yet a single slot never carries the whole electorate’s votes. Explain the mechanism that spreads the vote across the 32 slots, and why that spreading is necessary rather than optional.
- What are committees for? Name the two problems they solve, and explain the role BLS signature aggregation plays in one of them.
- Explain how RANDAO produces a seed that is both unpredictable in advance and hard to bias. Then name the one real weakness the page is honest about, and why it doesn’t let a minority attacker freely choose assignments.
- A slot’s proposer is offline, so no block is produced for that slot. What happens to the chain, and what does this reveal about the relationship between the slot clock and block production? Contrast it with a “pass the baton” scheme.
Show answers
- A slot is 12 seconds; an epoch is 32 slots = 384 seconds ≈ 6.4 minutes. At most once per slot, exactly one pseudo-randomly chosen proposer may add a block (the block opportunity). The duty every active validator performs exactly once per epoch is attesting — casting one signed vote on the head of the chain.
- Each validator is dealt into exactly one slot of the epoch (and one committee within it), so its single per-epoch attestation is assigned to just one of the 32 slots. Each slot therefore carries roughly 1/32 of the electorate. It’s necessary because if the whole active set tried to attest in one slot, that slot would be flooded with hundreds of thousands of signatures — impossible to propagate and verify inside a 12-second window. Spreading smears the load across 6.4 minutes.
- Committees solve (a) aggregation — a committee is the natural group over which many validators sign the same vote, so their BLS signatures aggregate into a single combined signature that proves all of them signed, turning hundreds of signatures into one to verify — and (b) bounded work — a fixed number of small committees keeps total consensus bandwidth/CPU within what a home node can sustain, protecting decentralization.
- Unpredictable: each proposer includes a fresh RANDAO reveal (a BLS signature over the epoch number) that it can’t compute until its slot, and the seed for an epoch’s assignments is finalized only shortly before that epoch — so no one knows future assignments far in advance. Hard to bias: the seed XORs together contributions from many proposers across the epoch, so no single proposer controls it. The honest weakness is last-revealer bias: the final proposer of an epoch can choose to reveal or skip, picking between two possible seeds (more choices with more consecutive tail slots). A minority attacker can’t freely choose assignments because skipping forfeits real rewards and controlling many consecutive end-of-epoch proposer slots is both rare and costly.
- The slot is simply empty — no block for that slot — and the chain advances to the next slot with its own different proposer; attesters build their view on the most recent block they can see. This shows the slot clock is a wall clock computed from genesis time, independent of block production: a missed proposal is a missed opportunity, not a stalled chain. In a “pass the baton” scheme, each node waits for the previous one to finish, so one offline node freezes everyone behind it — Ethereum’s clock refuses to wait on any single proposer.