Partnered With:

Ethereum Core Developer Conference Update: An in-depth look at the evolution of the current architecture choice roadmap

Read this article in 17 Minutes

Review the evolution of Eth1<->Eth2 merge and describe how the merge will work.

Ethereum Core Developer Conference Update 006

By Tim Beiko

ETH Chinese station

This update is a bit different from previous ones. First, I decided to move to Mirror to publish updates. Using the platform for the 1559 NFT project was a great experience, and I'm always looking to use it again. I keep a list of updates in HackMD so they can be easily found in one place.

Second, since our current focus is on The Merge, this article is not really an "update" but rather an in-depth discussion of The evolution of The roadmap to The current architectural options. In a few weeks, there will be a similar article detailing how the Ethereum network will work after the merger.

Merged prehistory

The merger will transform Ethereum's current proof-of-work (PoW) consensus algorithm into a proof-of-stake (PoS) mechanism that runs on beacon chains. The design is the result of several iterations of the "Ethereum 2.0" roadmap. Let's review how the roadmap has changed over the years.

Stage 0️, 1️ discount, 2️

For several years, proof-of-equity and sharding were developed independently of each other. At a seminar in Taipei in 2018, it was decided to unify the two research initiatives into a three-stage roadmap for "Ethereum 2.0". Ben Edginton in this article gives a very good summary of the workshop and the general philosophy of the time. It was at this event that Hsiao-Wei presented this now-famous "Ethereum 2.0" schematic:

以太坊核心开发者会议：深入探讨以太坊合并及其路线演变

source

This chart shows what each phase of the new roadmap would deliver at the time:

· Stage 0 will bring the beacon chain

· In phase 1, data shards are added

· In phase 2, virtual machines are added in each shard to realize computing in the system.

The number of shards was originally set at 100, then increased to 1024, and recently reduced to 64.

Merge early

As work on the beacon chain began in 2018, it became clear that this three-phase Ethereum 2.0 roadmap would take several years to fully deliver. Along with the growing pains of rapid growth in the number of people using Ethereum, this has brought about a resurgence of proof-of-work blockchain research initiatives. At Devcon IV 2018, the term "Ethereum 1.x" was proposed to cover these research initiatives. The biggest of these is Stateless Ethereum, a paradigm that removes unaccessed state from the network to limit the rate at which it can swell.

A proposal for an "early merger" emerged from an increasing focus on making PoW chains sustainable in the long term and developers' realization that beacon chains could be implemented earlier than other parts of the Ethereum 2.0 roadmap. The proposal starts the existing EVM chain as "shard 0" for the Ethereum 2.0 system. This will not only speed up the transition to the proof of equity, but also make the transition at the application layer smoother, since moving to the proof of equity does not require migration at the application layer.

Shortly after this proposal came out, Danny Ryan explored how we could leverage existing Eth1 clients to achieve early consolidation in his Eth1+Eth2 Cpent Relationship article. This will greatly reduce the development effort of delivering a combined system and leveraging the client, since the Eth1 client is already well established on the main network. Going down this path would 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 area of research).

Rollup centered roadmap

Fast forward to the end of 2020: Phase 0 At this point, 99% of the progress has been made and the beacon chain will soon be activated. Although work in Phase 1 went well, there are still a number of unresolved issues in Phase 2, which will implement computation on the shards introduced in Phase 1:

· How to smooth transition from current EVM chain to sharded VIRTUAL machine?

· What alternative virtual functions are deployed in terms of performance?

· How can we ensure that all kinds of virtual machines are really safe?

· How to coordinate the state and balance of all virtual machines?

At the same time, rollup (for example, the second floor expansion scheme) is making very rapid progress. Multiple teams have announced plans to go on the beta network, with encouraging early results.

Around this time, Vitapk posted a long post on Ethereum Magicians forums, arguing that we should focus on rollup in the short and medium term. Not only will they be on the main network before Phase 2 is complete, but they will be the biggest beneficiaries of Phase 1. Rollup generates a lot of data, and sharding can provide it with less storage than EVM chains. Here's a screenshot of the article:

以太坊核心开发者会议：深入探讨以太坊合并及其路线演变

This approach has several implications for the Phase 0-2 roadmap. Details are as follows:

· Phase 0 (Beacon chain) was running on the test network prior to the deployment of the main network. Once the PoW chain was ready, the beacon chain could become the consensus layer engine instead of waiting until after Phase 2;

