Original title: "Plan A and Plan B of Ethereum Merger"
Compilation of the original text: Overnight Porridge
Compilation of the original text: Overnight Porridge
You should definitely be reading this this week, Tim Beiko bringsAllCoreDevs Update 011, this article comprehensively tells us what is left of Ethereum on the road to merger.
Then the question comes, when to merge?
That's the only question a lot of people are interested in right now, and while the official answer is "when it's ready", which is true, it's not very helpful. So, let's break it down.
This involves two somewhat separate parts that make forecasting less straightforward. The first part is simple, client readiness for the merge, while the second part is Ethereum's difficulty bomb.
What is Ethereum's Difficulty Bomb?
Dune DashboardDune DashboardShows how the block production rate drops rapidly with the difficulty bomb in effect, and then we can recover it by resetting it via a hard fork.
The idea of the difficulty bomb is twofold, first it provides a mandatory function for developers, dismantling or delaying the difficulty bomb requires a hard fork, the idea is that if we are going to do this through a hard fork, then we will Use this opportunity for protocol upgrades. Especially in the early days, the purpose of the difficulty bomb was to encourage a rapid move to a proof-of-stake (PoS) consensus mechanism. In my opinion, it has pretty much failed at this, as evidenced by (a) we still haven't successfully moved to PoS, and have delayed the difficulty bomb at least 5 times, and (b) the two hardscores of Arrow Glacier and Muir Glacier Both forks only delayed the difficulty bomb and did nothing else, its main effect was just to complicate the plan.
The second and 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 defuse 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 fork after the merge.
Anyway, the point is, 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. And the backup option (Plan B) is to do another hard fork that only delays the bomb to gain a few more months to get ready for the merge.
So, it's a race, plan A is optimal, but it depends on everything being fully in place before the difficulty bomb destroys ethereum. But we don't know the exact time, because the time will be affected by the overall computing power, and we don't know exactly the merge readiness of the client.
Most importantly, we hope to have more clarity on these two matters by the end of May. At that point (or in the weeks after that), we'll have to decide whether to go for it, or delay the difficulty bomb with a hard fork, Plan B. We cannot allow the decision to be made for too long, as it will take weeks to organize a hard fork to dismantle the difficulty bomb, if required.
As of now, the progress of the test merge seems to be smooth (see below),The latest analysis shows, the difficulty bomb will not become a serious problem for Ethereum until mid/late August, when the average block time may rise to 20 seconds.
If I were a gambler, I'd bet some USDC on the August merger without delaying 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 onmerged timelineview (which I don't think is substantially different from the one discussed above).
you can joinEF mailing listtest merge
test merge
See Tim'sACD updatefor an overview of #TestingTheMerge. You can find notes from the weekly merge test call here.
Before we get into what the developers are doing to test the merge, I want to emphasize that if you run any infrastructure on Ethereum, you also need to be involved in the merge to test. This is the only real way to make sure your project won't break while we do it. To this end, my colleague Sajida put together aMerge Test LeaderboardMainnet shadow fork
Mainnet shadow fork
Since I last wrote about the merge test, we have done 3 mainnet shadow forks, one of which was in Amsterdam.
The mainnet shadow fork is an excellent test of the merge mechanism and the readiness of clients. They are more or less equivalent to mainnet for merging (although currently the Ethereum Foundation and development team control all validators, making shadow forks slightly easier). The shadow fork is so cool, I won't go into all the details, but overall the tests have been a great success so far.
1. The first mainnet shadow fork occurred on April 11. The following is a summary from Pari:
Marius announced that the shadow fork was a great success. During the test, a configuration problem related to the gas limit was found in the Geth client, but the problem was not very serious. Different clients have various problems. , but these problems were discovered and resolved.
2. The second mainnet shadow fork occurred during the Devconnect conference on April 23. The following is a summary from Pari:
This is the first shadow fork where every client has survived the merge and managed to stay in sync afterwards, and we're making real progress here!
3. The third shadow fork of the mainnet took place on May 5, and this test passed very smoothly.
You can find more information on the developer conference call transcript.
This includes some new tests on merge sync, which found some issues, but they are definitely fixable.
In addition, the Goerli testnet has also undergone 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, more than 10% of ETH is pledged in the Eth2 deposit contract. hildobby.eth put together a nice deposit dashboard that shows the status and history of pledge deposits. The number of active validators is now approaching 370,000 and growing faster than ever.
In addition, in terms of client diversity, we also have some good news. Prysm's market share is now less than 50%, which is a healthier state for the entire beacon chain. In the first few months, Prysm's market share exceeded 68%, which is a very unstable situation. Seems like it would be useful to write some warning articles, but seriously, kudos to the individuals and institutions who are desperate and put in the time and energy to make a difference, Ethereum is stronger and more secure because of you.
pledge
pledge
The ethereum.org staking page has been completely revamped, and it's beautiful.
While Lido has come under some scrutiny recently, as a tool with over 30% of the staking market, Lido is absolutely right. This seems to set off a cascade of transparency. The next chapter for Lido is the updated decentralization roadmap I requested in early March. Besides that, they also shared Lido's operator strategy. Superphiz has some ideas about it all.
Also from Lido, they published an article titled "Modeling The Entry Queue Post-Merge", which analyzes 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 of Rocket Pool in an interview with Darren Langley. Rocket Pool has announced support for Besu and Nethermind as Eth1 clients in its latest beta release. Yay, client diversity!
Recommended Popular Science Articles
articlearticleexplains some.
2. ConsenSys has established a nice merged knowledge base, and there are a few recent articles that are worth your time to read:
（1）Four Pillars of Consolidation；
(2) Regarding PoS, Tim Beiko, Matt Nelson and Chris AnatalioInterview Excerpt Video Playlist, look out for a follow-up interview with Justin Drake on Monday.
3. Here's an article for the API nerds: Adrian Sutton of the Teku team writes about theJSON type definitionwork done. A large part of the workload of client development is this behind-the-scenes heavy lifting. All good stuff.
4. From Adrian's article on the subject ofStealing inclusion fees from public beacon chain nodes, which is a cautionary tale for those running validators who may wish to rely on third-party services after performing client-side merges. Time to get your own execution client up and running.
5. This is what Alex Stokes talked about at the PEEPanEIP conferencewithdrawal topic, Alex is a great explainer.
6. bartek.eth has aKZG CommitmentVery nice post, I gave a short talk at Devconnect on the topic of KZG commitments (only slides, no video yet). Polynomials seem to be the data structure of choice going forward for a variety of reasons, so now is a good time to get a handle on all this stuff.
7. 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 my colleagues are doing on the protocol is underrated, as Joanne explained, FV is a very powerful tool, and verifying a protocol like this is very gratifying.
8. I finally finished the chapter on randomness in the Eth2 protocol, which turned out to be a lot more interesting than I expected, but ended up taking a lot longer than I planned. The probability is too difficult! Don't know what I'm going to challenge next, maybe it will be a committee. Before I start moving up, I also want to finish some lower level topics.
