In the cross-chain system, the cross-chain gateway is an important part of docking specific types of blockchains and forwarding cross-chain messages. It mainly provides core functions such as application chain adaptation, cross-chain transaction monitoring, cross-chain transaction execution, and cross-chain transaction routing. This article mainly introduces the design concept of cross-chain gateway from the aspects of cross-chain gateway architecture, cross-chain transaction process, and decoupling method of application chain and cross-chain gateway.

One, the overall structure

The cross-chain gateway can flexibly support two cross-chain modes. One is the relay mode, that is, cross-chain operations are performed through the relay chain, which is more suitable for scenarios where more blockchains perform cross-chain interoperability. The other is the direct connection mode, which can directly connect to other cross-chain gateways to transfer cross-chain transactions, which is more suitable for small chain-to-chain cross-chain systems. In order to support the switching between different cross-chain modes, the cross-chain gateway adopts the following hierarchical design.

The first layer is the application chain layer: this layer is responsible for the interaction logic with the application chain and its smart contracts, and provides a unified interaction interface for the interaction of the upper layer. Since the architecture of the blockchain varies from chain to chain, in order to decouple application chain adaptation and cross-chain gateways and achieve the effect of convenient access, we adopt a plug-in mechanism.

The second layer is the interaction layer: this layer contains specific logic such as how to submit IBTP packages and how to monitor cross-chain transactions on the application chain. The interaction layer is at the bottom of the cross-chain gateway, including execution modules and monitoring modules. The interaction layer shields the details of cross-chain transactions obtained and submitted from the application chain to the upper module, and provides a more streamlined interaction interface.

The third layer is the relay layer: this layer serves as the transfer scheduling layer for message flow in the cross-chain gateway. Cross-chain messages from the application chain and cross-chain messages received from other blockchains are processed and routed in a unified manner. The relay layer is mainly able to shield the complexity of different cross-chain modes, and uniformly call the underlying modules.

Two. Cross-chain transaction processing flow

In a typical cross-chain transaction process, a user on application chain A initiates a cross-chain transaction sent to application chain B, and the receipt is returned to application chain A after the execution on application chain B is completed.

Monitor transaction

The cross-chain transaction is initiated by the user and calls the cross-chain contract deployed on the application chain A. The cross-chain contract throws a cross-chain event in a specific format after receiving a request for a cross-chain transaction. The corresponding application chain plug-in polls or subscribes to the cross-chain event, and collects the Proof information of the cross-chain event on the application chain A, and sends it to the cross-chain gateway monitor along with the IBTP package On the module.

The monitoring module performs basic checking operations for cross-chain transactions (such as checking the serial number of cross-chain transactions), and only cross-chain transactions that pass the check can be submitted to the distribution module.

Distribution transaction

After receiving the cross-chain transaction submitted by the monitoring module, since the cross-chain gateway supports different cross-chain modes, the distribution module needs to coordinate the specific delivery objects of the cross-chain transaction.

In the relay mode, the distribution module sends cross-chain transactions through direct and relay chain proxy modules. In the direct connection mode, you can connect to the cross-chain gateway of other application chains through the P2P network and send the corresponding cross-chain transactions.

Synchronous transaction

In different cross-chain modes, the ways of synchronized transactions are also different.

In the relay chain mode, cross-chain transactions participate in consensus and are packaged into blocks. Therefore, when synchronizing transactions, the light node module of the relay chain needs to continuously update the block header information. The synchronization module synchronizes all cross-chain transactions related to its own cross-chain gateway in the relay chain block. For transactions synchronized by the relay chain, it is also necessary to cooperate with light nodes to perform SPV verification on cross-chain transactions to ensure the validity of cross-chain transactions.

In the direct connection mode, the cross-chain gateway receives cross-chain transactions through the P2P network.

Check transaction

For cross-chain transactions that are synchronized from other chains, they need to pass the inspection of the inspection module before they can be handed over to the distribution module for further processing. The logic of the check is related to the cross-chain mode.

