CN107742210A - A cross-chain transfer system and method between different blockchains - Google Patents

Abstract

The present invention discloses a cross-chain transfer system and method between different blockchains. The method includes: receiving a first transaction request, wherein the first transaction request requests to transfer the first-generation currency transfer to the second parachain; look up at least one order that matches the first transaction request in the order table, generate an order combination according to the at least one order and freeze the orders in the order combination; generate Combining the second transaction request, issuing the second transaction request to the first parachain through the interconnection chain; receiving the third transaction request, wherein the third transaction request is based on the second transaction request in the Generated by the execution result in the first parachain; when the third transaction request passes the verification, confirm the completion of the first transaction request and the order in the order combination, and record all transaction records. The present invention has good scalability and can guarantee atomicity in the transfer process.

Description

A cross-chain transfer system and method between different blockchains

technical field

The invention relates to the technical field of block chains, in particular to a cross-chain transfer system and method between different block chains.

Background technique

With the rapid development of blockchain technology and applications, various independent blockchains have emerged, and the realization of cross-blockchain transactions has become an urgent need for today's blockchain applications. For example, the most common demand at present is cross-blockchain currency transactions, that is, the transfer of virtual currency from one blockchain to another, so as to realize the value circulation between various blockchains.

In response to the needs of cross-chain transfers, industry and academia have proposed some preliminary solutions.

BTCRelay and BTC-Market realize one-to-one cross-chain transfer. In this scheme, the smart contract deployed on Ethereum can receive Bitcoin's block header and SPV (Simplified Payment Verification) verification information, thereby being able to verify transactions that occur on Bitcoin. However, when transfers between multiple chains are involved, such one-to-one schemes cause serious scalability issues. This is because a smart contract deployed on one of the blockchains needs to be able to verify the transactions of all other blockchains, which is obviously difficult to do. In addition, each node running a smart contract needs to store the block headers of all other blockchains, which imposes a storage burden on the node.

Interledger is a cross-chain transfer system and method proposed by Ripple. In this scheme, the sender of funds needs to find a group of suitable connectors to form a path to the receiver. Funds will be transferred from the sender to the receiver through the connectors in a relay manner. After the receiving party issues a valid proof of acceptance, both the connecter and the receiving party can get their own funds. The disadvantage of this scheme is that the sender must find a suitable set of connectors before transferring funds. Once there is no such connector, the transfer will not be possible. In addition, during the transfer process, the recipient must be online throughout the entire process, so that the proof of receipt can be issued in a timely manner. Once the proof of receipt is not issued within the stipulated time, the transfer transaction will be cancelled.

Cosmos is a newly proposed cross-chain transfer system and method. In Cosmos, one blockchain called "Hub" manages many other blockchains called "Zones". Both Hub and Zone use a consensus mechanism called "Tendermint". The block header of each Zone is submitted to the Hub, so the Hub can maintain the real-time status of each Zone. When an account in the source Zone transfers money to an account in the destination Zone, the transaction and related verification information from the source Zone will be packaged and sent to the Hub. Subsequently, the Hub sends the data packet to the destination Zone. However, in Cosmos, both Hub and Zone need to use the Tendermint consensus. If a certain blockchain does not adopt the Tendermint consensus, it must use a bridging Zone to successfully access Cosmos. This undoubtedly limits the scalability of the system. In addition, the proposal does not propose the transfer process in detail, nor does it explain how to ensure atomicity in the transfer process.

In addition, the Ethereum Foundation proposed Polkadot to improve the scalability of the blockchain system. In this system, tasks such as transactions are distributed among multiple blockchains. Multiple blockchains can run in parallel, thus, this system increases the processing speed of transactions. However, the proposal is only a preliminary draft and does not provide detailed details of cross-blockchain transactions.

Contents of the invention

In order to solve the above problems, the object of the present invention is achieved through the following technical solutions. In the present invention, the blockchain connected to the interconnected chain is called a parallel chain.

Specifically, according to one aspect of the present invention, the present invention provides a cross-chain transfer system between different blockchains, the system includes at least one interconnected chain and multiple parallel chains, each of which is connected to Interchain. Each parallel chain contains one or more data transceiver nodes and several network nodes, and the data transceiver nodes are connected to one or more of the network nodes; the interconnection chain contains multiple verification nodes, so The verification nodes are respectively connected to one or more of the above-mentioned data sending and receiving nodes; wherein, the parachain also includes an exchange module, and the exchange module is determined according to the two-way currency conversion quantity between the source parachain and the destination parachain Whether the transfer was successful.

The interconnected chain is used for transaction forwarding between multiple blockchains. Any blockchain can be connected to the Internet chain, and cross-chain transactions can be completed through the Internet chain. Every node on a parachain maintains a complete copy of that parachain.

Each parachain network contains one or more data sending and receiving nodes. Each data sending and receiving node keeps a complete copy of its own parachain; at the same time, each data sending and receiving node holds an account in the parallel chain, so that it can receive and issue transaction data in the parallel chain.

