---
# System prepended metadata

title: Dev Update Week 2 (robzajac)

---

# Dev Update Week 2 (robzajac)

## *Research*

This week my focus was on reading further into the light client protocol as defined in [`consensus-specs`](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair/light-client) and implemented in  [`beacon-api`](https://github.com/ethereum/beacon-APIs/tree/master/apis/beacon/light_client). Some observations:
- The light client protocol is made possible by the addition of the sync committee in Altair, which gives a way for light clients to verify the validity of the block header they receive from full nodes without having to reconstruct the chain themselves. Specifically, each block header is signed by the sync committee, a randomly elected set of 512 validators that rotate every 8192 slots (approximately [27 hours](https://eth2book.info/bellatrix/part2/building_blocks/committees#committee-assignments)). A constant & relatively small set of validators is chosen to meet minimal hardware requirements for light clients.
- Light clients initialize from a trusted checkpoint root, which is the root hash of a block known to be part of the canoncial chain. From a full node the light client requests the block header of the trusted checkpoint, as well as the current sync committee (public keys of 512 validators) and a Merkle proof of the committee.
- The sync committee at any given time defines a sync period, and the light client protocol provides a means to:
    - Traverse from the sync period of the provided checkpoint root to the current sync period
    - Track the latest header in the current sync period and request a header update when the sync committee changes

The effect of this protocol is that clients with minimal computation & storage can trustlessly verify the latest block header.

## *Implementation*
This week I also continued investigating the current state of light client development in the consensus layer and contacted the corresponding teams. Some results:
- Lodestar is the consensus client with the most commonly used "light server" implementation. Note that the light client data (specified above) is served from full nodes who implement the client protocol, i.e. light servers, which participate in the [LES network](https://github.com/ethereum/devp2p/blob/master/caps/les.md).
    - [Demo](https://light-client-demo.lodestar.casa/ ) 
- There is an open question around incentivizing full nodes to serve light client data. Light clients retrieve data from full nodes without giving any computation in return, which can lead to full nodes being swarmed by light clients. Whether this is an effect observed in practice by the Lodestar team is a question I will continue to investigate.
- Other consensus clients, namely `teku` and `prsym`, are interested in developing light client APIs. These implementations are in very early stages and there is room for contribution.
    - `teku` tracking: [1](https://github.com/ConsenSys/teku/issues/4230) [2](https://github.com/ConsenSys/teku/issues/6287)
    - `prysm` tracking: [1](https://github.com/prysmaticlabs/prysm/issues/11571)
- Outside of the client-server model, there also teams developing for the [Portal Network](https://github.com/ethereum/portal-network-specs) such as [`ultralight`](https://github.com/ethereumjs/ultralight). Portal Network aims to be a p2p alternative to LES for lightweight access to the Ethereum protocol which helps alleviate the incentive concerns with LES.

## *Planning*
I will most likely focus on helping build the light client APIs in `teku` or `prsym`, as well as consolidating the current research on incentivizing full nodes to serve light client data. Some next steps:
- Clone CL clients and meet with the teams to understand the codebase
- Follow up with Lodestar about operational experience of running light client APIs
- Communicate with previous contributors to incentives research, aggregate in a doc

For next week I would like to have a client forked ready for implementation of the light client APIs, and a doc in progress on current research in this part of the protocol.

## *Readings*
- https://mycelium.xyz/research/world-of-light-clients-ethereum
- https://www.parity.io/blog/what-is-a-light-client/
- [Light client specs](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair/light-client) and [API](https://github.com/ethereum/beacon-APIs/tree/master/apis/beacon/light_client)