Explain in detail how Ethereum 2.0 merges with 1.0

Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc)Editor's Note: This article comes from

Babbitt Information (ID: bitcoin8btc)

Note: The original author is Danny Ryan (djrtwo), the coordinator of Ethereum 2.0. In this article, he introduced in detail how Ethereum 1.0 will merge with Ethereum 2.0. According to his introduction, in the eth1+eth2 combination client , the eth2 client can handle the complexity of PoS and shard consensus, and the attached eth1 client can become an eth1 engine, which can handle the complexity of things like state, transactions, virtual machines, etc.

image description

(picture from: tuchong.com)<-> eth2 secondary titleRelationship between Ethereum 1.0 and Ethereum 2.0 clients

Since Vitalik proposed an early eth1 in December 2019

Since then, there have been active discussions among researchers to consider possible forms of this merger from a software perspective, and expectations for prototyping have only grown stronger. Our vision is to create a hybrid where the core consensus work is managed by an Ethereum 2.0 client (hereinafter referred to as eth2 client), while the state/block is managed by an Ethereum 1.0 engine (hereinafter referred to as eth1 engine), and Together they form the eth1+eth2 combined client.

This article aims to more clearly separate the responsibilities between the eth2 client and the attached eth1 engine in order to provide a better basis for conversation, specification writing, and prototyping. Note that this article does not define the specifics of the protocol (such as the precise method by which an eth1 client invokes the eth2 engine), and any examples included in this article are intended only to aid in the description and subsequent discussion.

To understand the content of this article, the prerequisite is that you are basically familiar with the concepts of Ethereum 2.0 and stateless Ethereum.

secondary title

Clear division of labor

In a nutshell, what we think of as an eth2 client today would handle core PoS as well as shard consensus. Essentially, the eth2 protocol and eth2 client are designed to be very good at generating and reaching consensus on a bunch of "stuff", which are many shard chains full of data and (final) state. Compared with the current PoW consensus layer of eth1, the "consensus layer" of eth2 is much more advanced and complex.

Today, the eth1 client has a relatively simple and thin consensus layer, it has only one chain, and PoW handles most of the complexity in the off-protocol hardware. Most of the complexity and optimization of the eth1 client resides at the user layer (including state storage/management, state synchronization, virtual machine execution, transaction processing, transaction pooling, etc.).

This separation of concerns makes for a nice pairing when eth1 is incorporated into eth2 as a shard, the eth2 client can handle the complexities of PoS and shard consensus, and the subsidiary eth1 client can become the eth1 engine, which can The complexity of handling state, transactions, virtual machines, and things closer to userland.

secondary title

Minimal changes to achieve local communication

How to combine eth1 and eth2 client software, there are many possible ways (such as complete merger, importing eth1 as a library, through the communication protocol between the two, etc.), but in this article, we will focus on one of the most A minimally invasive and modular approach - a native communication protocol between eth2 clients and simplified eth1 engines.

Given the diversity of eth1 and eth2 client implementations, this approach prevents client software from being locked in on either side, allowing client teams to remain independent and focus on their own R&D efforts, keeping the software project largely Stable for rapid prototyping.

So what would it look like?

Roughly, an eth1+eth2 combined client will look like this:

• Among them, the eth2 engine and the eth1 engine run together, and communicate locally through the RPC driven by the eth2 client.

• Both will maintain their own p2p interface, connect to peers and handle network protocols related to each specific domain.

• Ethereum 2.0 client

• Beacon Chain and Beacon State (the core consensus objects that build the rest of the system);

• Shard chains (1, eth1 shard chains, 2, many data-only shard chains);

Mempool operations [not shown] (Attestation, deposit, exit, etc.)

• P2P interface (1, consensus layer information, 2, including eth1 shard block gossip);

• RPC to the eth1 engine (all calls are driven by the eth2 client);

• Ethereum 1.0 Engine

• EVM virtual machine (execution and verification of eth1 shard blocks);

• P2P interface (1. transaction gossip on Ethereum today, 2. state synchronization, 3. no eth1 shard block gossip);

consensus

RPCs from eth2 clients (all calls are driven by eth2 clients);

secondary title

consensus

Since the eth1 engine completely relies on the eth2 client to promote consensus, we propose that the communication between the eth2 client and the eth1 engine is all methods on the eth1 engine called by the eth2 client (such as addBlock, getBlockProposal, etc.). This will enforce a leader/follower relationship to reduce the complexity of system reasoning and limit the business logic required by the eth1 engine.

state

From an eth2 client and core consensus point of view, the eth1 shard chain is handled almost identically to all other shard chains (fork selection, crosslinks, block structure, signatures, etc.). The main difference is that shard block content can be executed against the eth1 engine, so the format of the eth1 shard block data must be relative to eth1, and additional verification must be done for this successful execution.

