A Lodestar for Eth2
Why it is needed, how ChainSafe is building it, and the roadmap to 2021
Lodestar is ChainSafe’s Eth2 client being built in TypeScript. Lodestar provides highly accessible tooling libraries that benefit the entire Eth2 ecosystem. Our libraries are written in idiomatic TypeScript, making them accessible to a broad swath of developers. Additionally, Lodestar will feature heavily in the Eth2 ecosystem as light-client deployable. Check out this talk and these slides for a great introduction.
“A star that is used to guide the course of a ship…”
Why Lodestar?
To reintroduce Lodestar for new(er) readers, Lodestar is ChainSafe’s Eth2 client being built in TypeScript. There are many different teams working on implementing Eth2 clients in different languages, including Rust, Java, Go, etc. But why the need for multi-client support?
As leading Ethereum researcher Danny Ryan explains in his blog, client diversity provides many benefits:
- Contributing to the network’s resilience
- Cross pollination of ideas, algorithms, and architectures between different client teams
- Each client will have its own specific strengths or focus
- Serves as gateways to different programming communities
So what is Lodestar’s thing? Our aim is to be the most accessible Eth2 client. Fun fact: TypeScript is the 2nd most popular and 4th most in-demand language according to Stack Overflow! Additionally, we will focus on education and developer tooling. But perhaps the critical feature is that Lodestar will be browser native, so that all written code can run with no or very low modification.
Our two-pronged approach to Lodestar development
Our work can be compartmentalized into two buckets:
- Building an ecosystem of developer tooling and libraries and
- Prioritizing Lodestar as a light client with first class citizen status in the Ethereum ecosphere
Firstly, we are creating an ecosystem of composable developer tooling and libraries. When all of these tools & libraries are composed, you get the Lodestar client. Decomposed, we have over 20 libraries that can be leveraged as you see fit for your use-case. For example, both eth2-launchpad and MyEtherWallet utilizes — to some capacity — our BLS (or Boneh–Lynn–Shacham, a type of elliptical curve digital signature scheme) libraries. As well, friends of ChainSafe and co-contributors to the Lodestar repo, Node Factory, extensively leverages Lodestar libraries for their own development purposes, such as in their desktop Eth2 validator app ChainGuardian.
From a numbers perspective, we have seen almost 7k downloads per week for our libp2p libraries, and 3k downloads per week for our BLS libraries. To see our work, which was primarily built for our client implementation, being utilized by other players in the ecosystem is such a humbling and rewarding byproduct!
The other major focus for Lodestar is light clients. Check out this article from [now ChainSafer!] Thibault Sardan for an explainer on what they are and why they are important. From the onset, our intention for Lodestar was to be browser-native and optimized for resource-constrained environments. To achieve this, we have been laying the groundwork for prototyping light clients, which will allow Lodestar to run in a feather-light fashion from the browser. We have also led several rounds of light client working groups (the “Light Client Task Force”). For most typical Ethereum 1.0 use cases, users are likely interacting with Metamask in their browser, which currently requests data from a node provider. Theoretically, there is nothing stopping this node provider from sending to the user tampered data.
The aim is to allow a browser-ready light client, like Lodestar, to be plugged into Metamask, and make the connection vis-a-vis the server completely verifiable without the need for an intermediary. That is, our light client will have the same security guarantees as a full node, but without the high storage requirements and having to sync the whole chain under the stress of heavy server activity.
So what have we been up to in 2020?
2020 was a busy year for the Ethereum community and for the Lodestar team writ large. I mean, for Pete’s sake, the Beacon Chain was officially launched on December 1st, 2020 — that’s YUGE!
We had high hopes to prototype and perhaps even finish a light client proof-of-concept in 2020, but much of the effort instead revolved around productionizing and stabilizing our full beacon node. This included work to ensure the Lodestar beacon node reliably interoperates with other clients, having our validators reliably propose blocks, and running without abusing the computer’s CPU and memory.
Why take the time to build a full beacon node when our focus is a light client? We knew we needed a light server to serve our light client. This meant there would be value found from learning to build our own beacon node, which could then inform our light client work. There would also be synergies to capture from using our own beacon node to serve that data as opposed to another implementation, which would have been unoptimized for our specific use-case.
In terms of testnets for 2020, we attempted participation with the Lodestar beacon node in the Altona, Medalla, and Zinken testnets, but we weren’t quite ready when the testnets launched. Fortunately, we received overwhelming support from the dev community during these attempts. We are extremely grateful to the other client teams for their many suggestions that helped us stabilize our build.
Our client was also plagued with out-of-memory (OOM) issues, something we have only recently gotten under control. 🎊
Additionally, we built out a few websites demonstrating our developer tooling for educational purposes, which you can view here. These tools include a BLS Keygen (do NOT use this for your validator keys), Simple Serialize for serializing and deserializing data, and an Ethereum Name Record (ENR) tool used to share and decode node information in human-readable formats. To the wider blockchain community: please try out these libraries and see if it fits your use-case!
The completion of these sidequests represent important stepping stones in building up the experience to level up our team to tackle Lodestar 2021.
2021: Hard Fork 1, aka Altair
One of the key developments in the Ethereum 2.0 ecosystem is the upcoming hardfork/major upgrade to the network, HF1 aka “Altair”. Outside of lots of, er… rather insignificant details to this hardfork, the most interesting tidbit to this update is that it actually adds machinery to the blockchain to allow for light clients to exist.
In its current state, light clients do not function well on Eth2 because there isn’t an effective way for them to stay synced to the network. Syncing requires downloading and verifying every block sequentially which requires an exorbitant amount of data and time. This automatically eliminates browsers or mobile devices from functioning as light clients. Altair, on the other hand, adds purpose-specific mechanisms — sync committees and a light client sync protocol — to make it super lightweight to stay synced to the chain. This puts Lodestar in a unique position to be more immediately useful for most typical users.
Of course, a lot of work will need to be done to ensure our full node will be ready for the upgrade. Data structures are often very different on the other side of a hardfork. This means refactoring some — if not all — of the codebase to support handling these different versions of data appropriately, without introducing spaghetti code.
However, with Altair enabling compatibility for Eth2 light clients, we can plow forward with prototyping a full Lodestar light client (see the next section for a deeper discussion). Similar to how we built websites to demo a few of our libraries (the BLS keygen, Simple Serialize, and ENR websites), we will do the same for our light client once it’s stable and syncing. The plan is to spin up a basic Eth2 block explorer to demo our tooling… except the data being requested and served will all be validated by our light client! 🤯
Ethereum light client dev force: Go!
Now, our light client work with Lodestar can be currently broken up into two major development focuses: syncing and proof request/response.
First, we want everything in place to keep our light client synced. On the server side, we must have a stable beacon full node to serve our light clients with validated data. This is the work we’ve been working towards in 2020: everything comes full circle! We need our beacon node to be Altair-capable, and to expose the syncing machinery through an API. On the client side, we need the client to properly consume sync updates from our beacon node and …. stay synced. A light client synchronized with the full Beacon node and thus the network, is a light client ready to request and serve the underlying chain data.
But light client users don’t really care about a synchronizing light client. In fact, obviously they expect it to be sync’d under the hood. What they are concerned about is retrieving blockchain data in a lightweight, efficient, and secure way.
The key feature of a light client, and the other big focus of our development work, is the proof request/response machinery. When we have a synchronized light client, we can begin asking full nodes for pieces of data from the blockchain, such as data from dApp A or B, or a specific account balance. The data is returned in the form of a proof, which can be verified by the light client. For Lodestar, this proof will take the form of a merkle multi-proof, which is essentially a way of batching multiple merkle proofs into one, more-efficient proof. When you imagine the Beacon Chain, we have a massive object containing validator balances, recent blocks, recent states, etc. Multi-proofs make querying this data significantly more efficient. On the client side, these proofs are simply a means to an end, and are generally abstracted away from end users. We want our light client to provide a convenient interface that only provides relevant validated data (e.g. validator balances).
At the “library level”, Lodestar’s merkle multi-proof is ready to be used as one piece of infrastructure in any development team’s arsenal. However, the multi-proof has yet to be rolled up to the full-node level. We do however have Eth2 types available here. Once we are satisfied with our sync and multi-proof work, we will be a stone’s throw away from a stable prototype of a Lodestar light client.
So what’s next?
Here is Lodestar’s 2021 Roadmap:
Acknowledgements
Thank you to Cayman Nava, Colin Schwarz, Cindy Chau, Amer Ameen, and Stu Peters for their contributions. Your feedback was invaluable to the making of this article!
Get involved!
Want to work with ChainSafe? COME JOIN US!!! We have many open positions, so take a look and get in touch with us at careers@chainsafe.io if you are interested!
We invite the community to get involved by exploring our developer tooling and leveraging our Eth2 libraries to aid in your project’s development!
If you are interested in getting involved and contributing to the project, check out our Github. If you would like to get in contact with one of the Lodestar team members, feel free to drop by on Chainsafe’s Discord on the #lodestar channel, or email info@chainsafe.io. We would love to know more about you, your team and your project!
For more details on Lodestar, please head to our documentation site.
Learn more about ChainSafe by visiting our website, through our Medium, via Twitter, or by visiting the ChainSafe GitHub.
