header-langage
简体中文
繁體中文
English
Scan to Download the APP
Partnered With:

Ethereum Core Developer Conference: Incorporating the Latest developments

Read this article in 14 Minutes
The process of Ethereum's road to merger is unfolded one by one in this paper.
AllCoreDevs Updates
By Tim Beiko
ETH Chinese wechat official account


One year after Rayonism first built a prototype, we now have strong merge implementations across all Ethereum clients.


The path from where we are today to a full transition to proof of ethereum equity is now very clear. We need:


1. Several times there is no problem with the shadow of the main network fork;


2. All clients pass various merge test suites;


3. Successful deployment on the existing public test network.


That's it! Once these conditions are reached, and we observe that they are stable for a few weeks, we are ready for the mainnet merger!



Trent Van Epps created this map of ethereum's full transition from the launch of beacon chain deposit contracts to proof of equity. Note that TTD refers to Terminal Total Difficulty, when the merge occurs.


Let's roll it out one by one.


Shadow bifurcate


Over the past year, we've added a new step to our network upgrade process: Shadow Forks.


There have been several expository articles about shadow forks. In simple terms, shadow forking is a new developer test network created by forking a live network with a few nodes. Shadow forks have the same state, history, and chain ID as the main chain.


An overview of the shadow Fork network by @parithosh_j


Running these shadow forked test nets allows us to observe client performance as close to the public network as possible. At the nodes of the shadow bifurcation network, merging takes place efficiently. Later, transactions on the main network can be replayed on the fork, allowing us to see how the node behaves under the main network condition. We can also synchronize new nodes to the shadow fork to ensure that they still join the network as expected.


During these shadow forks, each execution layer (EL) and consensus layer (CL) combination is tested, with the goal of each client pair transitioning and running smoothly thereafter. We have 4 executive-tier clients and 5 consensus-tier clients, which is 20 pairs to test!



So far, we've had multiple Goerli shadow forks and two mainnet shadow forks. The second main net shadow fork (MSF2) proceeded almost perfectly. The other, MSF3, is scheduled for this week. If MSF3 has no problems and remains stable after that, we can upgrade the existing test network. To be safe, we will continue to fork shadows periodically until (and even during) the test net deployment.


In the meantime, we're redoubling our efforts on some other testing.


Combining test


The merger is a unique upgrade for testing because it cuts across ethereum's execution and consensus layers. While we have many separate testing tools for each layer, a large amount of new infrastructure for testing cross-layer interactions is necessary.


Hive test


Hive is an integration testing platform that we used to perform layer testing. Over the past few months, we've added the ability to simulate consensus layer behavior and use it to test various execution-layer clients. This will help us test the implementation and consensus layer's new Engine APIs for communication. To test PoW -> The PoS transition also requires the addition of emulators that simulate the behavior of the execution layer.


The client team is currently prioritizing supporting Hive and making sure they pass all test suites, while the test team focuses on adding execution-layer mocks to it.


Kurtosis


In addition to our existing test infrastructure, we also cooperate with [Kurtosis] (https://www.kurtosistech.com/), we use it every day automatic build start a short network to run the merge process.


These tools help us find implementation issues on individual clients and monitor various network health indicators. As things stabilize in this regard, our next step is to create even harsher network conditions and see how the client recovers. For example, suspend executive-tier or consensus-tier clients just before the transition and then unsuspend them after the merger; Or, after the merge, remove the databases and see how they handle synchronization.


And everything else


In addition to improving Hive and working with Kurtosis, a long list of testing tools built by the client, research, and test teams helped us discover every possible critical situation. They include fuzzy-testing tools, bad block generators, execution-layer/consensual-layer simulators, debugging apis, and many more fuzzy-testing tools. Here's a wish list of other tools.


Our first priority was to get clients through unit/specification testing and integration testing in Hive and Kurtosis. However, these other tools mentioned above can help us find and debug critical cases that we miss and then incorporate into our regular test suite.


On the human side, merge testing greatly increases coordination and collaboration across teams. For the first time, the consensus and execution client teams must work closely with each other to ensure that their software works with each client on the other layer. This allows for more and deeper collaboration across our testing infrastructure


Public test network


Once the shadow fork goes smoothly and all clients pass the test suite, we will be ready to deploy the merge on the existing public test network, namely Ropsten, Goerli, and Sepolia.


While public test networks don't stress test clients as much as the main network shadow fork does, they require much broader collaboration within the Ethereum ecosystem.


Consolidation requires more node runners than previous Ethereum upgrades. In past upgrades, node operators and miners at the execution level only had to upgrade one piece of software: their execution client. In merge upgrade, they will need to download, configure, and run a consensus layer client at the same time.


In terms of the consensus layer, we have always strongly recommended running an execution-layer node when you run the validator. Although prior to the merger, the running of the executive-tier nodes could be outsourced to a third party service provider. When merging, however, the pledgee will need to run an executive-tier node to validate the block and receive transaction fees when proposing the block (there may be no transaction fees if the executive-tier node is outsourced!).


Node operators, pledgers and infrastructure providers should ensure that their configurations are tested within Kiln in preparation for deployment on the test network. EthStaker also publishes tutorials on how to do this.


Once Ropsten, Goerli, and Sepolia have bifurcated and stabilized (assuming no further problems are found), then we are ready to set a date for the main network to merge!


provids


The transition to proof of equity on the Ethereum main network will be the same as on the test network. That said, it is worth emphasizing again that the transition takes place in three steps:


1. The client releases a version of the software that supports consolidation and starts "listening" for a specific total difficulty value that has been touched on the proof-of-work chain, known as TTD.


2. Once TTD is reached, the next block is packaged by the verifier assigned to the slot in the next beacon chain. This block will be the first block after the merger and will contain end users' transactions as well as proof-of-interest consensus data (i.e., certificates, deposits, forfeitures, etc.).


3. The first combined block is finalized. At this point, proof of work no longer forms part of the Ethereum fork selection rules. In other words, we have completely moved to PoS


The following illustration by Danny Ryan illustrates the process:



The leftmost block shows the execution layer and consensus layer running in parallel before the merger, with the PoW (execution layer) block containing transactions and the beacon chain (consensus layer) block containing consensus data for proof of interest.


The second PoW block on the left is what happens when TTD is touched or exceeded. The third block below is the first block after the merger and contains proof-of-interest consensus data and executive-level transactions.


The fourth block and subsequent blocks are irrelevant to proof of work. Once these blocks are finalized, the network can only be disrupted from that point onwards by something like a 51% attack under proof of work.


In other words,By then, we'll have completed the merger!


The merger is by far the most complex upgrade we have planned for Ethereum. The team and individual contributors have been working tirelessly for over a year now and the finish line is finally in sight.


While everyone is excited to see Ethereum transition to proof of equity, now is not the time to cut corners: ensuring a safe and seamless transition for Ethereum users and the rich ecosystem built on the network is our top priority. We're almost there!


When is the merger? Soon...


Thanks to Trent Van Epps, Danny Ryan, Mario Vega and others for their comments and additions to this update.


The original link


Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit