Last week, seven of the eight Eth2 clients in active development successfully marked the major milestone in moving from single-client to multi-client test networks during the Interop Lock-in. With this exciting success in the development of Eth2, we wanted to reflect on how this point was reached and what it means for the Ethereum network and ecosystem.
Anyone who has followed Ethereum over the past couple of years has likely become familiar with terms like “Ethereum 2.0,” “Eth2,” or “Serenity.” Each of these refers to substantial upgrades planned for the Ethereum protocol that were considered in one form or another before the network went live in 2015.
During Ethereum’s early years, groundbreaking research was carried out alongside the launch of the original chain (Eth1), while the massive growth of the Ethereum community that followed contributed to the initial adoption of decentralized applications. Yet the journey from these early advances to a highly decentralized, yet scalable, proof-of-stake blockchain has been a long one. However, over the past 18 months, research has finally stabilized into a cohesive and comprehensive view of the next major upgrades known as Eth2.
As research moved into specifications towards the end of 2018, many teams (client teams) from across the community came together to develop key implementations of the protocol (clients). Since then, there has been a dynamic interplay between specification and implementation. Bi-weekly calls and a common specifications repository organize communication and idea sharing, but client teams primarily worked in relative isolation, building and testing their implementations of the protocol.
Even though the specification was a moving target, customers could only dig deeper into interoperability and optimizations, but once Eth2’s Phase 0 specification was deemed “frozen” On July 1, 2019, customers made huge progress and started taking concrete steps toward production.
Interoperability
Joseph Delong Pegasys had the crazy idea of bringing together members of each of the client’s engineering teams in a remote location for a week of interoperability work. The event was considered the “Interop Lock-in” or, as it was generally called, “Interop”. With the spec freeze in sight andvOn the horizon, Interop in September was an opportunity for all of these stakeholders to work on initial interoperability issues in person.
THE main objective The goal of the event was to have each participating customer achieve pairwise interoperability with every other customer in small test networks — Lighthouse <-> Artemis, Lodestar <-> Lighthouse, Lodestar <-> Artemisetc.
Participating customer teams included:
Additional goals involved testing (1) larger networks in terms of number of nodes and (2) number of validators, (3) networks with more than 3 clients, (4) improving monitoring tools and debugging Eth2 networks, and (5) other fun things like getting Raspberry Pis running and building fork visualizers.
Before the event, some goals seemed far-fetched, but the teams worked diligently until the deadline and made incredible progress. By the end of the week, the client teams far exceeded the initial expectations of having a few pairwise networks, instead completing the entire pairwise testing, creating a small network of all 7 participating customers and more.
The following represents a snapshot of customer success highlights, but is certainly not exhaustive:
Multi-client test networks
- The 7 participating customers reached pairwise interoperabilityand although an 8th, Shapercould not be present, they begin to also take this step.
- Many larger testnets have been formed between more than 3 clients, more than 3 nodes, and more than the minimum number of validators.
- The 7 customers present were successfully executed on a single network.
- The libp2p implementations of all participating languages are now interoperable after debugging a few minor issues.
Network Debugging and Tools
- A few consensus errors between clients were identified, debugged, and recorded as parts of the state transition requiring increased test coverage.
- Command line tools were designed to better debug ssz objects and state transitions (zcli, pycliand similar tools integrated into clients).
- Progress on metrics dashboards, a fork viewer, and other tools to better understand clients and networks
- Customers were grouped into containers to perform large-scale network testing within the White block genesis platform.
And then some
- Customer teams were early alpha adopters of each other, resulting in extensive create/run scripts and associated documentation.
- Isolated load testing with Nimbus and Lighthouse processed over 2,000 validators on a single machine paired with equally comprehensive nodes on LAN.
- Several clients have been built and tested on a small Raspberry Pi network.
And beyond
Interop marked a major inflection point for Eth2. There’s still a lot of work to be done before launch, but engineering efforts will increasingly focus on testnets, optimizations, and usability – work that begins to get this software into the hands of users .
So, what’s next for client teams and eth2 development?
- Benchmarks and optimizations
- Test synchronization, stress test networks, etc.
- Public and incentivized test networks
- Third-party audits
- Improve the validator user experience
Finally, we owe a special thank you to ConsenSys for helping to organize, host and provide the resources that made Interop possible.
