Ethereum Merge Plan A and Plan B

You should definitely read this week, Tim Beiko brings you AllCoreDevs Update 011, a comprehensive look at what’s left for Ethereum on the road to a merge.

So the question is, when will the merger take place?

This is the only question many people are interested in right now, and the official answer is "when it's ready," which is true, but not very helpful. So, let's break it down.

This involves two somewhat separate parts that make predictions less straightforward. The first part is the easy part, client readiness for the merge, while the second part is Ethereum’s difficulty bomb.

What is Ethereum’s difficulty bomb?

The difficulty bomb (sometimes referred to as the ice age) is a mechanism that has existed since the early days of Ethereum. Its function is to start exponentially increasing the difficulty of mining proof-of-work (PoW) blocks after reaching a certain block height, which in turn increases the interval between blocks. There is currently a Dune dashboard that shows how the block production rate drops rapidly as the difficulty bomb takes effect, and then we can recover by resetting it through a hard fork.

The idea of ​​the difficulty bomb was twofold. First, it provided a mandatory feature for developers. Removing or delaying the difficulty bomb required a hard fork. The idea was that if we were to do this via a hard fork, then we would use that opportunity to upgrade the protocol. Especially in the early days, the purpose of the difficulty bomb was to encourage a rapid move to a proof-of-stake consensus mechanism. In my opinion, it has mostly failed in this regard, as evidenced by (a) we still haven't successfully moved to PoS and have delayed the difficulty bomb at least 5 times, and (b) both Arrow Glacier and Muir Glacier hard forks only delayed the difficulty bomb and did nothing else. Its main impact was just to complicate the plan.

The second, more realistic purpose of the difficulty bomb is to prevent miners from continuing to participate in PoW mining after PoS is activated. Miners need to remove the difficulty bomb themselves, which is not difficult (only one line of code), but the existence of the difficulty bomb effectively forces miners to maintain their own ETH1 client branch after the merger.

Regardless, the point is that the current iteration of the difficulty bomb will become noticeable very quickly.

Plan A and Plan B

The ideal path (Plan A) is to merge before the difficulty bomb becomes a big problem. The fallback option (Plan B) is to do another hard fork that only delays the bomb, buying a few more months to prepare for the merge.

So, it’s a race, and plan A is optimal, but it depends on everything being fully ready before the difficulty bomb destroys Ethereum. But we don’t know when that will be, because the timing will be affected by overall hashrate, and we don’t know exactly how ready clients are to merge.

The bottom line is that we hope to have more clarity on both of these things by the end of May. By then (or a few weeks after that), we will have to decide whether to go for it, or to delay the difficulty bomb with a hard fork as Plan B. We can’t let the decision-making take too long, because organizing a hard fork to remove the difficulty bomb would also take several weeks if needed.

So far, progress on the test merge appears to be going smoothly (see below), and the latest analysis suggests that the difficulty bomb will not become a serious problem for Ethereum until mid/late August, when average block times may rise to 20 seconds.

If I were a gambler, I would bet some USDC on the August merge and not delay the difficulty bomb. But this is by no means financial advice, and don’t cry to me if you lose your shirt.