Each data sending and receiving node also holds an account on the interconnected chain, so that it can receive and issue transaction data on the interconnected chain; in addition, the data sending and receiving node can learn the real-time status of the interconnected chain, including the transaction data written into the interconnected chain.

The interchain network contains multiple verification nodes. On the one hand, the verification nodes synchronize the block headers of each parachain, and then verify the transaction requests from each parachain; on the other hand, they maintain a complete copy of the interchain and participate in the interchain consensus process.

When a parachain is connected to the Internet chain, the data sending and receiving node of the parachain will send a transaction request to the Internet chain network, and the transaction request includes the SPV verification method for the transaction of the parachain. Therefore, the verification nodes in the interconnected chain can verify the validity of the transaction request from the parachain.

Each parachain contains: sending module, verification module, and exchange module. These include:

When a user initiates a cross-chain transaction request, a transaction needs to be constructed first, and the funds to be transferred are temporarily stored in the sending module.

The exchange module can exchange tokens issued by its own blockchain for tokens issued by another blockchain.

The verification module synchronizes the block header of the interconnected chain in real time, so it can verify the validity of the transaction information in the interconnected chain; both the sending module and the exchange module can call the verification module.

The user temporarily deposits the funds to be transferred to the sending module, including:

The sending module sets a timer for each temporarily deposited fund, and the temporarily deposited funds cannot be withdrawn before the timer expires.

The token exchange function of the exchange module also includes:

1. Users who need to exchange tokens hold accounts on the parachain to which the exchange module belongs and the target parachain;

2. The user deposits a token to the exchange module;

3. The user sends an order to the exchange module, which includes but is not limited to: the user's account on the parachain to which the exchange module belongs, the user's account on the target parachain, the amount of tokens deposited by the user to the exchange module, and The amount of tokens that the user expects to exchange;

4. The exchange module maintains an order table, which contains the orders submitted by each user.

According to another aspect of the present invention, the present invention also includes a cross-chain transfer method between different blockchains, the method uses the above-mentioned system, and the method includes the following steps:

(1) The sender initiates a transaction request in the source parachain, and transfers the tokens to be sent to the sending module of the source parachain;

(2) Each data sending and receiving node on the source parachain listens to the sending module, and after listening to the transaction request initiated by the sender, the data sending and receiving nodes each broadcast a transaction request to the Internet chain network;

(3) Through the consensus process of the interconnection chain, only the transaction from one of the source parachain data sending and receiving nodes is written into the blockchain of the interconnecting chain, and then the data sending and receiving node on the destination parachain broadcasts a A transaction request, the target transaction party of the transaction request is the exchange module of the target parachain, and carries the interchain transaction request issued by the active parachain data sending and receiving node in step (2) and the SPV verification information of the interchain transaction request;

(4) The exchange module calls the verification module on the destination parachain to verify the validity of the transaction request issued by the data sending and receiving node of the destination parachain. The verification process includes: the verification module verifies the interchain transaction request carried in the transaction through the SPV verification method validity, if the interchain transaction request is valid, it can be considered that the transaction request sent by the destination parachain data sending and receiving node is valid;

(5) The exchange module finds the order combination that matches the transfer process in the order table, and several orders in the order combination will be frozen. After that, these orders will not be selected by other cross-chain transfer processes, nor can they be withdrawn by the submitter;

(6) The data sending and receiving nodes on the destination parachain monitor the exchange module, and then each broadcast a transaction request to the interchain network. The transaction request contains order combination information, and the order combination information includes account, and the amount of source parachain tokens expected to be obtained by each submitter;

(7) Through the consensus process of the interconnection chain, only the transaction from a destination parachain data sending and receiving node is written into the blockchain of the interconnecting chain; after that, the data sending and receiving node of the source parachain issues a transaction request in the source parachain , the destination transaction party of the transaction request is the sending module of the source parachain, and at the same time, it also carries the interchain transaction request issued by the destination parachain data sending and receiving node in step (6) and the SPV verification information of the interchain transaction request;

(8) The sending module of the source parachain calls the verification module, and then verifies the validity of the transaction request issued by the source parachain data sending and receiving node. The verification process is the same as step (4);

(9) If the transaction request is valid, the sending module will transfer the token deposited by the transaction sender to the account of each submitter on the source parachain according to the token amount expected to be obtained by each order submitter;

(10) The data sending and receiving nodes of the source parallel chain each broadcast a transaction request to the Internet chain network, which contains order combination information;

(11) Each data sending and receiving node on the destination parachain broadcasts a transaction request in the destination parachain respectively. The destination transaction party of the transaction request is the exchange module of the destination parachain, and at the same time, it also carries the data sending and receiving of the source parachain The interchain transaction request issued by the node in step (10) and the verification information of the interchain transaction request;

(12) The exchange module calls the verification module on the destination parachain, and uses the same verification process as in steps (4) and (8) to verify the validity of the transaction request issued by the destination parachain data sending and receiving node. If the transaction request is valid , transfer the token deposited by the sender to the account of the receiver on the destination parachain.

Preferably, the present invention also includes the following steps:

