In the previous week, seven out of the eight Eth2 clients currently under active development achieved a significant milestone by transitioning from single-client to multi-client testnets during the “Interop Lock-in”. With this thrilling advancement in Eth2 development, we aimed to reflect on how this was accomplished and its implications for the Ethereum network and ecosystem.
Anyone who has been tracking Ethereum over the last few years has likely become accustomed to phrases like “Ethereum 2.0”, “Eth2”, or “Serenity”. Each of these terms refers to considerable enhancements planned for the Ethereum protocol that have been contemplated in some form since before the network was launched in 2015.
During the early years of Ethereum, pioneering research was carried out alongside the original chain (Eth1) launching, while the massive expansion of the Ethereum community that ensued facilitated the initial adoption of decentralized applications. Nevertheless, the journey from these initial breakthroughs to a highly decentralized yet scalable proof-of-stake blockchain has been protracted. However, over the past 18 months, research finally consolidated into a cohesive and comprehensive vision for the impending major upgrades known as Eth2.
As research progressed into specifications toward the close of 2018, numerous teams (client teams) from throughout the community stepped forward to develop core implementations of the protocol (clients). Since that time, there has been a dynamic interplay between specification and implementation. Bi-weekly meetings and a common specification repository facilitated communication and the exchange of ideas, but client teams primarily operated in relative seclusion, constructing and evaluating their implementations of the protocol.
While the specification was constantly evolving, clients could only delve so far into interoperability and optimizations; however, once the Phase 0 specification of Eth2 was considered “frozen” on July 1, 2019, clients made remarkable progress and began taking concrete steps toward production.
Interop
Joseph Delong from Pegasys conceived the bold idea of assembling members from each of the client engineering teams in a remote location for a week dedicated to interoperability efforts. This event was known as the “Interop Lock-in” or more commonly referred to as “Interop”. With the spec freeze approaching and Devcon on the horizon, Interop in September presented a chance for all stakeholders to collaboratively address initial interoperability challenges face-to-face.
The main objective of the event was to enable each participating client to achieve pairwise interoperability with every other client within small testing networks — Lighthouse Artemis, Lodestar Lighthouse, Lodestar Artemis, etc.
Participating client teams consisted of:
Additional objectives included testing (1) larger networks in both node count and (2) validator count, (3) networks featuring 3+ clients, (4) improving tools for monitoring and debugging Eth2 networks, and (5) other enjoyable endeavors such as setting up raspberry pis and creating fork visualizers.
In the lead-up to the event, some objectives seemed ambitious, yet teams persisted diligently until the deadline and achieved remarkable advancements. By the week’s conclusion, client teams greatly surpassed the initial expectations of establishing a few pairwise networks, successfully completing the entire pairwise tests, creating a small network of all seven participating clients, and beyond.
The following offers a glimpse into the highlights of client accomplishments, though it is certainly not exhaustive:
Multi-client testnets
- All seven participating clients attained pairwise interoperability, and even though an eighth, Shasper, could not be present, they have initiated efforts to work through this milestone as well.
- Numerous larger testnets were established comprising 3+ clients, 3+ nodes, and surpassing the minimal validator counts.
- All seven clients present were successfully operated on a single network.
- All participating languages’ libp2p implementations are now interoperable after resolving some minor issues.
Network debugging and tools
- Certain consensus discrepancies among clients were identified, analyzed, and logged as parts of the state transition that necessitate increased testing coverage.
- Command-line tools were developed to enhance the debugging of ssz objects and state transitions (zcli, pycli, and similar tools incorporated within clients).
- Advancements were made on metrics dashboards, a fork visualizer, and other tools to improve understanding of clients and networks
- Clients were packaged into containers to facilitate large-scale network testing within the Whiteblock genesis platform.
And then some
- Client teams functioned as each other’s initial alpha users, resulting in comprehensive build/run scripts and associated documentation.
- Isolated load assessments with Nimbus and Lighthouse managed over 2000 validators on a singular machine connected with similarly full nodes via LAN.
- Several clients were developed and evaluated on a compact raspberry pi network.
And beyond
Interop represented a significant turning point for Eth2. There remains a substantial amount of tasks to complete prior to launch, but engineering initiatives will progressively be focused on testnets, enhancements, and usability — efforts that start to transition this software into the hands of users.
So what are the upcoming plans for client teams and eth2 development?
- Benchmarks and enhancements
- Test synchronization, stress test networks, etc
- Public and incentivized testnets
- Third-party evaluations
- Refining the validator user experience
Lastly, we extend our gratitude to the ConsenSys team for assisting in organizing, hosting, and providing resources that made Interop feasible.