Tim Beiko gives his own take on the merge timeline (which I don't think is substantially different from what is discussed above).

You can join the EF mailing list to get updates.

Test Merge

See Tim's ACD Update for an overview of #TestingTheMerge . You can find notes from the weekly merge testing call here.

Before we get into what developers are doing to test the merge, I want to emphasize that if you run any infrastructure on Ethereum, you need to get involved in the merge testing as well. It’s the only real way to ensure that your project doesn’t break while we’re at it. To that end, my colleague Sajida put together a merge testing leaderboard‌ to track who’s doing the testing.

Mainnet Shadow Fork

Since I last wrote about merge testing, we’ve done 3 mainnet shadow forks, including one in Amsterdam.

Mainnet shadow forks are a great test of the merge mechanics and client readiness. They are more or less equivalent to a mainnet merge (although the Ethereum Foundation and development team currently control all validators, which makes shadow forks slightly easier). Shadow forks are so cool that I won’t go into all the details, but in general, these tests have been a huge success so far.

• The first mainnet shadow fork occurred on April 11th. Here is a summary from Pari:

Marius announced that this shadow fork was a huge success. During the test, a configuration problem related to gas limit was found in the Geth client, but the problem was not very serious. There were various problems with different clients, but these problems were discovered and solved.

• The second mainnet shadow fork occurred during the Devconnect conference on April 23. Here is a summary from Pari:

This is the first shadow fork in which every client survived the merge and managed to stay in sync afterwards, we are making real progress here!

• The third mainnet shadow fork occurred on May 5, and this test also passed very smoothly.

You can find more information in the developer conference call transcript.

These include some new tests on merge sync which found some issues, but they are definitely fixable.

In addition, the Goerli testnet also performed 4 shadow forks.

On top of that, we plan to merge three existing Ethereum testnets in June: Ropsten, Sepolia, and Goerli.

Beacon Chain Milestones

As of now, over 10% of all ETH is staked in the Eth2 deposit contract. hildobby.eth has put together a nice deposit dashboard that shows the status and history of staked deposits. The number of active validators is currently approaching 370k and growing faster than ever.

In addition, we have some good news on client diversity, with Prysm now at less than 50% market share, which is a healthier state for the entire beacon chain. In the previous few months, Prysm had over 68% market share, which is a very unstable situation. It seems that writing some warning articles really helps, but seriously, I want to pay tribute to the individuals and institutions who are desperate and invest time and energy to make changes, because with you, Ethereum is stronger and more secure.

Of course, the battle is not over yet. The next thing to improve is the diversity of execution clients, which is even worse than the diversity of consensus clients before.

Staking

The staking page on ethereum.org has been completely revamped and is very slick.

While Lido has come under some scrutiny recently, and as a tool that has reached over 30% of the staking market share, this is exactly the right thing to do. This seems to have triggered a flurry of transparency. The next chapter for Lido is the updated decentralization roadmap that I requested in early March. In addition to this, they also shared Lido’s operator strategy. Superphiz has some thoughts on all of this.

Also from Lido, they published a paper titled "Modeling The Entry Queue Post-Merge‌", analyzing how mergers may affect Lido's socialized reward model when the validator activation queue is very long.

As for Rocket Pool, Bits Be Trippin gave an overview of Rocket Pool in an interview with Darren Langley. Rocket Pool announced support for Besu and Nethermind as Eth1 clients in its latest beta. Yay, client diversity!

Recommended popular science articles

• What are these shadow forks that developers have been doing? Yash Kamal Chaturvedi’s article explains a bit.

• ConsenSys has built a nice merge knowledge base, and there are a few recent articles that are worth your time:

1. The four pillars of the merger‌;

2. For PoS, here’s a video playlist of excerpts from interviews with Tim Beiko, Matt Nelson, and Chris Anatalio‌, and keep an eye out for a follow-up interview with Justin Drake on Monday.

• Here's a post for API nerds: Adrian Sutton of the Teku team wrote about the work the team has done around JSON type definitions. A large part of client development workload is this behind-the-scenes heavy lifting. It's all good stuff.

• The article from Adrian on the topic of stealing inclusion fees from public beacon chain nodes‌ serves as a cautionary tale for those running validators who may want to rely on third-party services after the execution client merge. It’s time to get your own execution client up and running.

• This is Alex Stokes talking about withdrawals at the PEEPaNEIP conference. Alex is a great explainer.

• bartek.eth has a really good post about KZG commitments, and I gave a short talk on the topic at Devconnect (slides only, no video yet). Polynomials seem like they’re going to be the data structure of choice going forward for a variety of reasons, so now’s a good time to get up to speed on all this stuff.

• Today’s hot news is Joanne Fuller’s article on formal verification of the Ethereum 2 protocol, “Fixing the Array-Out-of-Bound Runtime Error‌”. I sometimes feel that the formal verification work done by my colleagues on the protocol is underestimated. As Joanne explains, FV is a very powerful tool, and it is very gratifying to verify the protocol like this.

• I finally finished the chapter on randomness in the Eth2 protocol, which turned out to be much more interesting than I expected, but ended up taking much longer than I planned. Probability is so hard! Not sure what I'll tackle next, maybe committees. There are still a few lower-level topics I want to finish before I start moving up.

Note: The original author is ConsenSys developer Ben Edgington.