If in the above step (7), the data sending and receiving node of the source parachain fails to learn the interchain transaction request issued by the data sending and receiving node of the destination parachain, at this time, the timer of the sending module of the source parachain will time out, and then, execute The following steps:

1. The sending module of the source parachain returns the token deposited by the sender to the sender's account;

2. After the data sending and receiving nodes of the source parachain detect the refund behavior of the sending module, they each broadcast a transaction request to the Internet chain network, which includes the refund information of the sending module;

3. After the consensus process of the interconnection chain, only the transaction request from one of the source parachain data sending and receiving nodes is written into the blockchain of the interconnecting chain, and the data sending and receiving nodes of the destination parachain construct a transaction request accordingly. The target transaction party of the request is the exchange module of the target parachain, and the transaction request carries the interchain transaction request issued by the active parachain data sending and receiving node in step 2 and the SPV verification information of the interchain transaction request, and then the transaction Request to publish to the target parachain network;

4. The exchange module on the target parachain calls the verification module to verify the validity of the transaction request from the data sending and receiving node of the target parachain. If the transaction request is valid, each order in the order combination will be unfrozen according to the refund information. These orders can then be picked up by other cross-chain transfer processes or withdrawn by the submitting party.

The present invention has the following advantages: any number of blockchains can be connected to the interconnected chain, and then participate in cross-chain transactions. Therefore, the present invention has good scalability. Atomicity can be guaranteed during the transfer process. Even if a certain link fails during the transfer process, the transfer process can be canceled as a whole, thereby ensuring that the participants in the transaction will not suffer economic losses.

Description of drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiment. The drawings are only for the purpose of illustrating a preferred embodiment and are not to be considered as limiting the invention. Also throughout the drawings, the same reference numerals are used to designate the same parts. In the attached picture:

Figure 1 is the architecture diagram of the interconnection chain.

Figure 2 is a block diagram of each parachain.

Figure 3 is the order table in the exchange module.

Figure 4 shows the flow of cross-blockchain transfers in the interconnected chain architecture.

Fig. 5 shows the processing flow of the present invention when the transfer process fails.

detailed description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided for more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

It is worth noting that the meaning of "transfer" in this invention is: an account on the first parachain converts part of its own assets into tokens of the second parachain with equal value in a certain way, and transfers The process of transferring converted assets to another account on the second parachain. In the present invention, this process is realized by the exchange module.

first embodiment

Figure 1 is the architecture diagram of the interconnection chain. Interchain is a blockchain used for transaction forwarding between different blockchains. Any blockchain can be connected to the Internet chain 101, and complete cross-chain transactions with the help of the Internet chain 101. The blockchain connected to the interconnected chain 101 is called a parallel chain. In Figure 1, each node in the parachain network 102 (parachain network nodes and data sending and receiving nodes) maintains a complete copy of the parachain 102, similarly, each node in the parachain network 103 maintains a parachain 103, each node in the parachain network 104 maintains a complete copy of the parachain 104.

Each parachain network contains one or more data sending and receiving nodes. Each data sending and receiving node keeps a complete copy of its own parachain. At the same time, each data sending and receiving node holds the account of the parallel chain, so it can receive and issue the transaction information of the parallel chain.

In addition, each data sending and receiving node also holds an account on the interconnection chain, so that it can receive and issue transaction information on the interconnection chain. In addition, data sending and receiving nodes can learn the real-time status of the interconnected chain, such as transaction information written into the interconnected chain.

The interchain network contains multiple verification nodes. On the one hand, the verification nodes synchronize the block headers of each parallel chain, and then verify the transaction requests from each parallel chain. On the other hand, maintain a complete copy of the interconnected chain and participate in the consensus process of the interconnected chain.

When a parallel link is connected to the Internet chain, the data sending and receiving node will send a request to the Internet chain network, and the request includes the SPV verification method for the transaction request of the parallel chain. Therefore, those skilled in the art should understand that, given the transaction request in the parachain and its verification information (the verification branch of the Merkle tree), the verification node can verify the validity of the parachain transaction request.

It is worth clarifying that the data sending and receiving nodes, network nodes, and verification nodes in the interconnection chain described in the embodiments of the present invention can be implemented by hardware such as computers, routers, and gateways, or by pure software. The implementation may also be implemented in a combination of software and hardware, as long as the functions that each node described in the above embodiments should have can be realized.

Figure 2 introduces the modules that should be included on each parachain. Each parachain 205 includes three modules as shown in FIG. 2 : sending module 201 , verification module 202 , and exchange module 203 . The functions of the three modules are briefly introduced.

First of all, it is worth clarifying that the sending module, verification module, and redemption module in the parachain described in the embodiment of the present invention can be implemented by hardware such as computers, routers, and gateways, and can also be implemented by pure software. It is implemented in a combination of software and hardware, as long as the functions that each node should have as described in the following embodiments can be realized.

When a user needs to transfer a sum of funds to an account on another blockchain, the user needs to first construct a transaction and temporarily store the funds to be transferred to the sending module 201 . The sending module 201 sets a timer for each temporarily deposited fund, and the temporarily deposited funds cannot be withdrawn before the timer expires.

