Sync Committee Protocol

The Basics of Ethereum's Light Client Protocol

The basic procedure by which a Light Client learns about more recent blocks. Taken from the official annotated spec for Ethereum.

Ethereum's Light Client Protocol

In the past sections, we have made a few references to how we borrow security from Ethereum's validator set and how we generate these "proofs of consensus" that can succinctly verify Ethereum consensus on-chain. While we originally glossed over this detail for the sake of simplicity, it is important to note that our protocol is specifically secured by Ethereum's Light Client protocol, which was introduced in the Altair hard fork. Ethereum's Light Client protocol is secured by a group of rotating validators known as the sync committee. The official annotated spec for Ethereum provides a good introductory description of its details:

The sync committee is the "flagship feature" of the Altair hard fork. This is a committee of 512 validators that is randomly selected every sync committee period (~1 day), and while a validator is part of the currently active sync committee they are expected to continually sign the block header that is the new head of the chain at each slot.

The purpose of the sync committee is to allow Light Clients to keep track of the chain of beacon block headers. The other two duties that involve signing block headers, block proposal and block attestation, do not work for this function because computing the proposer or attesters at a given slot requires a calculation on the entire active validator set, which Light Clients do not have access to (if they did, they would not be light!). Sync committees, on the other hand, are (i) updated infrequently, and (ii) saved directly in the beacon state, allowing Light Clients to verify the sync committee with a Merkle branch from a block header that they already know about, and use the public keys in the sync committee to directly authenticate signatures of more recent blocks.

The Light Client protocol uses the sync committee to reduce the computational cost of verifying the validity of Ethereum block headers. Verifying over 400k+ signatures per block can be quite expensive, even in settings outside of blockchain. It is important to note that the sync committee does not have the same security as the entire Ethereum validator set. In particular, there is no slashing for the sync committee, so the security of the sync committee relies on an honesty assumption of the sync committee validators. However, as long as a significant portion of the entire Ethereum validator set is honest, it is statistically unlikely with high probability that the sync committee will ever sign off on an invalid block header, as its honesty proportion will reflect the honesty of the entire Ethereum validator set.