Prysm: Light Client Support

**ToC:**[toc] ## How to enable light client support in Prysm You can enable the processing and serving of light client updates in Prysm by passing the `--enable-light-client` flag to your beacon node. ## Why it matters Don't trust, verify. This has been one of the basic rules of the decentralized movement, yet we blindly trust that the RPC providers are sending the correct information to us. We trust our wallet applications, and our wallets trust RPC providers. This should not be the norm. Light clients were introduced as a defensive tool against such scenarios. They are lightweight clients that follow the chain minimally, allowing us to prove the information RPC providers give out. To enable light clients to work, full nodes must provide a set of small updates, known as light client updates, allowing LCs to follow the chain. Adding LC support in full nodes will make it easier for LCs to access the necessary data. Wallets should then integrate light clients into their applications, to add an extra layer of protection. ## How it works Light clients follow the chain per rules described in [the spec](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/light-client/light-client.md). They start from a trusted block root, and obtain what's called a `LightClient Bootstrap`. That bootstrap object contains the list of public keys for current sync committee members. With this info, they can verify any future message signed by this committee. The light client keep polling the full nodes for regular updates, which contain some info about the chain. This info includes things such as block root, state root, parent root and execution data, for both head and finalized checkpoint. Using the data that the light client keeps, users can verify claims about Ethereum's state. A merkle proof is also needed to be provided alongside the claim. ## Prysm's Implementation Details ##### Core mechanism Prysm keeps a cache containing some light client data per block root. When a new block arrives, it's LC data, comprised of LC Update, LC Finality Update, and LC Optimistic Update are computed. Then this data is compared to the block's parent's data, which is stored in the cache. The comparison is done based on rules defined [here](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/light-client/sync-protocol.md#is_better_update). If the data is better, we keep them as the data for that block, otherwise this block will point to it's parent's data. Upon Finalization, a number of tasks are done: 1. First a Light Client Bootstrap is computed from the new finalized checkpoint and saved to the DB. 2. Second, a migration from the light client cache to the cold DB will take place. We will take the new finalized checkpoint, and traverse back to the previous finalized checkpoint (this is called Tail in the LC cache). We will take the best update available for every sync committee period available in the cache, and save it to the DB. Then the old data will be purged from the cache. ##### How LCs can access data The saved light client data is accessible in three different ways: 1. Beacon API: light clients can call the beacon API endpoints and get the data: I. [/eth/v1/beacon/light_client/bootstrap/{block_root}](https://ethereum.github.io/beacon-APIs/#/Beacon/getLightClientBootstrap) II. [/eth/v1/beacon/light_client/updates](https://ethereum.github.io/beacon-APIs/#/Beacon/getLightClientUpdatesByRange) III. [/eth/v1/beacon/light_client/finality_update](https://ethereum.github.io/beacon-APIs/#/Beacon/getLightClientFinalityUpdate) IV. [/eth/v1/beacon/light_client/optimistic_update](https://ethereum.github.io/beacon-APIs/#/Beacon/getLightClientOptimisticUpdate) 2. GossipSub: There are additional GossipSub topics added that light clients can subscribe to and stay in sync with the network. These updates are sent 4 seconds into a slot with better updates than the previously seen blocks. I. [light_client_finality_update](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/light-client/p2p-interface.md#light_client_finality_update) topic & II. [light_client_optimistic_update]([light_client_finality_update](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/light-client/p2p-interface.md#light_client_optimistic_update)) topic 3. The Req/Resp domain: There are also 4 message types defined in the Req/Resp domain that light clients can use to query the data they need.