The PoS merger is the current focus of Ethereum’s work. The overall plan for the merger has been determined, and the client team will complete a series of tasks in the next few months.
Original title: “Ethereum Core Developer Conference Update 006”
Written by: Tim Beiko
Translation: ETH Chinese Station
This update is a bit different from the previous ones. First, I decided to move to Mirror to release updates. It was a great experience to use this platform for the 1559 NFT project, and I have been looking for opportunities to use it again. I will keep a list of updates on HackMD so that they can be easily found in one place.
Second, since our current work focuses on the merger (The Merge), this article is not actually an “update”, but an in-depth discussion of the evolution of the roadmap to the current architecture choices. In a few weeks, there will be a similar article detailing how the Ethereum network will operate after the merger.
Merged prehistory 📜
The merger will convert Ethereum’s current Proof of Work (PoW) consensus algorithm to a Proof of Stake (PoS) mechanism running on the beacon chain. This design is the result of multiple iterations of the “Ethereum 2.0” roadmap. Let us review the changes in the road map over the past few years.
Phase 0️⃣, 1️⃣, 2️⃣
For several years, the development of proof of stake and sharding have been independent of each other. At a seminar in Taipei in 2018, everyone decided to unify these two research plans to form a three-phase “Ethereum 2.0” roadmap. In this article, Ben Edginton made a very good summary of the seminar and the general idea at that time. It was at this event that Hsiao-Wei showed this now-known “Ethereum 2.0” sketch:
This picture shows what will be delivered at each stage of the new roadmap at that time:
Phase 0 will bring the beacon chain
In phase 1, data fragmentation will be added
In phase 2, a virtual machine is added to each shard to implement calculations in the system.
The number of shards was initially set at 100, then increased to 1024, and recently reduced to 64.
Merge early 🌅
As work on the beacon chain starts in 2018, it is clear that this three-phase Ethereum 2.0 roadmap will take several years to be fully delivered. Along with the growth pains brought about by the rapid increase in the number of people using Ethereum, this has brought about the revival of the proof-of-work blockchain research program. At Devcon IV in 2018, the term “Ethereum 1.x” was proposed to cover these research projects. One of the most important is Stateless Ethereum. This paradigm removes unvisited states from the network to limit the rate of state expansion.
On the one hand, more and more attention is being paid to making the PoW chain sustainable in the long-term. On the other hand, developers realize that the beacon chain can be implemented earlier than other parts of the Ethereum 2.0 roadmap. There was a proposal for “early merger”. This proposal starts the existing EVM chain as the “shard 0” of the Ethereum 2.0 system. This will not only speed up the move to proof of rights, but also make the transition to the application layer smoother, because moving to proof of rights does not require migration on the application layer.
Soon after the proposal came out, Danny Ryan explored in his article “Eth1+Eth2 client relationship (Eth1+Eth2 client relationship)” how we can achieve early mergers by using existing Eth1 clients. This will greatly reduce the development work of delivering a merged system and using the client, because the Eth1 client has been battle-tested on the mainnet. Going down this path can also give researchers more time to solve the open problems of phases 1 and 2 (see here), and stateless Ethereum (which is still a very active research area).
Road map centered on Rollup🎯
Soon the end of 2020 is coming: the progress of stage 0 at this time has reached 99%, and the beacon chain is about to start soon. Although the work in phase 1 is progressing smoothly, there are still many unresolved problems in phase 2, which will implement computing functions on the shards introduced in phase 1:
How to smoothly transition from the current EVM chain to a fragmented virtual machine?
From a performance perspective, what alternative virtual machines can be deployed?
How do we ensure that various virtual machines are really safe?
How to coordinate the status and balance on all virtual machines?
……
At the same time, very rapid progress is taking place in rollup (such as the second-tier expansion plan). Several teams announced that they would be on the testnet and achieved encouraging early results.
Around this time, Vitalik published a long article on the Ethereum Magicians forum, stating that we should focus our short- and medium-term expansion work on rollup. Not only will they be on the mainnet before the completion of Phase 2, but they will also be the biggest beneficiaries of Phase 1. Rollup generates a large amount of data, and sharding can provide it with lower storage consumption than the EVM chain. Below is a screenshot of the article:
This approach will have several impacts on the phase 0-2 roadmap. details as follows:
Phase 0 (beacon chain) was in the stage of running on the testnet before deploying the main network. Once the PoW chain is ready, the beacon chain can become the consensus layer engine without waiting until after Phase 2;
The realization of Phase 1 (data slicing) will take several years. It has changed from a key obstacle to expansion into an incremental improvement, which will reduce the overhead of already developed expansion schemes (such as rollup);
Phase 2 (fragmented execution) is a more complex function with the most open research issues. It can be launched in a few years or be cancelled completely without any impact on the expansion roadmap.
The research community quickly gathered on this proposal and published an ethresear.ch article within a month, detailing the current merger plan!
Current & Future Roadmap🗺
Executable beacon chain⛓
The current merged architecture was first detailed in the “Executable Beacon Chain” published by Mikhail Kalinin in November 2020. In short, it combines the insights of the Ethereum 2.0 roadmap that has been iterated over multiple iterations:
The beacon chain has been launched and can now be used as a consensus engine;
Rollup is the best short-term solution for extended computing;
The current Eth1 client is the best basis for the merged execution layer;
Moving to proof of equity can be achieved in a way that has the least impact on the currently running application
A major change proposed by Mikhail is that instead of making the current EVM chain “shard 0”, it is better to connect directly to the beacon chain.
This is a simple but important insight-the Eth1 execution layer client has been constructed in a way that the consensus algorithm can be exchanged. The main network uses proof of work, while the test network and private Ethereum network use proof of authority consensus algorithms (clique, IBFT, etc.).
In the article, Mikhail proposed to directly use the proof of stake as a new consensus algorithm used by the client. In other words, it is to merge the current proof-of-work chain with the beacon chain. The following picture made by Trent Van Epps illustrates this change well:
Source: https://twitter.com/trent_vanepps/status/1415741658067517441/photo/1
This method will minimize the work to be done by the client team on the PoW chain, while still bringing all the benefits of “premature merger” and “Rollup-centric route” [1].
Rayonism project☀️
In order to verify the feasibility of the executable beacon chain architecture, the client was prototyped in a month-long hackathon called Rayonism.
Within a few weeks, various hybrid combinations of Eth1 and Eth2 clients will run transactions on the EVM as merged clients, reaching a consensus through the beacon chain.
Highly speaking, the current Eth2 node becomes the consensus layer of the network, and the current Eth1 node serves as its execution layer. The function of the consensus layer is extended to send the latest chain header information to the execution layer and request blocks from the execution layer. The execution layer is still responsible for processing blocks, broadcasting transactions, storing and managing state, and processing JSON RPC requests.
This experiment verified that the architecture of the executable beacon chain is reasonable and can be used as the basis for the transition to proof of stake. Now this process is called merger.
PoW -> PoS transition⛏
What is not tested in the Rayonsim project is the transition from a real PoW network to a running Pos network. After several iterations, a specification has now been roughly finalized.
In order to achieve the transition from proof of work to proof of equity, a TERMINAL TOTAL DIFFICULTY (total difficulty of ending) needs to be set in the client. When the difficulty of the block is found to exceed the difficulty of the proof-of-work chain, the client will enter the transition mode, and they will start to monitor the information of the proof-of-stake layer to reach a consensus. Once the difficulty of a block finally finalized by the consensus layer exceeds T ERMINAL TOTAL DIFFICULTY , the execution layer will completely stop monitoring and broadcasting PoW block information. In this way, the merger is complete 🎉!
For applications, this will not have any impact on contracts and users. There are some opcodes that need to be updated, but that’s all. For the operator of the beacon chain node, an execution engine needs to be selected in the merger. Similarly, if you run a node on a proof-of-work network, you need to choose a consensus client in the merger. As the merger progresses, you can expect multiple developer testnets, tutorials, and conferences to discuss these issues.
Next work🛠
Although the overall plan for the merger has been determined, the client team has a long list of things that need to be completed in the next few months. Most of the things to be done can be tracked here . The ones that are worth paying attention to include determining the merged synchronization protocol, setting up integration tests for the entire process, going online to the developer testnet and running them under adverse conditions, and for the transition period Plan for various unexpected situations.
If you want to learn more about the actual specification, EIP-3675 details the changes required by the execution layer client, while the merge folder in the consensus specification details the changes in the consensus layer.
When things stabilize a bit, please look forward to another article on how the Ethereum client will work after the merger. Thank you for reading and see you next time 👋🏻!
Thanks to Danny Ryan, Trent Van Epps, and Mikhail Kalinin for their feedback on the draft of this article.
[1] One notable change is that “Stateless Ethereum” is no longer a prerequisite for the transition to Proof of Stake.
[2] During the transition phase, reorganization can be better handled based on the total difficulty rather than the block or slot number. For more information, please refer to the “Transition process” section in EIP-3675.
Source link: hackmd.io
