The Merge will mark the end of Proof of Work and the full transition to Proof of Stake, fundamentally changing how the Ethereum blockchain reaches consensus. The core benefits of the Merge, outlined in Charting The Path To Proof of Stake Ethereum, are increased energy efficiency, validators, decentralization, and security, as well as the distinctions between execution layer clients (Eth1) and consensus layer clients (Eth2). 

Ethereum core devs and researchers have been working rigorously to ensure a smooth transition for the Merge and recently met in Greece for the Amphora Interop event to consolidate their progress. From October 2nd to 9th, 40 representatives of Eth1 and Eth2 teams, the Ethereum Foundation research team, and Consensys R&D worked together on-site for the first time since the pandemic. The event’s ultimate goal was to create a long-lived, multi-client devnet. And they achieved it!

Breakout sessions

A demo of the Merge local testnet by Consensys Protocol Lead Engineer, Adrian Sutton was posted on the second last day of event. To document completed tasks and for continued collaboration leading up to the Merge, the Amphora Client Milestone Tracker was also created. 


https://www.youtube.com/watch?v=bXTC7sy1UtA

Amphora Client Milestone Tracker

The Amphora Client Milestone Tracker is open for everyone on the project to contribute to. The tracker includes active clients, the milestones that led to the devnet completion, and links to resources. Milestone one consisted of outlining all specs, while milestones two and three focused on pairing and syncing clients with transitions. Milestone four achieved multi-client interoperability, and five tied each one together into a functional devnet. 

The Merge readiness criteria captured in the tracker was a central focus of the Amphora Interop. Teams worked in breakout sessions to discuss testnet automation, API definition, error standardization, fuzzing and continuous integration, and the roadmap from Amphora to mainnet. Tools to run and restart Merge testnets and test tooling like local machine runs were developed. One mergenet was deployed on the final day and shared on Twitter. Once feedback is consolidated, it will inform another iteration of engineering work for early November. Risks and potential pain points were also discussed. 

Breakout sessions throughout the week

The event has been a huge step forward to realize the Merge and rapidly get clients up to speed. We spoke with Mikhail Kalinin, who is a Consensys researcher working on the merge, and Sajida Zouarhi, Senior Product Manager for Hyperledger Besu at Consensys. Both attended the Amphora Interop and we wanted to understand first-hand their experience and the significance of the milestones outlined in the Amphora Client Milestone Tracker. 

Q&A with Consensys Core Devs and Product Managers  

Clarissa Watson: From the perspective of the Eth1 execution client, Hyperledger Besu, was the Merge interoperability workshop successful? 

Sajida Zouarhi: This Merge interop was a successful event on all counts. Hyperledger Besu was able to successfully interop with all clients. Not only did we manage to “merge” the Eth1 chain (execution layer) with the Eth2 Proof of Stake chain (consensus layer) on a multi-client testnet, but we did it in a week. Being able to hack in sync with all core devs with a high-degree of focus was a game changer. Our team saved several months worth of work.

The learnings of this week are going to inform Ethereum’s roadmap; many important topics were discussed, especially regarding security and maximal extractable value (MEV). Our goal is to make Besu a top choice client on the execution layer — not only when paired with Teku — but for all consensus clients. This is absolutely vital for the whole Ethereum ecosystem if we are to achieve client diversity after the Merge.

James Beck: What specs were implemented in milestone one to ensure collaboration between Execution and Consensus layer clients on the devnet?

Mikhail Kalinin: There are three main sources of the Merge spec: the consensus layer (CL), the execution layer (EL), and engine API, which is the protocol used by clients to communicate. 

Clarissa Watson: What did you observe about basic testing between clients during milestone two in order to complete milestone three? 

Mikhail Kalinin: To achieve milestone two, we focused on particular client pairings and their ability to work post-Merge. Milestone three was the same, but added the transition process. 

The transition process is an essential part of the Merge as this is where the system actually turns from Proof of Work to Proof of Stake. The specifications and implementation are the most sophisticated aspects of the Merge and very important for the clients to do smoothly.

Clarissa Watson: What were the key learnings from milestone four, many-to-many (TTD < 50) client testing, that informed milestone 5?

Mikhail Kalinin: Milestone 4 was a big step towards the long lived multi-client testnet. Client teams were checking if their Consensus layer or Execution layer clients worked well together, not only with their counterparty, but also with another implementation of a CL or EL client.

James Beck: Completion of M5 means all clients can use the devnet. How do you envision the devnet supporting clients ahead of the Merge?

Mikhail Kalinin: It doesn’t mean that every client is ready for the Merge as it might seem at the first glance. What we have accomplished means that most of the clients support the Merge and demonstrates their stability in the best case. Clients may join testnet to test particular things like the sync process after the Merge. Approaching the Merge, we plan to have a new model of a tesnet each time a batch of changes are made to the spec. The next restart is planned for early November.

Clarissa Watson: Given Raul Jordan’s statement on client diversity, was there an effort to use Teku and Besu to support different clients during devnet development?

Sajida Zouarhi: Client diversity is important especially when a client has supermajority: more than 2/3 of the staked ETH. If a problem occurs on a majority client, the entire blockchain will be affected. However, if we have a healthy distribution amongst clients -- not necessarily equal -- it will mitigate this risk greatly. 

In a post-Merge context, two types of clients will be running in sync. On the execution layer for example, we would have Besu, and on the consensus layer that would be Teku. The complex part here is the need for diversity on both layers. This is why having Teku and Besu perform well across 4 combinations respectively during this interop week was an important step towards contributing to Ethereum’s security after the Merge.

Keep track of the Merge & reach out on Discord

The teams will continue to ensure all clients can work together on the devnets to prepare for the Merge. To keep track of their progress, follow Consensys Product Owner, Ben Edgington for weekly updates on the Merge here and The Ethereum Foundation blog. You can learn more about how client diversity increases network resilience and performance in Teku and Besu documentation. Please join our discord channel where you can discuss any questions you have about this article with Consensys engineers and product managers working on the Merge. 

The progress made during the Amphora Interop is astonishing. The Merge will upgrade Ethereum to new heights, making it more scalable, secure, and sustainable. The future of Ethereum is now!