The verification module 202 is used to synchronize the block header 206 of the interconnected chain in real time. Therefore, given the transaction request in the interconnected chain and its verification information (the verification branch of the Merkle tree), the verification module 202 can verify the validity of the transaction request in the interconnected chain. Both the sending module 201 and the exchange module 203 can call the verification module 202 to verify the transaction request in the interconnected chain.

Through the exchange module 203, users can exchange tokens issued by their own blockchain for tokens issued by another blockchain by submitting an order. For example, parachain X issues tokens named XCoin, and parachain Y issues tokens named YCoin. User Carol holds account X _C on parachain X and account Y _C on parachain Y. If Carol wants to exchange 5YCoin for 10XCoin, she needs to send 5YCoin to the exchange module 203 through the account Y _C . The 5YCoin submitted by Carol will be temporarily stored in the exchange module. From the perspective of parachain Y, parachain X is the "target parachain" and XCoin is the "target currency". At the same time, Carol sends an order to the exchange module 203 . The order includes the target parachain X, Carol's account Y _C on the parachain Y, the account X _C on the parachain X, the amount of YCoin submitted by Carol (5YCoin), and the amount of XCoin expected to be exchanged (10XCoin) . All orders submitted by users are stored in the order table 204 .

Certain blockchains, such as Ethereum, provide Turing-complete smart contracts. In this case, the above-mentioned sending module 201, verification module 202, and exchange module 203 can be implemented with smart contracts. However, it can also be implemented using other technologies in the blockchain. In addition, the above three modules can be combined with each other, or can be three independent modules. For example, when using a smart contract to implement three modules, the sending module 201, the verification module 202, and the exchange module 203 may be three components of a smart contract, or three independent smart contracts.

It is worth clarifying that the sending module, verification module, and redemption module in the parachain described in the embodiment of the present invention can be located in the data sending and receiving nodes, or in the network nodes, or distributed in data sending and receiving nodes. Among the nodes or network nodes, independent hardware or software may also be independent of both data transmitting and receiving nodes and network nodes, as long as the functions that each module described in the above embodiments should have can be realized.

Figure 3 shows the order table of parachain Y. Each row in Figure 3 represents an order. Among them, the order 301 in the second line is submitted by Carol.

The following is an example to introduce the process of transferring funds using the interconnected chain architecture.

Suppose Alice holds account X _a on parachain X, and Bob holds account Y _b on parachain Y. Alice wishes to transfer assets worth 10XCoin to Bob. Parachain X is the source parachain, and parachain Y is the destination parachain. Since Y _b can only accept assets in the form of YCoin, the 10XCoin from Alice must be converted into a certain amount of YCoin before it can be accepted by Y _b . In this embodiment, the amount of assets received by the recipient is specified by the sender. Suppose Alice wants Bob to receive 5YCoin. Here, it is assumed that the account of the sending module on parachain X is X _sc , the account of the verification module is X _VA ; the account of the exchange module on parachain Y is Y _EX , and the account of the verification module is Y _VA .

In the following description, a transaction request is described by t (source account, destination transaction party). It should be understood by those skilled in the art that this format is only used for convenience of description, rather than as a limitation of the transaction format.

Figure 4 shows the transfer process of this example.

In step S401, Alice initiates a transaction request t(X _a , X _sc ) through her own account X _a 401 to transfer 10XCoin to the sending module 402 of the parachain X. In this way, 10XCoin from Alice will be registered in the sending module 402. Alice will not be able to withdraw the deposited 10XCoin before the preset timer expires.

In step S402 , each data transceiving node 403 a to 403 c on the parachain X listens to the sending module 402 . After listening to the transaction request t(X _a , X _sc ), 403a to 403c each broadcast the transaction request t(X _gi , Y _g ) to the interconnected chain. The transaction request t(X _gi , Y _g ) means that the transaction request is sent by any data sending and receiving node X _gi in the parachain X, and any data sending and receiving node Y _g in the destination parachain Y can know the transaction request.

The original transaction request t(X _a , X _sc ) and the SPV verification information of t(X _a , X _sc ) are appended after t(X _gi , Y _g ). Here, the SPV verification information of t(X _a , X _sc ) is the verification branch of this transaction request on the Merkle tree. Those skilled in the art should understand that, given the block header and the verification branch on the Merkle tree, the verification nodes 404a to 404d in the interconnected chain can use the SPV verification method to verify the validity of t(X _a , X _sc ) . Since t(X _gi , Y _g ) is created from t(X _a , X _sc ), the validity of t(X _gi , Y _g ) can be verified indirectly.

Although there will be multiple versions of t(X _gi , Y _g ) signed by 403a to 403c in the interchain network, the verification node can recognize that they represent the same cross-chain transaction request, because t( X _gi , Y _g ) carry the same t(X _a , X _sc ). Through the internal consensus mechanism of the interconnected chain, only one version of t(X _gi , Y _g ) is written into the blockchain of the interconnected chain.

