What is sync committee?

A group of 512 validators, chosen at random for 256 epochs at a time, that signs recent block headers so light clients can follow the chain cheaply.

Without it a light client would have to track the entire validator set to verify anything; with it, checking a handful of committee signatures is enough (source: the Ethereum consensus specifications). Committee duty carries its own rewards and penalties separate from ordinary attestation duty. It is infrastructure most users never see, and it is what makes trust-minimized wallets and cross-chain light-client bridges possible. Membership is known in advance so clients can prepare, and the rotation is short enough that a committee which went bad could not mislead clients for long. See light client and validator.

The practical payoff is that a wallet on a phone can check the chain for itself rather than trusting whatever server it happens to be pointed at.

How it works

Verifying Ethereum properly means tracking hundreds of thousands of validators and their attestations, which is far beyond a phone or a smart contract on another chain. The sync committee is the shortcut.

The protocol selects 512 validators pseudorandomly to serve for 256 epochs. During that period they sign the most recent block header each slot, and the signatures are aggregated into a single compact object. A client that knows the committee's public keys can verify the aggregate against a header without knowing anything about the rest of the validator set (source: the Ethereum consensus specifications).

Handover is what makes the scheme work over time. The header a committee signs commits to the next committee, so a client that has verified one period can bootstrap itself into the next without external help, and can walk forward indefinitely from a single trusted starting point.

The security model is weaker than full consensus and honest about it. A sync committee signature is evidence that a supermajority of a randomly chosen 512 validators attested to a header. It is not finality, and a client that needs finality checks the finalized checkpoint rather than the committee signature. See finality.

Example

Illustrative arithmetic from the constants. A period of 256 epochs, at 32 slots per epoch and 12 seconds per slot, is 256 × 32 × 12 = 98,304 seconds, or about 27.3 hours. So the committee rotates roughly daily, and a light client that goes offline for a week needs to walk forward through about six handovers to catch up, each verified against the previous one. That is a handful of signature checks rather than a week of full validation, which is the entire point.

Why it matters when you buy

This is what lets a cross-chain bridge verify Ethereum without trusting an operator, and what lets a mobile wallet check balances without trusting a server. Both matter after coins leave an exchange. The chain pages cover how each network settles, and the guide on sending crypto across chains covers what a bridge is actually verifying.

Related terms

• light client — what the committee exists to serve
• validator — who serves on it
• beacon chain — the layer that selects it
• epoch — the unit its term is measured in
• attestation — the ordinary duty this sits beside
• bridge — the application that depends on it most

Questions

Can a sync committee lie about the chain?

A colluding supermajority of the 512 could sign a header that did not belong to the canonical chain, which is why the design is a convenience for following the head rather than a replacement for finality checks.

How is the committee chosen?

Pseudorandomly from the active validator set, with the selection derived from the beacon chain's randomness. Membership is known an entire period in advance so clients and validators can prepare.

Does this affect my transactions?

Not directly. It affects how cheaply software can verify the chain, which shows up as wallets and bridges that trust fewer intermediaries. See node.