· Phase 1 (data sharding) is still a few years away and goes from being a critical barrier to capacity expansion to an incremental improvement that reduces the overhead of already developed capacity expansion solutions (such as rollup);

· Phase 2 (Sharding execution) is a more complex feature with the most open research questions, which can be rolled out in a few years or eliminated completely with no impact on the expansion roadmap.

The research community quickly gathered around the proposal and within a month published an ethresear.ch article detailing the current merger plan!

The current & amp; Road map for the future

Executable beacon chain ⛓

The current merger architecture is detailed in the Executable Beacon Chain, first published by Mikhail Kapnin in November 2020. In short, it combines the insights of multiple iterations of the Ethereum 2.0 roadmap:

· Beacon chain has been started and can now be used as a consensus engine;

·Rollup is the best short-term solution for scale-up computing;

· The current Eth1 client is the best base for the combined implementation layer;

· Moving to proof of equity can be done in a way that has minimal impact on the currently running application

One of the major changes Mikhail proposed was that instead of making the current EVM chain "shard zero," it would be connected directly to the beacon chain.

This is a simple but important insight -- the Eth1 executive-layer client is already built in a consensus-algorithm-interchangeable way. The main network uses proof of work, while test networks and private Ethereum networks use proof of Authority consensus algorithms (CPQUE, IBFT, etc.).

In the article, Mikhail proposes a new consensus algorithm that directly uses proof of equity as a client. In other words, merge the current proof-of-work chain with the beacon chain. The following chart, made by Trent Van Epps, nicely illustrates the change:

以太坊核心开发者会议：深入探讨以太坊合并及其路线演变

source

This approach will minimize the work of the client team on the PoW chain, while still bringing all the benefits of "early merging" and "rollup-centric route" [1].

Rayonism project ☀ ️

To verify the feasibility of the executable beacon chain architecture, the client was prototype in a month-long hackathon called Rayonism.

Within a few weeks, various hybrid combinations of Eth1 and Eth2 clients run transactions on EVM as combined clients, reaching consensus through the beacon chain.

At a high level, the Eth2 node now acts as the consensus layer of the network, and the Eth1 node acts as its enforcement layer. The function of the consensus layer is extended to send the latest header information to the executive layer and request blocks from the executive layer. The executive 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 was sound and could be used as a basis for the transition to proof of interest, a process now known as consolidation.

PoW -> PoS transition ⛏

What Rayonsim did not test was the transition from a real PoW network to a working Pos network. After several iterations, we now have a rough specification.

To make the transition from proof of work to proof of equity, one needs to be set up on the client side

TERMINAL TOTAL DIFFICpTY

(End total difficulty). When it is found that the difficulty in the block exceeds the difficulty in the proof-of-work chain, the clients go into transition mode and they start listening for information in the proof-of-claim layer to reach consensus. Once the consensus layer is finalized, the difficulty of a block exceeds T

ERMINAL TOTAL DIFFICpTY

, the executive layer will completely stop listening and broadcasting PoW block information. So, the merge is complete!

For the application, this has no impact on the contract or the user. There are some opcodes that need updating, but that's about it. For runners of beacon chain nodes, an execution engine needs to be selected in the merge. Similarly, if you are running a node on a proof-of-work network, you need to select a consensus client in merge. As the merger proceeds, you can expect multiple developer test networks, tutorials, and conferences to discuss these issues.

Next work

While the overall plan for the merger is in place, the client team has a long list of things that need to be done in the coming months. Most of the things I need to do can be done herehereThe tracking points of interest include determining post-merge synchronization protocols, creating integration tests for the entire process setup, launching developer testing networks and running them under adverse conditions, and planning for various contingencies during the transition.

If you want to dive into the actual specification,EIP-3675The merge Folder in the consensus specification details the changes required by the execution-level client.

When things settle down a bit, look for another in-depth article on how ethereum clients will work after the merger. Thanks for reading, see you next time!

Thanks to Danny Ryan, Trent Van Epps and Mikhail Kapnin for their feedback on the draft of this article.

[1] One notable change is that "stateless Ethereum" is no longer a prerequisite for transitioning to proof of interest.

[2] It is better to handle regrouping in the transitional phase based on total difficulty rather than block or slot numbers. For more information, see the Transition Process in IP-3675.