In step S403, after the data sending and receiving nodes 405a to 405b on the parachain Y learn that the transaction request t(X _gi , Y _g ) has been written into the blockchain of the interconnected chain, they each broadcast a transaction request in the parachain Y t(Y _gj ,Y _EX ). The destination transaction party of the transaction request is the exchange module Y _EX 406 on the parachain Y. At the same time, the t(X _gi ,Y _g ) that has been written into the interconnection chain, and the SPV verification information of t(X _gi ,Y _g ), will also be attached to t(Y _gj ,Y _EX ), thus being compatible with t(Y _gj , Y _EX ) broadcast together.

In step S404, the exchange module 406 invokes the verification module 407 on the parachain Y to determine the validity of t(Y _gj , Y _EX ). Although there are multiple t(Y _gj ,Y _EX ) issued by different data sending and receiving nodes in the parallel chain Y, since they all represent the same transfer operation, the verification module will only process one of the t(Y _gj , Y _EX ).

Since the verification module 407 can synchronize the block headers of the interconnected chain in real time, the verification module 407 can use the SPV verification method to verify the validity of t(X _gi , Y _g ) carried in t(Y _gj , Y _EX ). Since t(X _gi , Y _EX ) is created according to t(X _gi , Y _g ), the verification module 407 can indirectly verify the validity of t(Y _gj , Y _EX ). The verification module 407 will return true if t(Y _gj , Y _EX ) is valid, otherwise, return false.

After the verification module 407 returns true, in step S405, the redemption module 406 uses the matching algorithm based on the amount of XCoin deposited by Alice (10XCoin) and the amount of YCoin (5YCoin) that Alice expects Bob to receive, from the order saved by itself Find the order combination matching the transaction request t(Y _gj , Y _EX ) in the list. The present invention does not require the matching algorithm adopted by the exchange module 406 .

Assume that the exchange module 406 uses the order table in FIG. 3 and selects the second order order2, which is the order submitted by Carol, as the order matching the transaction request t(Y _gj , Y _EX ). Those skilled in the art should understand that the order combination matching t(Y _gj , Y _EX ) in this embodiment only includes one order, but in practical applications, the order combination may include multiple orders.

Once order2 is selected, the order will be frozen. In other words, order2 will not be able to be withdrawn temporarily, nor will it be selected by other cross-chain transfer operations.

Subsequently, in step S406, the data sending and receiving nodes 405a to 405b on the parachain Y each broadcast a transaction request t(Y _gj , X _g ) to the interchain network. The transaction request t(Y _gj , Y _EX ) of parachain Y, the relevant verification information of t(Y _gj , Y _EX ), and the information stored in order2 are all appended after t(Y _gj , X _g ).

Since there are multiple data sending and receiving nodes on the parallel chain Y, multiple t(Y _gj , X _g ) signed by different data sending and receiving nodes will be released to the interconnection chain. However, because it carries the same t(Y _gj , Y _EX ) and order information, only one version of t(Y _gj , X _g ) is written into the blockchain of the interconnected chain through the consensus process of the interconnected chain.

After the transaction request is written into the blockchain of the interconnected chain, in step S407, the data sending and receiving nodes 403a to 403c on the parachain X can all learn the content of t(Y _gj , X _g ). Subsequently, the data transceiving nodes 403a to 403c broadcast the transaction request t(X _gi , X _SC ) in the parachain X. The destination transaction party of the transaction request t(X _gi , X _SC ) is the sending module 402 . At the same time, the transaction request t(Y _gj ,X _g ) in the Internet chain, the SPV verification information of t(Y _gj ,X _g ), and the information saved in order2 are all attached to the transaction request t(X _gi ,X _SC ).

In step S408, the sending module 402 calls the verification module X _VA 408 on the parachain X to verify the validity of the transaction request t(X _gi , X _SC ). Since the verification module 408 synchronizes the block header of the interconnected chain in real time, it can use the SPV verification method to verify the validity of the attached transaction request t(Y _gj , X _g ). Since t(X _gi ,X _SC ) is created according to t(Y _gj ,X _g ), if t(Y _gj ,X _g ) is valid, then t(X _gi ,X _SC ) carrying it can be considered valid .

If t(X _gi , X _SC ) is valid, the verification module 408 returns true and enters step S409. At this time, the sending module 402 learns that the order submitted by Carol can meet Alice's transfer demand through the information saved in order2, so the sending module sends the 10XCoin deposited by Alice to Carol's account X _C on the parachain X. In this way, Carol obtained the 10XCoin that she wished to exchange.

Those skilled in the art should know that if the order combination contains multiple orders, the sending module will divide the 10XCoin deposited by Alice into multiple copies, and send them to each order submitter according to the amount expected to be exchanged by each order submitter. Account on parachain X.

In step S410, each data sending and receiving node 403a to 403c in the parachain X sends a signed transaction request t`(X <sub>gi</sub> , Y <sub>g</sub> ) to the interchain network as a proof that Carol has completed the currency exchange. Similar to step S402, in the end, only one version of t`(X _gi , Y _g ) is written into the blockchain of the interconnected chain.

