Explore ETH 2.0: How is cross-chip communication handled?

Source: Adiasg.me

Translation: First Class (First.VIP)

Editor's Note: The original title was "Exploring Cross-Chip Communication for ETH 2.0"

As the phase of Eth2.0 deepens, the focus of research is shifting to phase 2: state execution. The most important aspect at this stage is the processing of cross-chip communication, which affects the scalability of the sharded blockchain system, the execution environment capacity and the user experience. This article aims to help readers understand the design of cross-chip communication and explore the available methods.

• Introduction to Blockchain | How does the alliance chain work, and what are the advantages and disadvantages?
• Ripple completes $ 200 million Series C financing, valuation reaches $ 10 billion
• French financial market regulator approves first ICO application after updating rules

The design of cross-chip communication can be divided into two layers:

1. Consensus layer: Used to handle cross-slice messaging. This design will affect the scalability of the sharded blockchain system.

2. Consensus layer: Includes interfaces for cross-chip transmission and contract invocation. This design choice affects the capacity of the execution environment.

Consensus layer

The consensus layer of cross-chip communication is responsible for transmitting cross-chip messages in each partition of the blockchain system. The main challenge is to provide strong guarantees for the validity of cross-slice messages while maintaining scalability. This layer can be divided into two parts:

• Send / Receive finality
• Data delivery

Send / receive final certainty

The source shard and destination shard must complete the sending and receiving of cross-slice messages, respectively. The designs that can be used to achieve this are:

• Asynchronous : The source shard sends a message, and the target shard can receive this message at any time in the future.
• Synchronous : The target shard accepts messages within a limited time after the source shard is determined to be sent. There are several ways to achieve this: · Run some kind of consensus protocol between the shards and decide to send and receive at the same time, for example: Sharded Byzantine Atomic Commit . · The source shard is sent first, and the corresponding target shard must be received within a period of time, for example: CBC Casper cross-shard messaging . This method requires a hierarchical structure between the source and target shards; otherwise, deadlock may result due to sending and receiving conflicts. Place cross-slice messages on the beacon chain and force the target shards to receive them before the next cross. (Note: This may limit scalability.)

Synchronization is not compatible with the design of Eth2.0 because it requires the shards to somehow coordinate the sending and receiving of final determinism.

data transmission

Previous mechanisms involved the final certainty of sending and receiving, which is different from actually sending or receiving a message. This is the task of the data transfer mechanism. (The differences between the two will be highlighted in the "User Delivery" approach in this section)

The design of ETH 2.0 requires that all consensus activities occur only in the beacon chain. This means that all cross-slice messages must "flow" through the beacon chain. This gives us two options for data transfer across slices:

• Protocol-delivered : The protocol delivers complete data for cross-slice messages by making cross-slice messages available on the beacon chain. This increases the overhead of the beacon chain and seriously affects the scalability of the system.
• User-delivered : This protocol only reaches a consensus on the minimum information of the cross-slice message (the Merkle root of the cross-slice message from each shard). The user is then responsible for passing the Merkle branch associated with the cross-slice message to the target shard. This method is more suitable for Eth2.0, because it follows the general principle of forming consensus only on the merkle root on the beacon chain.

Proposed design of the consensus layer

In order to prioritize system scalability, a solution that asynchronously sends / receives final determinism and user-delivered data is more feasible . User 1 on shard A sends Ether to user 2 on shard B as follows:

1. User 1 creates transaction TX1 on shard A, marks the balance from EE1, and declares that the target is user 2.

2. When the crosslink from shard A is included in the beacon chain, the merkle root that collects all cross-slice transactions since the last crosslink appears on the beacon chain. This is evidence that TX1 is included in shard A.

3. Shard B finds this merkle root on the beacon chain. User 2 creates transaction TX2, showing that shard B contains the merkle certificate of TX1. This allows the appropriate amount to be marked to User 2's balance on EE2.

Executive layer

The execution layer of cross-chip communication provides interfaces for users and contracts for cross-chip transmission and contract invocation. The design space on this floor has not been well explored. Recent discussions on this layer include:

• Cross-slice calls in the execution environment
• Reliable value transfer between shards

Cross-slice call

The basic question is: what happens when the function of another shard is called on a different shard? For a sharded blockchain, design is not unique. It is the same as a system that executes applications separately in multiple partitions, such as:

• Single-threaded and multi-threaded systems
• Single computer and network application system

Inspired by the above system, a simple design can be the following types of calls:

• Asynchronous call, no return
• Asynchronous call with callback specified
• Synchronous call

Alternative methods include various advanced concurrent programming paradigms, such as protolambda's commit capabilities post .

Reprinted please retain copyright information.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!