Lodestar Light Client

Why does eth2 need light clients? Downloading the whole chain is prohibitive for many environments (eg: websites, phones, etc). For such use cases that simply want to read some small piece of the chain (eg: fetch a recent validator balance), a light client is sufficient and preferable.

In order to retrieve the latest state, Ethereum full nodes must download the genesis (or other) beacon state, and download and sequentially process every canonical block from start to finish.

Using light clients, this bandwidth & processing load can be reduced by ~99%.

How does eth2 protocol allow light clients to exist / support light clients?

Broadly speaking, a light client has two main components. First, the light client must stay synced to the chain. It does this without downloading all of the data, eg: just downloading a recent block header. Second, once synced, the light client must be able to retrieve recent data from the chain.

The altair upgrade includes the key feature specifically designed to support light client syncing -- the sync committee! The sync committee and its associated infrastructure lets a light client stay updated to the head of the chain very cheaply.

The chain data retrieval is provided by extensive use of merkle proofs. Once the recent block header is verified and trusted, a light client server can provide chain data in the form of merkle proofs to a light client. These proofs can be trustlessly verified against the recent block header.

Because the sync protocol plays such a central role for light clients, it is worth going into more detail on how it funcitons:

Altair creates the sync committee, a special long-lived committee that rotates approximately every 27hrs

The sync committee allows light clients to more easily sync and stay synced to the beacon chain!

The beacon state tracks the current AND next sync committee participants. We will see why this will be important below.

Sync committee participants attest to the current state of the chain, specifically the previous block, and these attestations are aggregated into a single signature which is included in every new block

So now every block contains an signature verifying its predecessor

This special sync committee attestation is named “SyncAggregate” (to differentiate it from “Attestations” put on chain via beacon committees)

Recap:

(Relatively) small subset of validators attest to block N-1 in every block N

(Relatively) small subset of validators only rotates every ~27 hrs

(Relatively) small subset of validators (current and next) is included on chain

The light client sync protocol can now be crafted. It relies on the sync committee’s agreement on the view of the chain

Instead of initializing the node with the entire beacon state (eg: the genesis state), the light client downloads a historical block header and the current and next sync committee at that block.

Instead of downloading and tracking the entire validator set (120k validators and counting!!), a light client can just download and track the current and next sync committee.

Instead of progressing the chain by downloading and processing every historical block sequentially, a light client can just download the last SyncAggregate from a sync committee (ensuring that ⅔ of the committee signed) and a merkle proof to the next sync committee

In essence, the light client syncs by tracking each sync committee across time, syncing forward committee by committee, ensuring that each committee handoff has a ⅔ vote that verifies the next.