In step S411, each data transceiving node 405a and 405b on the parachain Y can learn the transaction request t`(X <sub>gi</sub> , Y <sub>g</sub> ) written into the interconnected chain. Subsequently, 405a to 405b respectively broadcast a transaction request t`(Y _gj , Y _EX ) in the network of the parachain Y. Among them, t`(X <sub>gi</sub> ,Y <sub>g</sub> ) and its SPV verification information will be appended to t`(Y _gj ,Y _EX ).

After each network node of the parachain Y receives the transaction request t`(Y _gj , Y _EX ), enter step S412.

The exchange module 406 first calls the verification module 407 on the parachain Y to verify the validity of the transaction request t`(Y <sub>gj</sub> , Y <sub>EX</sub> ). The verification module 407 indirectly verifies the validity of the transaction request t`(Y _gj , Y _EX ) in the same manner as in step S404.

If the transaction request t`(Y _gj , Y _EX ) is valid, then the exchange module 406 can be sure that Carol has received 10XCoin on the parachain X. At this time, the exchange module 406 transfers the 5YCoin deposited by Carol to Bob on the parachain Account Y _b 409 on Y. In this way, Bob received the 5YCoin that Alice wanted to transfer to him. The transfer process is over.

From a microscopic point of view, Alice deposits 10XCoin in the sending module 402 on the parachain X through the account X _a , and then transfers it to Carol’s account X _C on the parachain X. At the same time, Carol transferred 5YCoin to the exchange module 406 on the parachain Y through the account Y _c , and then transferred it to Bob's account Y _b on the parachain Y. However, from a macro point of view, 10XCoin from account X _a was converted into 5YCoin and then transferred to account Y _b . Therefore, the present invention realizes cross-chain transfer.

Another situation of the present invention is described below. The data sending and receiving nodes 403a to 403c on the parachain X do not know the valid transaction request t(Y _gj , X _g ) in step S407. Therefore, an effective t(X _gi , X _SC ) cannot be constructed accordingly.

In this case, the timer of the sending module 402 on the parachain X will time out. Subsequently, the steps shown in FIG. 5 are executed.

In step S501, the sending module on the parachain X returns the 10XCoin deposited by Alice to the account X _a .

In step S502, after monitoring the refund behavior of the sending module, each data sending and receiving node on the parachain X constructs a transaction request t``(X <sub>gi</sub> , Y <sub>g</sub> ), which contains the refund information of the sending module . Then, send t``(X _gi , Y _g ) to the interchain network. After the consensus process of the interconnected chain, only t``(X _gi , Y _g ) from a data sending and receiving node is written into the blockchain of the interconnected chain.

After t``(X <sub>gi</sub> , Y <sub>g</sub> ) is written into the interconnected chain, in step S503, each data sending and receiving node on the parachain Y constructs a transaction request t``(Y _gj , Y _EX ). The destination transaction party of the transaction request is the exchange module on the parachain Y. At the same time, the transaction request t``(X <sub>gi</sub> ,Y <sub>g</sub> ) and its verification information are also appended to t``(Y _gj ,Y _EX ). Next, each data sending and receiving node broadcasts the transaction request t``(Y _gj , Y _EX ) constructed by itself to the network of the parachain Y.

In step 504, the exchange module on the parachain Y invokes the verification module to check the validity of t``(Y <sub>gj</sub> , Y <sub>EX</sub> ). If t``(Y _gj , Y _EX ) is valid, the redemption module can learn the refund information from t``(Y _gj , Y _EX ), so it unfreezes the order2 submitted by Carol. After that, order2 can be re-selected by other cross-chain transactions, and Carol can also withdraw this order. The process ends.

In this way, the present invention can guarantee the atomicity of cross-chain transactions. Even if the transaction is interrupted, the participants in the transaction will have no economic loss.

second embodiment

The inventive idea and main implementation steps of this embodiment are similar to those of the first embodiment, and the similarities will not be repeated here. The difference from Embodiment 1 is that processors and memories are used in this embodiment, and the specific method steps are implemented by parallel chains and/or interconnection chains distributed on the above-mentioned processors and/or memories.

It is worth clarifying that the sending module, verification module, and redemption module in the parachain described in the embodiment of the present invention can be implemented by hardware such as computers, routers, and gateways, or by pure software, or by software It can be implemented in a hard-bonded manner, as long as the functions that each node should have in the following embodiments can be realized.

It is worth clarifying that the sending module, verification module, and redemption module in the parachain described in the embodiment of the present invention can be located in the data sending and receiving nodes, or in the network nodes, or distributed in data sending and receiving nodes. Among the nodes or network nodes, independent hardware or software may also be independent of both data transmitting and receiving nodes and network nodes, as long as the functions that each module described in the above embodiments should have can be realized.

It is worth clarifying that the sending module, verification module, and redemption module in the parachain described in the embodiment of the present invention can all be located in the processor, or they can all be located in the memory, or they can be dispersedly distributed in the processor or memory Among them, it can also be independent of both the processor and the memory, and be implemented by independent hardware or software, as long as the functions that each module described in the above-mentioned embodiments should have can be realized.

