For me the Merge began in 2015, a month before the launch of Ethereum mainnet. At that distant time, I had joined a small startup and was working on one of the first Ethereum clients. After the startup closed, I started prototyping Hybrid Casper FFG for a Java client with Dmitry Shmatko, where we met Danny Ryan for the first time.

Forming the first Beacon Chain working group

I didn't know it at the time, but we were forming the original Beacon Chain team and were granted permission by the Ethereum Foundation (EF) to continue our work on a fully featured Beacon Chain client in Java. With the progress on what was then called “Eth2,” the first Merge designs authored by Vitalik began to appear. At that time, the plan was to make the Ethereum mainnet one of 64 shards.After working for a year, a big event took place for our  work on Beacon Chain during the Fall of 2019.

Interop Lock-In

Seven teams working on Beacon Chain clients gathered together in Canada for an offsite called, Interop Lock-In with the goal of meeting in person and advancing our work as a team.

During the week we spent together at Interop Lock-In, we made a huge step towards delivering the Beacon Chain. Thanks to Joe, as well as Johnny Rhea and Ben Edgington, the entire team joined Consensys and formed the TXRX R&D team under Joe's leadership. I would like to express my gratitude to Joe, Johnny, and Ben for their efforts to bring our teams together, and a special thanks to the Ethereum Foundation for their support over the year and a half leading up to this event. It was a lot of fun and very productive!

From then on at Consensys R&D, I was under the excellent guidance of Joe Delong and began to work closely on the Merge. I immediately love the idea, because I had deep knowledge on both mainnet and the Beacon Chain that I'd learned while working on the clients of these networks. The value of upgrading Ethereum to PoS, the complexity of the design, and the challenges associated with it greatly fueled my interest and curiosity.

The first forms of PoS

By the time I started working on Merge, several articles had been written on this topic; good examples are posts by Vitalik Buterin and Alex Stokes. At that time, there was an idea to use the Beacon Chain as a Finality gadget for mainnet and the analysis of this design was my first work on a given topic. There was also an idea of a direct transition to PoS as well, bypassing the Finality gadget stage published by Vitalik.

As a result of my initial research, I decided to create a prototype on Teku, in which one of the Eth2 shards was used to store data of the Execution chain. At the same time, Danny Ryan published an article on the separation of concerns between execution and consensus clients. Guillaume Ballet helped a lot with the prototype by creating Catalyst - the first prototype of the Execution Layer client. By this time, we started to have regular calls on the Merge, mostly to coordinate our efforts. The prototype was created and we moved on.

The roll-up centric roadmap & Beacon Chain launch

After some time, Vitalik published the Rollup-centric roadmap that started to make sense, because of the progress on rollups and the Merge, which moved us away from the idea of executable shards.

In one of the channels we used back in those days, we discussed the idea of moving an execution payload from a shard to the Beacon Chain. With this idea in mind, I published the Executable Beacon Chain Proposal, with key points that are included in the current design of Merge today.

Almost simultaneously with this proposal, the deposit contract was deployed and the Beacon Chain was launched! After publishing the proposal, I updated the Teku prototype, and consequently created the first prototype of the Consensus Layer clients. Next, Guillaume and I presented the Executable Beacon Chain and post-Merge client architecture at the R&D workshop hosted by the Ethereum Foundation.

There was a concern from Martin and Peter from the Geth team on plans to deprecate mainnet at the Merge, which would break an invariant of serving the chain’s history and significantly affect client sync algorithms. 

After the presentation, the idea of simply replacing the PoW consensus engine with the Beacon Chain and leaving everything else as it is came to my mind. I discussed this idea with Danny and Tim on one of the calls. There was a general consensus that this approach was reasonable, and starting from that moment, a high-level design of PoS Ethereum was settled upon.down. A huge amount of work on figuring out the details and writing specifications came next. 

Contributing to Merge specs

I will never forget my first major spec contribution. At the same time, Vitalik published the Quick merge proposal, which described the mechanism of transition to PoS that gave us the Terminal Total Difficulty as the only correct trigger to upgrade the network. I adjusted my version of the Consensus specs with Vitalik’s work, and we had a nearly final version of the entire design, including the Merge transition itself that allowed  for a seamless transition to PoS. This was a very important UX goal that we had from the very beginning.

Next was Rayonism, with Diederik Loerakker (Proto) behind the idea of this project, whom we all know for his outstanding contribution to the specification and design of the Beacon Chain. 

Proto created many tools and spent a lot of his time working on Rayonism, which resulted in the launch of the first multi-client devnet. I am very grateful to him for this project, starting from picking up the name, continuing with the development coordination, his work on the tooling, block explorer, and monitor fork patches, and just for the great working atmosphere we had there. It was an exhausting two weeks, but the result paid off all the efforts. The most important outcome of this project was participation of all Consensus layer  and Execution layer client teams. For the first time the Merge specs and design got so much attention from client developers, who made first prototypes of their client’s feedback on the Merge. The initial version of the Engine API allowing both types of CL clients to communicate with each other were also designed during Rayonism.

After Rayonism, work on Merge began to develop like a snowball, involving more and more developers and community attention. In the summer of 2021, a lot of work was done on the specifications. EIP-3675  was the first one with my co-authorship and Engine API specifications were also written during that time. Also, my teammate Dmitry Shmatko published his analysis on Terminal total difficulty as a trigger for the Merge upgrade on Mainnet.

Regrouping in Greece

Then, we had the Amphora Interop meet up  in Greece. By that time two years had passed  since Interop Lock-In in Canada and it was great to again gather all in one place to take a step towards one of the biggest and the most important goals in the history of Ethereum. There were a lot of new faces, great talks and an exciting atmosphere. I am very grateful to sponsors, organizers, and participants who made that meet up happen. In the evening of the last day of the event the first persistent devnet was launched - a great result of a week of rapid spec and software development. I would like to say special thanks to Parithosh Jayanthi and Proto who worked on the testnet infrastructure setup that we still use today to launch various devenets and testnets. Also, Matt Garnett’s Mergemock and general Merge testing effort started by Marius are other great outcomes of the Amphora week. 

After the interop, we accomplished the Kintsugi testnet and currently are at the end of the Kiln sprints. And now, when the specification is considered final and only allows minor changes, or critical fixes, when EIPs are in the Review stage we will be ready to start forking existing testnets and means the Merge is coming! I am very excited and looking forward to it!

From R&D to real impact

My story of working on Merge is an example of true diversification and decentralization of work on an R&D project. This is the right way of doing sophisticated projects that involve a huge amount of complexity in a living ecosystem worth billions of dollars. 

It's important that diversification be reflected by mentioning the names of the developers and researchers who've contributed to the Merge in one way or another in my blog. But even more of these names remain outside the scope of this document. To those unnamed, thank you for your work!

Thank you for your support

It's been a long journey and I am very grateful to all those who've helped me develop my passion about the Merge into an incredible project with an even greater purpose, which is near to be shipped!

Many thanks to Consensys R&D who have enabled me to do this work from day one, supported me, and encouraged me in every possible way.

In particular, I want to thank  my team for the numerous discussions, brainstorms, and diverse support and to the Ethereum Foundation Researchers, who have been a huge help for the Merge project along the way. 

Let’s Merge!

For regular updates and news on the Merge, visit the Consensys Merge Knowledge Base, where you’ll also find Eth2 archives with key milestones achieved and other essential resources for developers.