secondary title

state

eth2 has a state related to the core consensus, which is the so-called "beacon-state". The beacon state data is small (only about 10-40MB, depending on the size of the validator set), and it contains all the information needed to understand the core consensus and how to deal with the shard chain. In fact, to handle the consensus-related parts of a shard chain, a client must have access to the beacon state (e.g., the latest crosslink running the shard chain fork election, the current validation set or shuffling Randomly assigned).

The state of eth2 will not always interact with the state of the user layer, and the most important interaction is the availability of shard chain data. The actual user layer data root is located in the shard chain data, and for the eth1 shard chain, it is the current Ethereum user state root.

The different cases of eth1 status in relation to eth2 clients are discussed below:

3. For an eth2 client with a stateful eth1 engine to run a validator that can generate eth1 shard blocks, it must use an additional eth1 engine and complete eth1 state to run the eth2 protocol (developers are exploring stateless block generation methods , but we do not discuss it for simplicity). New valid blocks can then be formed on demand using the local state and transaction memory pool (TX mempool) (more on this below).

network

In addition to validators, many user/application nodes may also run with a fully stateful eth1 engine, such as block explorers, archive nodes, state providers, etc.

network

ENR

For simplicity, eth2 and eth1 will initially maintain their own separate network stacks and protocols. In response to shifting responsibilities (e.g. eth1 shard block gossip), developers have deprecated some of the existing eth1 protocols (e.g. eth1 shard block gossip) and replaced them with the eth2 protocol. After the initial prototyping phase, or at a further stage, it may be necessary to migrate the eth1 protocol to libp2p to unify the network stack, but this is not required.

eth2 clients and eth1 engines have access to the same discv5 DHT, but independently find appropriately capable peers and maintain connections independently.

secondary title

eth1 functionality (state, transactions, etc.) is represented by an existing eth (or new eth1) key in the ENR.

The eth2 function (core consensus) is represented by the eth2 key in the ENR.

The existence of each protocol means that nodes are able and willing to identify the type of underlying network protocol.

secondary title

Wire protocol

1. eth2 protocol 1. eth2 request/response (1. Status, 2. Beacon block synchronization, 3. Shard block synchronization); 2. Core consensus gossip (1. Beacon block, 2. Proof, 3. block, including eth1 sharding, 4, other validator operations); 2, eth1 protocol 1, subset of eth1 wire protocol (1, transaction gossip, 2, synchronization method, such as getnodedata or new method, 3, get receipt receipt )

3. Why does the eth2 client process eth1 block gossip? eth2 is specially used to handle the production, gossip and verification of shard blocks. Our goal is for the eth1 shard to be standard and as consistent as possible with the rest of the shards. Regarding the core consensus, the main difference of eth1 blocks compared to other shards is the ability to execute/verify block content against the eth1 engine,

When the validator is forking the eth1 shard block to the beacon chain, the eth2 client will call the eth1 engine again to execute and validate the block.

When a stateful eth1+eth2 combined node receives a new eth1 shard block, the eth2 client will call the eth1 engine again to validate the block and update the local state store.

secondary title

Transaction gossip and storage pool mempool

The eth1 shard blocks are fed to the eth1 engine from the attached eth2 client. Transactions included in these blocks should be purged from the storage pool in a manner similar to current Ethereum mainnet PoW blocks.

block production

The eth1 shard blocks are generated from the content of the storage pool mempool according to the attached eth2 client. This RPC method and underlying functionality is similar to getWork, but will return the full block content, not just a hash.

secondary title

block production

For beacon blocks and non-eth1 shard blocks, the eth2 client has everything it needs to generate valid blocks.

For eth1 shard blocks, eth2 clients have immediate/anytime access to eth1 state, transactions, and other underlying eth1 structures to generate valid blocks. Conversely, when a designated validator produces an eth1 block, the eth2 client requests a feasible eth1 block data (TX, state root, etc.) from the eth1 engine. Then, the eth2 client packs this eth1 block data into a complete shard block (adding slot, positer_index, positer_signature, etc.), and broadcasts the block to the network.

The eth1 engine is able to generate valid/feasible eth1 block data because it manages the eth1 transaction storage pool in the same way that the Ethereum mainnet uses today, and it maintains the latest eth1 head state through updates from the eth2 client information.

• secondary title

• What's the next step?

• If this general design is agreed upon, the next steps include:

• Ensure that assumptions about eth2 clients driving the eth1 engine are consistent with existing eth1 software and do not impose unintended burdens on existing eth1 software;

• More clearly define the communication protocol used to drive the eth1 engine, such as new_head(block), validate_block_transition(block), get_proposal(parent_root), etc.;

Define network components, such as which subset of the eth1 protocol is required, and how to specifically use ENR;