third embodiment

The inventive idea and main implementation steps of this embodiment are similar to those of the first embodiment, and the similarities will not be repeated here. The difference from Embodiment 1 is that a storage medium is used in this embodiment, and specific method steps are implemented by computer programs distributed on the storage medium.

It is worth clarifying that the sending module, verification module, and redemption module in the parachain described in the embodiment of the present invention can be located in the data sending and receiving nodes, or in the network nodes, or distributed in data sending and receiving nodes. Among the nodes or network nodes, it can also be independent of both the data transmitting and receiving nodes and the network nodes, and be implemented by a separate program, as long as the functions that each module described in the above embodiments should have can be realized.

Those skilled in the art should understand that the above-mentioned embodiments are only illustrative. For example, the variable names of the above-mentioned parachains, accounts, and transactions are only for the convenience of description, rather than limiting the scope of protection.

The above is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of changes or modifications within the technical scope disclosed in the present invention. Replacement should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the protection scope of the claims.

Claims (20)

1. A cross-chain transfer system between different blockchains, the system includes at least one interconnected chain and a plurality of parallel chains, each of which is connected to the interconnected chain; it is characterized in that: Each of the parallel chains includes one or more data sending and receiving nodes and at least one other network node, and the data sending and receiving nodes are connected to one or more of the network nodes; the interconnection chain includes multiple verification nodes, the verification nodes are respectively connected to one or more of the data sending and receiving nodes; Wherein, the parachain further includes an exchange module, and the exchange module at least determines whether the transfer condition is met according to the two-way currency conversion quantity between the source parachain and the destination parachain. 2. A cross-chain transfer system between different blockchains as claimed in claim 1, characterized in that: The transfer conditions include transfer quantity and/or transfer time. 3. A cross-chain transfer system between different blockchains as claimed in claim 1, characterized in that: Each of the data sending and receiving nodes has kept a complete transaction copy of its own parachain and has an account in the parallel chain, and can receive transaction information in the parallel chain; each of the data sending and receiving nodes also keeps a Have an account, be able to receive and issue transaction information on the interconnection chain and obtain the real-time status of the interconnection chain; The verification node synchronizes the block headers of each parallel chain to verify the transaction request from each parallel chain, maintains a complete copy of the interconnected chain and participates in the consensus process of the interconnected chain. 4. A cross-chain transfer system between different blockchains as claimed in claim 3, characterized in that: The real-time status includes transaction information written into the interconnected chain. 5. A cross-chain transfer system between different blockchains as claimed in claim 1 or 2, characterized in that: The exchange module is further used to exchange the token issued by its own parachain for the token issued by another parachain. Within a certain period of time, if the amount of currency exchange between the two parachains is balanced, the transfer is successful. 6. A cross-chain transfer system between different blockchains according to claim 1 or 2, wherein, each of the parallel chains also includes the following modules: The sending module is used to temporarily store funds to be transferred in cross-chain transactions; The verification module is used to synchronize the block header of the interconnected chain in real time, and verify the validity of transactions in the interconnected chain; both the sending module and the exchange module can call the verification module. 7. A cross-chain transfer system between different blockchains as claimed in claim 6, characterized in that: The sending module sets a timer for each temporarily stored fund, and freezes the temporarily stored funds before the timer expires. 8. A cross-chain transfer system between different blockchains as claimed in claim 6, characterized in that: The exchange module maintains an order table, which contains the orders submitted by each user, and the order includes at least one of the following information: the user's account on the parachain to which the exchange module belongs, the user's account on the second parachain , the amount of tokens deposited by the user to the exchange module, and the amount of tokens that the user expects to exchange. 9. A cross-chain transfer method between different blockchains, characterized in that: The first parallel chain transfers money across chains to the second parallel chain through an interconnected chain; Among them, the first parachain determines whether the transfer is successful according to the amount of two-way currency conversion between itself and the second parachain. Within a certain period of time, when the currency conversion between the two parachains is balanced, the transfer can be successful. Otherwise the transfer fails. 10. A cross-chain transfer method between different blockchains, characterized in that the method specifically includes the following steps: (1) The first parachain broadcasts a first transaction request to the Internet chain network; (2) The first transaction request is written into the blockchain of the interconnected chain, and then a second transaction request is broadcast in the second parachain, and the target transaction party of the second transaction request is the exchange module of the second parachain ; (3) The second parachain verifies the validity of the second transaction request, finds an order combination that matches the transfer process, and freezes several orders in the order combination; (4) The second parachain broadcasts a third transaction request to the Internet chain network, and the third transaction request contains order combination information; (5) The third transaction request is written into the blockchain of the interconnected chain, and then a fourth transaction request is issued in the first parachain, and the destination transaction party of the fourth transaction request is the sending module of the first parachain ; (6) The first parachain verifies the validity of the fourth transaction request, and transfers the token deposited by the transaction sender to the token amount expected to be obtained by each order submitter to each submitter on the first parachain. account; (7) The first parachain broadcasts a fifth transaction request to the Internet chain network, which contains order combination information; (8) The fifth transaction request is written into the blockchain of the interconnected chain, and then a sixth transaction request is broadcast in the second parachain, and the destination transaction party of the sixth transaction request is the exchange module of the second parachain ; (9) The second parachain verifies the validity of the sixth transaction request, and transfers the token deposited by the sender to the receiver's account on the second parachain. 11. A cross-chain transfer method between different blockchains as claimed in claim 10, characterized in that: The verification process in the step (3) includes: the verification module verifies the validity of the first transaction request carried in the second transaction request through the SPV verification method, if the first transaction request is valid, then the second transaction request is valid of. 12. A cross-chain transfer method between different blockchains as claimed in claim 10, characterized in that: The verification process in the step (6) includes: the verification module verifies the validity of the third transaction request carried in the fourth transaction request through the SPV verification method, if the third transaction request is valid, then the fourth transaction request can be considered It is vaild. 13. A cross-chain transfer method between different blockchains as claimed in claim 10, characterized in that: In the above step (5), if the data transceiver node of the first parachain fails to learn the interchain transaction request issued by the data transceiver node of the second parachain, the timer of the first parachain sending module will time out and the transaction will fail . 14. A cross-chain transfer method between different blockchains as claimed in claim 10, characterized in that: After the transaction fails, steps (6) to (9) are no longer performed, but the following steps are directly performed: (a) The sending module of the first parachain returns the token deposited by the sender to the sender's account; (b) After detecting the refund behavior of the sending module, the data sending and receiving nodes of the first parachain broadcast a transaction request to the Internet chain network, which includes the refund information of the sending module; (c) After the consensus process of the interconnection chain, only the transaction request from one of the first parachain data sending and receiving nodes is written into the blockchain of the interconnecting chain, and then the data sending and receiving nodes of the second parachain construct a transaction accordingly request, the target transaction party of the transaction request is the exchange module of the second parachain, and the transaction request carries the interchain transaction request issued by the first parachain data sending and receiving node and the SPV verification information of the interchain transaction request, and then the A transaction request is issued to the second parachain network; (d) The exchange module on the second parachain invokes the verification module to verify the validity of the transaction request from the data sending and receiving node of the second parachain. If the transaction request is valid, each item in the order combination will be The order is unfrozen. 15. A cross-blockchain transfer method, characterized in that the method comprises: Receive a first transaction request, wherein the first transaction request requests to transfer the first token in the first parachain to the second parachain; Find at least one order matching the first transaction request in the order table, generate an order combination according to the at least one order, and freeze the orders in the order combination; Generate a second transaction request including the order combination, and issue the second transaction request to the first parachain through the interconnection chain; receiving a third transaction request, wherein the third transaction request is generated according to the transfer result of the second transaction request in the first parachain; When the third transaction request is verified, it is confirmed that the first transaction request and the order in the order combination are completed, and all transaction records are recorded. 16. A cross-blockchain transfer method, characterized in that the method comprises: Sending a first transaction request, wherein the first transaction request requests to transfer the first token in the first parachain to the second parachain; Receive the second transaction request issued by the interconnection chain to the first parachain, the second transaction request includes the order combination generated according to the first transaction request; the order includes at least one of the following information: The account on the parachain to which the exchange module belongs, the user's account on the second parachain, the amount of tokens deposited by the user to the exchange module, and the amount of tokens that the user expects to exchange; Verify the validity of the second transaction request, if it is invalid, terminate the transfer, and if it is valid, complete the transfer according to the above order combination; Sending a third transaction request, wherein the third transaction request is generated according to the transfer result of the second transaction request in the first parachain. 17. A cross-chain transfer method between different blockchains as claimed in claim 16, characterized in that: The method for generating the order combination is as follows: the exchange module of the second parachain uses a matching algorithm to find the order combination that matches the first transaction request from the order list stored by itself. 18. A cross-blockchain transfer method, characterized in that the method comprises: receiving one or more first transaction requests, wherein the first transaction request requests to transfer the first token in the first parachain to the second parachain; Writing the first transaction request into the blockchain of the interconnected chain through a consensus mechanism; Receive one or more second transaction requests, the second transaction request includes the order combination generated according to the first transaction request; the order includes at least one of the following information: Account, the user's account on the second parachain, the amount of tokens deposited by the user to the exchange module, and the amount of tokens that the user expects to exchange; Writing the second transaction request into the blockchain of the interconnected chain through a consensus mechanism; Receive one or more third transaction requests, the third transaction requests are generated according to the transfer results of the second transaction requests in the first parachain; Through a consensus mechanism, write the third transaction request into the blockchain of the interconnected chain. 19. A cross-chain transfer method between different blockchains as claimed in claim 18, characterized in that: The method for generating the order combination is as follows: the exchange module of the second parachain uses a matching algorithm to find the order combination that matches the first transaction request from the order list stored by itself. 20. A cross-chain transfer method between different blockchains as claimed in claim 18, characterized in that: The third transaction request is generated by each data sending and receiving node in the first parachain as proof of the transfer result.