Original source: AllCoreDevs Updates
Author: Tim Beiko
Original translation: ETH Chinese WeChat public account
A year after Rayonism first built a prototype, we now have a robust merged implementation across all Ethereum clients.
The path from where we are today to fully transitioning to Proof-of-Stake on Ethereum is now very clear. we need to:
1. Several mainnet shadow forks without problems;
2. Clients have passed various merge test suites;
3. Successful deployment in the existing public testnet.
And that's all! Once these conditions are met, and we observe that they are stable within a few weeks, we can prepare for the mainnet merge!
Trent Van Epps made this map of the journey from the launch of the Beacon Chain deposit contract to Ethereum's full transition to proof-of-stake. Note that TTD refers to Terminal Total Difficulty, i.e. when the merge occurs.
shadow fork
shadow fork
Over the past year, we have added a new step to our network upgrade process: Shadow Forks.
image description
An overview of the shadow fork network by @parithosh_j
Running these shadow fork testnets allows us to observe how clients behave under conditions as close as possible to the public network. On the nodes of the shadow forked network, the merge effectively occurs. Later, transactions on the mainnet can be replayed on the fork, allowing us to see how nodes behave under mainnet conditions. We can also sync new nodes to the shadow fork to ensure they still join the network as expected.
During these shadow forks, every combination of Execution Layer (EL) and Consensus Layer (CL) is tested, and our goal is for each pair of clients to transition and run smoothly thereafter. We have 4 execution layer clients and 5 consensus layer clients, which means there are 20 pairs of combinations to test!
So far we have had multiple Goerli shadow forks and two mainnet shadow forks. The second mainnet shadow fork (MSF2) went almost flawlessly. Another, MSF3, is set to take place this week. If there are no problems with MSF3 and it remains stable afterwards, we can upgrade the existing testnet. To be on the safe side, we will continue to do regular shadow forks before (and even during) the testnet deployment.
In the meantime, we're also doubling down on some other testing efforts.
merge test
The merge is a unique upgrade for testing because it spans ethereum's execution and consensus layers. While we have a lot of individual testing tools for each layer, a lot of new infrastructure for testing cross-layer interactions is necessary.
Hive test
Hive is an integration testing platform that we previously used for testing at the execution layer. Over the past few months, we've added the ability to simulate the behavior of the consensus layer and used it to test various execution layer clients. This helps us test the new Engine APIs that the execution and consensus layers use to communicate. In order to test the transition from PoW -> PoS, it is also necessary to add a simulator that simulates the behavior of the execution layer.
The client team is currently prioritizing support for Hive and making sure they pass all test suites while the test team is focused on adding execution layer mocks to it.
Kurtosis
In addition to our existing testing infrastructure, we are also working with [Kurtosis] (https://www.kurtosistech.com/), which we use to automatically spin up an ephemeral network every day to run the merge process.
These tools help us discover implementation issues on individual clients and monitor various network health indicators. As the situation stabilizes on this front, our next step is to create harsher network conditions and see how clients recover. For example, suspend the execution layer or consensus layer clients just before the transition and then unpause them after the merge; or remove the database after the merge and see how they handle syncing.
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 find every possible corner case. They include fuzzing tools, bad block generators, execution layer/consensus layer simulators, debugging APIs, and more fuzzing tools. Here's a wish list of other tools.
Our first priority is to get the client to pass unit/spec tests, as well as integration tests in Hive and Kurtosis. However, these other tools mentioned above can help us find and debug corner cases that we miss, which we then incorporate into our regular test suite.
On the human side, merge testing greatly increases cross-team coordination and collaboration. For the first time, the consensus layer and execution layer client teams must work closely with each other to ensure their software works with every client on the other layer. This allows for more and deeper collaboration across our testing infrastructure
public testnet
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 testnets, namely Ropsten, Goerli and Sepolia.
While public testnets do not stress test clients as much as mainnet shadow forks, they require broader collaboration within the Ethereum ecosystem.
The merger requires more node runners than previous Ethereum upgrades. In past upgrades, node operators and miners on the executive layer only needed to upgrade one piece of software: their executive layer clients. In merged upgrades, 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 executive layer node along with validators. Although before the merger, the operation of the execution layer nodes can be outsourced to third-party service providers. But when merging, the pledger will need to run an execution layer node to verify the validity of the block, and receive transaction fees when proposing the block (outsourcing the operation of the execution layer node may not receive transaction fees!)
Node operators, stakers, and infrastructure providers should ensure their configurations are tested on Kiln in preparation for deployment on the testnet. EthStaker has also published various tutorials on how to do this.
main network
main network
The transition to proof-of-stake on the Ethereum mainnet will be the same as it was on the testnet. That said, it's worth emphasizing again that the transition happens in three steps:
1. The client releases a software version that supports merging, and begins to "listen" to a specific total difficulty value that is reached on the proof-of-work chain, that is, the final total difficulty (TTD).
2. Once the TTD is reached, the next block will be packaged by the verifier assigned to the next beacon chain slot. This block will be the first block after the merge, containing end-user transactions as well as proof-of-stake consensus data (i.e. proofs, deposits, slashing, etc.).
3. The first merged 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 diagram by Danny Ryan illustrates the process:
The leftmost block shows the execution and consensus layers running in parallel before merging, where PoW (execution layer) blocks contain transactions and beacon chain (consensus layer) blocks contain proof-of-stake consensus data.
The second PoW block from the left is when the TTD is reached or exceeded. The third block below is the first block after the merger, which contains proof-of-stake consensus data and execution layer transactions.
in other words,
in other words,At that point, we're done merging!
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-stake, this is no 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 are almost there!
When will it be merged? soon. . .
Original link
