# Bootstrapping the beacon chain light client ecosystem The Altair fork of the beacon chain introduces specialized support for efficient light clients. These light clients only follow a subset of the broader consensus and in exchange for a reduced security margin greatly reduce the resource requirements needed to interact with the chain in a trust-minimized way. This document details some thoughts on bootstrapping the light client ecosystem as we approach the mainnet Altair fork. # Requirements Starting from the design implied by the [current light client spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/altair/sync-protocol.md), an ecosystem of beacon chain light clients needs the following: 1. Light client implementation * Software that implements [the spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/altair/sync-protocol.md) * the ability to start from a `LightClientSnapshot` obtained from a trusted source * the ability to consume `LightClientUpdate`s * the logic to process `LightClientUpdate`s to track the latest block header 2. "Light server" implementation * Software that provides an endpoint for a light client implementation to request `LightClientUpdate`s * the actual API endpoint * the logic to track enough of the canonical chain to produce the relevant data * notice this involves listening to the global beacon net gossip topics and running the state transition/fork choice to compute the latest canonical state # What's missing for the high-level components? The light client implementation is fairly small but I do not know of any complete prototypes yet. These should be pretty straightforward to prototype and test against testnets as they start moving to Altair. **A first milestone here is to simply have a light client that tracks the latest state/block root.** The "smallest" diff between what we have now and a working light server would be to extend a beacon node implementation. A beacon node will already track the relevant data and be able to stay in sync w/ the chain in an efficient manner. This beacon node extension would just need the API endpoint and a component to capture a snapshot of its local view of the chain as a `LightClientUpdate` when requested. **A first milestone here is to fork one of the production-grade beacon clients and build out the aforementioned functionality.** # Future extensions As the light client ecosystem grows, there will be reasons to specialize each of the components further. * The current light client spec is only safe up to finality but there are many use cases where low-latency light clients tracking up to the head of the chain would be great for network decentralization (e.g. reduction on Infura reliance). * Extend proof functionality of the light client so that it can verify arbitrary state against the latest block header, i.e. utilizing SSZ multiproofs to prove some state at a given block e.g. some contract balance at slot N was X ETH. * There is a long-standing open question around incentivizing light servers to provide data for light clients. One possible solution is to have light clients pay light servers for their work. An independent light server that stands alone from a beacon node would make sense in the scenario where light servers are part of a dynamic network (e.g. managing many payment channels) with variable load.