ETHEREUM

ConsenSys Developer: Ethereum's Plan A and Plan B for Merge

2022/5/12

This week you definitely should read this, Tim Beiko brings AllCoreDevs Update 011, which comprehensively tells us what is left for Ethereum on the road to merge.

This article is authorized for reprint from The Way of Metaverse, original here.

So when is the merge happening?

Advertisement - Continue scrolling for more

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

This involves two somewhat independent parts, making predictions not so straightforward. The first part is straightforward, the state of client readiness for the merge, and the second part is Ethereum's difficulty bomb.

Table of Contents

What is Ethereum's Difficulty Bomb?

The Difficulty Bomb (sometimes referred to as the Ice Age) is a mechanism that has been present in Ethereum since the early days. Its function is to exponentially increase the difficulty of Proof of Work (PoW) block mining after reaching a certain block height, which in turn increases the time interval between blocks. Currently, there is a Dune dashboard that shows how block production rate rapidly decreases as the Difficulty Bomb takes effect, and then we can reset it through a hard fork.

The idea behind the Difficulty Bomb is twofold. First, it provides developers with a forcing function where dismantling or delaying the Difficulty Bomb requires a hard fork. Our idea is that if we are going to do this through a hard fork, then we will take the opportunity to upgrade the protocol.

Especially in the early days, the purpose of the Difficulty Bomb was to encourage a swift transition to the Proof of Stake (PoS) consensus mechanism. In my view, it has almost failed in this regard, evidenced by (a) we still have not successfully transitioned to PoS and have delayed the Difficulty Bomb at least 5 times, and (b) both Arrow Glacier and Muir Glacier hard forks only postponed the Difficulty Bomb without doing anything else, making the plan more complicated.

The second, more practical purpose of the Difficulty Bomb is to deter miners from continuing to mine PoW after PoS activation. Miners need to dismantle the Difficulty Bomb themselves, which is not difficult (just one line of code), but the presence of the Difficulty Bomb effectively forces miners to maintain their ETH1 client branch after the merge.

Regardless, the current iteration of the Difficulty Bomb will soon become significant.

Plan A and Plan B

The ideal path (Plan A) is to merge before the Difficulty Bomb becomes a major issue. The fallback option (Plan B) is to undergo another hard fork solely to delay the bomb and buy a few more months to prepare for the merge.

So, it's a race, with Plan A being optimal, but it depends on having everything fully ready before the Difficulty Bomb disrupts Ethereum. We don't know the exact timing as it will be influenced by the overall hashrate, and we also don't have a precise understanding of the client merge readiness.

Most importantly, we hope to have a clearer picture on both fronts by the end of May. By then (or in the weeks following), we will have to decide whether to push for it or use a hard fork as Plan B to delay the Difficulty Bomb. We can't afford to delay the decision-making process too much, as organizing a hard fork to dismantle the Difficulty Bomb will also take weeks if needed.

As of now, progress on testing the merge seems to be going smoothly (see below), with the latest analysis indicating that the Difficulty Bomb will only become a serious issue for Ethereum in mid to late August, by which time the average block time may rise to 20 seconds.

If I were a betting person, I'd wager some USDC on the merge happening in August rather than delaying the Difficulty Bomb. But this is by no means financial advice, and if you lose your shirt, don't come crying to me.

Tim Beiko has offered his own take on the merge timeline (which I believe doesn't substantially differ from the discussion above).

You can join the EF mailing list for updates.

Merge Testing

Refer to Tim's ACD update for an overview of #TestingTheMerge. Notes from weekly merge test calls can be found here.

Before we delve 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. This is the only real way to ensure that your project doesn't break when we do this. To that end, my colleague Sajida has put together a merge testing leaderboard to track who is participating in testing.

Mainnet Shadow Forks

Since my last write-up on merge testing, we have completed 3 mainnet shadow forks, one of which was in Amsterdam.

Mainnet shadow forks serve as excellent tests for the merge mechanism and client readiness. They are more or less equivalent to a mainnet merge (although currently all validators are controlled by the Ethereum Foundation and development teams, making shadow forks slightly easier). Shadow forks are cool, I won't go into all the details, but overall, these tests have been hugely successful so far.

1. The first mainnet shadow fork on April 11 had the following summary from Pari:

Marius announced that this shadow fork was a massive success, identifying a gas limit configuration issue in the Geth client during testing, which was not severe, various issues with different clients were identified and resolved.

2. The second mainnet shadow fork during the Devconnect on April 23 had the following summary from Pari:

It was the first time that every client survived the merge process and managed to stay in sync afterward, we made real progress here!

3. The third mainnet shadow fork on May 5 also passed smoothly.

More information can be found in the developer call notes.

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

In addition, there have been 4 shadow forks on the Goerli testnet.

Most importantly, we plan to merge the three existing Ethereum testnets—Ropsten, Sepolia, and Goerli—in June.

Beacon Chain Milestones

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

Additionally, in terms of client diversity, we have some good news as Prysm's market share is now below 50%, which is a healthier state for the entire Beacon Chain. In the previous months, Prysm's market share was over 68%, which was very unstable. It seems that writing some cautionary articles really worked, but truth be told, credit goes to individuals and institutions who have made changes despite all odds, as it is because of you that Ethereum is becoming stronger and more secure.

Of course, the battle is not over yet. The next improvement to be made is in client diversity for execution, which is even worse than previous consensus client diversity.

Staking

The ethereum.org staking page has been completely revamped and looks very nice.

Recently, Lido has come under some scrutiny, and as a tool with a market share of over 30% in the staking market, this practice is entirely correct. This seems to have triggered a series of transparency actions. The next chapter for Lido is the decentralized roadmap update I requested in early March. In addition, they shared Lido's operator strategy. Superphiz has some thoughts on all of this.

Also from Lido, they published an article titled "Modeling The Entry Queue Post-Merge," analyzing how the merge might impact Lido's social reward model in the case of a long queue of validators awaiting activation.

Regarding Rocket Pool, Bits Be Trippin provided 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 test release. Yay for client diversity!