Try   HackMD

Dev Update Week 2 (robzajac)

Research

This week my focus was on reading further into the light client protocol as defined in consensus-specs and implemented in beacon-api. 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). 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.
  • 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 2
    • prysm tracking: 1
  • Outside of the client-server model, there also teams developing for the Portal Network such as 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

Last changed by 
 
robzajac
0
1
158

Read more

Final dev update (robzajac)

This is the final dev update for robzajac in EPF cohort three. Project summary The light client protocol is a way for nodes in low-computation environments to sync to the latest block header without needing to trust a third party. It is built on the introduction of the sync committee in Altair, a randomly selected set of 512 validators (rotating every 256 epochs) which signs the headers of newly attested blocks. The goal of this project was to implement support for the light client APIs in the consensus client teku. These APIs are the method by which light clients poll the data required to participate in their sync protocol. A secondary goal was to make progress in the research area of node RPC incentivization or otherwise design a way to incentivize the serving of light client data. More information on light clients can be found in the original project proposal. Status report

Feb 23, 2023
Light client consensus layer development

This is a project proposal for EPF Cohort Three by robzajac. The goal of this project is to enable greater decentralization and trustless access to the Ethereum consensus layer by implementing the light client protocol in teku. This will increase the availability of light client data in the CL and make it easier for light clients to sync to the latest block header without needing to trust a third party. Motivation The light client protocol is a way for clients in minimal computational environments to sync to the latest block header without needing to trust the data provider (e.g. a node hosted on Infura). For more on the protocol and its motivation, see background reading. This protocol describes both the light client itself, and a "light client server" which provides the data needed for the light client to execute its sync protocol. While there have been several light client projects in development (e.g. recently announced RPC-proxy light clients Kevlar and Helios), there are not as many implementations of the light client server. Currently, the majority providers for light client data in beacon nodes are the consensus clients Nimbus and Lodestar. Serving this data is done altruistically, as light clients do not contribute any computation to the network. In order to contribute to greater availability of this data, as well as expand client diversity, more consensus clients should implement the light client protocol.

Feb 23, 2023
teku light client table

As described in the latest dev update, persisting light-client data on disk and serving requests with a table lookup will be the best way to provide light client support in teku. It has the advantages of: Providing the best light client update per is_better_update, given that light client updates can be compared and saved per sync-committee period Providing the highest rate of data availability, as all nodes that see a block will be able to serve light client data corresponding to the block (previously an archive node would be required for historic states) Code maintainability, as the logic of updating when we sync and serving from the table is much simpler than computing the slot required for light client updates and retrieving the relevant beacon states on-the-fly This doc will briefly describe the interface and details of this table in teku. Light client data schemas Add two columns with type:

Feb 17, 2023
Dev Update Week 15

This week I focused mainly on two things: Worked on getting my mainnet besu + teku pair up and running on a node provided by Mario. Initially had some issues with the configurations for the clients, but now the EL & CL syncs are both complete with teku up-to-date in archive mode.Archive mode in teku is necessary for accessing historic states, which are required to derive light client data. We can test the light client API already implemented (light client bootstrap) on this mainnet client pair. Worked on the light client updates by range API and the light client data availability problem. Light client data, at least for LightClientUpdate, is derived from beacon state. The light client API specifies that servers should provide light client data for a historic period of ~5 months. Most nodes, at least in teku, run in prune mode, meaning that they do not store any state beyond the latest finalized. Archive nodes have a significant storage requirement that most nodes will not provide (especially archive nodes running with >= 5 months of historic data, not just e.g. from the latest checkpoint).

Feb 12, 2023
Read more from robzajac
Published on HackMD