Altair: sync committees, or how a phone verifies Ethereum
Proof-of-stake is secured by hundreds of thousands of validators — wonderful for security, hopeless for a light client that can't track them all. Altair adds a sync committee: a small, rotating group of 512 validators that signs each block, so a resource-limited client verifies one aggregate signature instead of a million attestations. It's what makes trustless light clients — and the bridges built on them — possible.
- proof of stake & the beacon chain
- Merkle proofs
Altair, October 2021 — the beacon chain’s first upgrade, and the book’s first purely consensus-layer chapter. Everything so far has verified Ethereum the heavyweight way: run a full node, track all the state, check everything. But most devices can’t do that. A phone wallet, an in-browser client, or another blockchain wanting to read Ethereum’s state needs to be convinced of the chain’s head without downloading the world or following a million validators. Before Altair, they couldn’t — so they trusted an RPC provider, quietly reintroducing the middleman a blockchain exists to remove. Altair’s fix is the sync committee. Let’s derive it.
The problem: a light client can’t check a million validators
Under proof of stake, a block is made canonical by attestations Signed votes from validators on the head of the chain and the justified/finalized checkpoints. Every active validator attests each epoch, so verifying the chain the full way means processing votes from the entire validator set. from the validator set — and that set is enormous (hundreds of thousands, heading past a million) and changes constantly. To verify the head the full way, you’d have to know every validator’s key and process a mountain of aggregated votes each epoch. A light client A client that follows and verifies the chain with minimal resources — a phone, a browser tab, or a smart contract on another chain — without storing all state or running full consensus. — a phone, a browser, a contract on another chain — simply can’t. So it falls back on trusting an RPC provider to tell it the truth.
→ Step 2: sample a committee small enough to check.
Sync committees: 512 signers, one signature to check
Altair adds a sync committee A randomly-sampled subset of 512 validators, selected for a ~27-hour period. During that period the committee members sign each block header; a light client verifies their aggregate signature to be convinced of the head. : a randomly-sampled group of 512 validators, fixed for a period of about 27 hours. During that period, the committee members sign each block’s header. Because Ethereum uses BLS signatures A signature scheme whose signatures can be aggregated: many validators' signatures over the same message combine into one, verifiable against the aggregate of their public keys in a single check. , all their signatures over a block combine into one aggregate signature. So a light client’s job collapses to: hold the 512 committee public keys, and verify that a supermajority of them signed the head — a single signature check against 512 known keys. That’s light enough for a phone.
→ Step 3: let each committee vouch for the next.
The payoff: follow the head from a single checkpoint
The elegant part: the next period’s sync committee is committed in the current beacon state. So a light client that trusts the current committee can obtain the next committee’s keys along with a Merkle proof A short proof that a value (here, the next sync committee) is part of the beacon state, checkable against the state root the current committee already signed. It lets the client accept the next committee without a new trust assumption. that they’re genuinely in the state the current committee signed — and thereby hop from period N to period N+1 with no new trust. Chain those hops and a client that starts from a single trusted weak subjectivity checkpoint A recent, trusted starting point (a finalized block root) a light client is given once, out of band. From there it can verify everything forward on its own. can follow Ethereum’s head trustlessly, forever. This is what makes real light clients (like Helios) and, crucially, trust-minimized bridges — where one chain runs an Ethereum light client to verify Ethereum’s state — possible.