Partnered With:

ConsenSys Developers: Ethereum merged Plan A and Plan B

Read this article in 15 Minutes

What is left on ethereum's path to consolidation?

原文标题：《以太坊合并的 Plan A 和 Plan B 》

Ben Edgington is a ConsenSys developer

Overnight porridge, the way of the meta-universe

You should definitely read this this week. Tim Beiko is here. AllCoreDevs update 011 gives a comprehensive overview of what's left on ethereum's path to consolidation.

Which begs the question, when is the merger?

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

There are two parts that are somewhat independent, and they make the prediction less straightforward. The first part is simple, the client's readiness for the merger, while the second part is Ethereum's difficulty bomb.

What is ethereum's difficulty bomb?

Difficulty bombs (sometimes referred to as ice ages) are a mechanism that existed in ethereum's early days, and their function is to start exponentially increasing the difficulty of mining proof-of-work (PoW) blocks once a certain block height is reached, which in turn increases the time between blocks. There is one at the moment. The Dune dashboard ‌ shows how block productivity drops rapidly as the difficulty bomb takes effect, which can then be recovered by resetting it with a hard fork.

The idea of difficulty bombs is twofold, first of all it provides a mandatory feature for developers, removing or delaying difficulty bombs requires a hard fork, and the idea is that if we're going to do this through a hard fork, then we'll take the opportunity to upgrade the protocol. Especially in the early days, the difficulty bomb was designed to encourage a rapid shift to proof-of-stake (PoS) consensus mechanisms. In my opinion, it has almost failed in this regard, as evidenced by (a) we still haven't succeeded in switching to PoS and have delayed difficulty bombs at least 5 times, and (b) Both hard forks, Arrow Glacier and Muir Glacier, only delayed difficulty bombs and did nothing else, Its main effect is simply to complicate planning.

The second, more realistic purpose of difficulty bombs is to prevent miners from participating in PoW mining after PoS activation. The miners had to disarm the difficulty bomb themselves, which wasn't difficult (it only took one line of code), but the existence of the difficulty bomb effectively forced the miners to maintain their own ETH1 client branch after the merger.

Anyway, the point is that the current iteration of the difficulty bomb will soon become noticeable.

Plan A and Plan B

The ideal path (Plan A) is to merge before the difficulty bomb becomes A big problem. The alternative (Plan B) is another hard fork that only delays the bomb, giving it a few more months to get ready for the merger.

So, it's A race and plan A is optimal, but it depends on everything being completely ready before the difficulty bomb destroys Ethereum. But we don't know exactly when, because the timing is affected by the overall computing power, and we don't know exactly how ready the client is to merge.

Most importantly, we hope to have a clearer picture of these two things by the end of May. At that point (or in a few weeks after), we'll have to decide whether to go for it or go with a Plan B deferred difficulty bomb called a hard fork. We can't allow decisions to be made too long, because it would take weeks to organize a hard fork to defuse a difficult bomb if needed.

So far, the test merge seems to be going well (see below), and the latest analysis suggests ‌ that difficulty bombs won't become a serious problem for Ethereum until mid/late August, when the average block time could rise to 20 seconds.

If I were a betting man, I would bet some USDC on the August merger and not put off the difficulty bomb. But this is not financial advice, and if you lose your shirt, don't cry to me.