In the relay mode, the cross-chain transaction has passed the verification engine of the relay chain and has participated in the consensus of the relay chain, so the check module only needs to verify that the cross-chain transaction does come from the relay chain. On the relay chain, for cross-chain transactions that pass consensus, the relay chain node will sign it. The check module verifies the attached signature to verify the validity of the cross-chain transaction.

In the direct connection mode, cross-chain transactions are cross-chain transactions obtained through the P2P network, so compared to the relay mode, the inspection module needs to undertake more verification work. The main things that need to be checked are the registration check of the application chain and the verification check of the verification engine. If the application chain needs to customize the verification rules for cross-chain transactions, it can be more dynamic by updating the verification rules.

Execute transaction

Cross-chain transactions from the relay chain or other cross-chain gateways can be submitted to the execution module after passing the inspection of the inspection module. The execution module is directly connected to the application chain plug-in. Before calling the cross-chain contract, the serial number needs to be checked to prevent replay attacks.

After submitting the transaction, the execution module needs to wait for the execution result on the application chain, and return the result to the distribution module through a cross-chain receipt. The transfer process of the cross-chain receipt is similar to that of a cross-chain transaction. The execution module must ensure that the cross-chain transaction is submitted to the application chain and needs to return the corresponding receipt information.

Three, plug-in mechanism

For cross-chain scenarios, a more difficult problem is the access adaptation of blockchains of different architectures. In order to simplify the adaptation of different blockchains, we adopted a plug-in mechanism in the cross-chain gateway. The cross-chain gateway is mainly responsible for the interaction and communication with the relay chain or other cross-chain gateways. And all the parts that are specifically operated on the application chain are all encapsulated in the application chain plug-in, and a set of plug-in interfaces suitable for cross-chain interaction are determined according to the needs of cross-chain gateway and application chain interaction.

In this way, for the cross-chain gateway, when docking any new type of application chain, it does not need to modify itself, but a new application chain plug-in can be developed according to the determined interface.

The interface that the plug-in needs to provide is mainly divided into the following four main parts:

1. Submit transaction interface

The interface for the cross-chain gateway to submit IBTP packages. The basis of the interaction between the cross-chain gateway and the application chain plug-in is IBTP: the IBTP package submitted by the cross-chain gateway to the plug-in, and the received receipt information is also the IBTP package. In this way, the plug-in shields the complexity of the inconsistent transaction structure of different blockchains from the cross-chain gateway, and simplifies the design of the cross-chain gateway.

The application chain plug-in is responsible for parsing the IBTP package and transforming it into a structure adapted to the application chain to submit transactions. At the same time, it is necessary to encapsulate the execution results obtained, and obtain Proof information for cross-chain transactions from the application chain.

2. Query cross-chain transaction meta information interface

At the IBTP protocol level, the smallest granularity that the protocol can perceive is the application chain. The protocol can only forward cross-chain transactions to the cross-chain gateway corresponding to the destination chain ID in the IBTP packet. For more fine-grained on-chain contracts and user account addresses, the application layer parses and defines the business structure in the IBTP payload field.

Therefore, the cross-chain contract needs to record the latest transaction sequence number information of its own application chain and other chains (that is, the meta-information of cross-chain transactions), and update these meta-information when executing cross-chain transactions. Because this meta-information is essential for the restart and recovery of the cross-chain gateway, the plug-in needs to provide an interface that can query this meta-information.

3. Query historical transaction information

For cross-chain events thrown by the application chain, some cross-chain events may not be received in time due to uncontrollable reasons such as network jitter or cross-chain gateway downtime. In this case, the plug-in needs to provide an interface for querying missing cross-chain events for the cross-chain gateway to restore the order in which the cross-chain gateway processes cross-chain events.

4. Query basic information of the application chain

The cross-chain gateway is unaware of the use of application chain plugins, so if the cross-chain gateway needs to obtain the basic information of the application chain (such as application chain type, consensus algorithm type, application chain name, etc.), it needs to query the application chain plugin.

The plugins that meet the above four requirements can meet the needs of cross-chain gateways to collect and forward cross-chain transactions, and at the same time fully decouple the cross-chain gateway’s dependence on the underlying application chain, making it more convenient and simple to adapt to new types of blockchains .