Lodestar Post Devcon Update
Written by Colin Schwarz and Cayman Nava
Introduction
Devcon is always an exciting time for the Ethereum community, and Devcon 5 was no exception. This year’s conference was especially busy and productive for the Lodestar team. Four out of five of our full-time team members were able to attend the conference in Osaka. During our time in Japan, Lodestar team members gave several talks, sat on an eth2 panel and had a lot of productive conversations and brainstorming sessions with other eth2 teams and implementers. Talks and experiences at Devcon also helped us to focus our research and development efforts moving forward for our work on productionizing the Lodestar beacon chain and on building out a light client. This article will discuss some important conversations that we had with other implementation and research teams. It will also touch on some of the ideas that came out of Devcon for how to advance Lodestar past some of the major challenges which we have been facing and will conclude with some thoughts on progressing light client research and development.
Conversations at Devcon
During Devcon, our team had many conversations with other researchers and developers about light clients in general and phase 2 light clients in particular. We talked about how there are two different layers of light client, one at the beacon/shard level, and one at the Execution Environment (EE) level. These layers differ in terms of the participants in the system who hold the data, the formats of proofs requested, and the ways of verifying these proofs.
Data requests on the beacon/shard chain level have different requirements than EE requests. Beacon/shard chain proofs are more straightforward and requests are usually made to a known part of the merkle tree. EE level proofs are a little trickier. Since every EE may have different proof logic, it may be useful to modularize EEs to include proof verification as separable functionality. This way, light clients at the EE level can rely on a built-in proof verification function and not need to potentially write custom verification code for each EE. We look forward to continuing these talks both on and off-line, as we continue to delve deeper into this space.
Addressing Outstanding Issues
In a call shortly after Devcon, the Lodestar team identified major outstanding issues that would require further discussion to work out the best solutions. Currently, our big blockers are how to best optimize our state transition and how to best implement syncing blocks by range. Optimizing our state transition is a high priority and a very non-trivial undertaking. For now, we have a PR open to take state transitions out into their own package and see where this leads us. In the near future, we will need to decide how to best organize caches and indexes of various beacon state computations. Regarding the implementation of syncing blocks, we have a PR open to sync blocks from peers in a round-robin fashion, and plan on adjusting our strategy further as needed.
Light Client Research and Call
Over the past month, we have made significant progress on light client research and prototyping. Prior to Devcon, we were prototyping merkle multiproof generation+verification in our ssz library in an effort to better understand this important aspect of eth2 light clients. We currently have a draft PR showing this work.
One takeaway from Devcon is that light client technology is going to be important for the future of Ethereum. In that vein, we’ve decided to host a monthly community call to discuss light client research and logistics to bring research to production. We call it the Light Client Task Force! The first call will be next week, Nov 6, 14:00 UTC. See this post for the full announcement!
