Lodestar Light Client

We build a prototype of an Eth2.0 lightclient to sync to the Lodestar beacon chain and consume proofs


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%.

Lodestar Light Client showcase

How it's made

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.

Technologies used