Tim Beiko gives his own take on merging timelines ‌ (which I don't think is substantially different from what was discussed above).

You can join in. EF mailing list ‌ for updates.

Test merger

See Tim's & NBSP; ACD update ‌ to get the p #TestingTheMerge Overview. You can find notes from the weekly merge test call here at ‌.

Before we get into what developers are doing to test merges, I want to emphasize that if you're running any infrastructure on Ethereum, you need to participate in merges as well. That's the only real way to make sure your project doesn't break when we do this. To that end, my colleague Sajida has put together a consolidated test rankings ‌ to keep track of who is testing.

The shadow of the main net bifurcated

Since I last wrote on the topic of merge testing, we've done three mainnet shadow forks, including one in Amsterdam.

The mainnet shadow fork is an excellent test of the merge mechanism and the readiness of the client. They are more or less equivalent to the mainnet merging (although currently the Ethereum Foundation and the development team control all the validators, which makes shadow forking slightly easier). Shadow forks are so cool THAT I won't go into all the details, but overall, these tests have been a huge success so far.

1. The first shadow fork of the main net happened on April 11. The following is a summary from Pari:

Marius declared the shadow fork a great success. During testing, a configuration issue related to gas limits was found in the Geth client, but it was not serious. There were various issues with different clients, but these were found and resolved.

2. The second mainnet shadow fork happened on April 23rd during Devconnect. Here's a summary from Pari:

This is the first shadow fork where every client survived the merge process and managed to keep in sync afterwards, and we're making real progress here!

3. The third main net shadow bifurcation took place on May 5th, and this test also passed smoothly.

For more information, you can find it in the developer conference call transcript.

These included some new tests on merge synchronization that found some problems, but they were definitely fixable.

In addition, the Goerli test network also underwent four shadow forking.

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

Beacon chain milestone

So far, more than 10% of ETH is pledged in Eth2 deposit contracts. Hildobby. Eth assembled a nice deposit dashboard ‌ that shows the status and history of pledged deposits. The number of active validators is currently approaching 370,000 and growing faster than ever.

In addition, we have some good news in terms of client diversity, Prysm's market share is now less than 50%, which is a healthier position for the entire beacon chain. In the first few months, Prysm's market share exceeded 68%, which was very volatile. It seems that writing a few warning articles really helps, but seriously, kudos to the individuals and institutions who are desperate and investing their time and energy to make a difference, because ethereum is stronger and safer because of you.

Of course, the fight is not over. The next improvement is the diversity of execution clients, which is even worse than the diversity of consensus clients.

The pledge

Ethereum.org's pledge page has been completely revamped and is beautiful.

Lido has come under some scrutiny recently, and it is entirely right that Lido is a vehicle with more than 30% of the collateral market. This seems to have triggered a flurry of transparency. Lido's next chapter is the updated decentralization roadmap THAT I requested in early March. Among other things, they shared Lido's carrier strategy. Superphiz has some ideas about all this.

Also from Lido, they published an article entitled Modeling The Entry Queue post-merge ‌ that analyzed how merging might affect Lido's social reward model in The case of very long validator activation queues.

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

Recommended popular Science articles

1. What are the shadow forks the developers have been working on? Yash Kamal Chaturvedi's article ‌ explains some of this.

ConsenSys has built a decent combined knowledge base, and there are a few recent articles that are worth your time:

(1) Four pillars of the merger ‌;

(2) Video playlist of excerpts from interviews with Tim Beiko, Matt Nelson, and Chris Anatalio on PoS ‌, watch for a follow-up interview with Justin Drake on Monday.

3. This is an article for API nerds: Teku's Adrian Sutton wrote team Around & NBSP; The JSON type defines the work done by ‌. A big part of client development is this behind-the-scenes grunt work. All good stuff.

4. The article from Adrian on the subject of stealing the inclusion fee from the common beacon chain node ‌ is a cautionary tale for those running validators who may wish to rely on third party services after performing client merges. It's time to get your own execution client up and running.

5. Here's Alex Stokes talking about withdrawals at the PEEPanEIP conference ‌, Alex is a great explicator.

6. Bartek. Eth has a review of & NBSP; Very good post from KZG promise ‌, I did a short talk on the topic of KZG promise on Devconnect (slides only, video not yet found). Polynomials seem to be the preferred data structure of the future for a variety of reasons, so now is a good time to get a grip on all this stuff.

Fixing the Array-in-out-of-Bound Runtime Error‌, Joanne Fuller's article on formal verification of ethereum 2 protocols, I sometimes feel that the work my colleagues do on formal verification of ethereum 2 protocols is underestimated, As Joanne explains, FV is a very powerful tool, and it is very comforting to validate protocols like this.

8. I finally finished the chapter on randomness in the Eth2 protocol, which turned out to be a lot more fun than I expected, but ultimately took a lot longer than I had planned. Probability is too hard! I don't know what I'm going to challenge next, but maybe the committee. Before I start moving up, I want to finish some lower-level topics.