Trusted and Efficient Cross-Blockchain Data Parallel Transfer Method Based on Relay Mechanism

Abstract

The present invention provides a trusted and efficient cross-blockchain data parallel transfer model based on a relay mechanism. Using this method, it is possible to support efficient information transfer between homogeneous or heterogeneous blockchains that can support key-value pair reading and writing operations. This includes, but is not limited to: between Hyperledger Fabric and Hyperledger Fabric, between Hyperledger Fabric and Hyperledger Sawtooth, and between Ethereum and Hyperledger. Compared with traditional cross-chain data transfer methods, the present invention decouples cross-chain related components and specific application chains through RPC calls, making it theoretically possible to support all application chains that can read and write. To improve performance, methods such as parallel transmission and multi-threaded parallel query are introduced, which can transfer data in the target chain to the source chain faster, and the relay chain records the transfer events to prevent both parties from denying the fact that the transfer event occurred.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain, and particularly relates to a reliable and efficient cross-blockchain data parallel transfer method based on a relay mechanism. Background Art

[0002] A blockchain is a distributed database system that uses a P2P network for communication. It has the characteristics of decentralization, trustlessness, data transparency, and traceability. There are already dozens of common blockchains, and their consensus mechanisms and storage mechanisms are different, so they cannot communicate directly. However, we have a need for cross-blockchain communication, which can be divided into two categories. The first is that existing blockchains have chosen different blockchain technologies for their own usage scenarios, creating information silos. The other is that when designing at the beginning, considering storage pressure, etc., using a single-chain node to fully back up data will cause too much pressure, so the main and slave chains are divided, but there is still a communication need between the main and slave chains.

[0003] Currently, all cross-chain solutions can be divided into four main modes, including manual asset transposition, notary mechanism, and side-chain mechanism. Among them, although manual asset transposition / hash locking is simple to implement, it is only applicable to the asset transposition scenario and cannot be applied to read / write scenarios. Although the notary mechanism has relatively high implementation efficiency and can be used in read / write scenarios, its degree of decentralization will be affected because all participants need to trust this third party. The side-chain mechanism is relatively complex to implement because it needs to solve the inter-chain communication problem in a P2P manner, and the efficiency is relatively low compared to the middleman, but the advantage is that it retains decentralization.

[0004] The existing methods consider scenarios relatively comprehensively, pay more attention to the generality of various scenarios, and have more verification steps. However, in the scenario of a large amount of data transfer that highly values performance, the latency is unacceptable to users, that is, its performance is low and cannot meet the scenario of a large amount of data transfer. Summary of the Invention

[0005] The purpose of the present invention is to provide a reliable and efficient cross-blockchain data parallel transfer method based on a relay mechanism for the deficiencies of the existing model in the scenario of a large amount of data transfer, which can sacrifice part of the security to meet the requirements of users for low time-consuming and high-performance data exchange in the scenario where there is a large amount of data demand between multiple blockchains.

[0006] To achieve the above object, the technical solution of the present invention is: to provide a reliable and efficient cross-blockchain data parallel transfer method based on a relay mechanism, including the following steps:

[0007] S1: Set up the application connection plug-in. Connect to the application chain by using the client APIs of different blockchains. On the other hand, this plug-in should also be started as an RPC server, encapsulating a unified operation protocol to provide operation interfaces for the upper layer.

[0008] S2: Set up the relay chain. Each blockchain participating in data transfer needs to start its own relay chain node. The relay chain has the roles of cross-chain transaction routing and on-chain data consensus endorsement.

[0009] S3: Set up the gateway. The gateway acts as an intermediary, connecting to the application chain client and the relay chain respectively.

[0010] S4: The source chain initiates transfer requests in parallel. A number of requests will wait in the transaction queue and will be uniformly packaged and encapsulated by the gateway after a fixed time window, and then passed from the gateway to the relay chain.

[0011] S5: The relay chain nodes broadcast requests for synchronization and consensus, and will route the requests to the corresponding gateways. The gateways then pass them to the destination chain for multi-threaded parallel query, write the query results into the result fields and return them to the gateways, and then further pass them back to the relay chain.

[0012] S6: The relay chain broadcasts the requests for returning results to other relay chain nodes. The relay chain nodes perform hash operations on all the received requests and then persistently store them, and send the request responses to the corresponding gateways, and then write the results to the corresponding application chain.

[0013] Preferably, the said S1 includes the following steps:

[0014] S1-1: Deploy a contract on the corresponding application chain that can read and write the data to be transferred, and then record the name of the contract, the name of the corresponding call method in the contract, and the call parameters, etc.

[0015] S1-2: Implement the corresponding client according to the contract content in step S1-1, ensuring that the implemented client can normally interact with the contract deployed in step S1-1 to retrieve the data to be queried from the application chain or write the data to be written into the application chain.

[0016] S1-3: Package the data read and write interfaces of the client into an RPC server, wrap the read and write capabilities into a service, decouple the subsequent components from specific application chain types, and this part serves as the application connection plug-in.

[0017] Preferably, the said S2 includes the following steps:

[0018] S2-1: The application chain starts a relay chain node as the representative in the cross-chain network.

[0019] If the current application chain is the first application chain in the cross-chain network, directly start a relay chain node and record the IP of the server where the relay chain node is located and the port number of the starting node.

[0020] If the current application chain wants to join an existing cross-chain network, connect the newly started relay node to the existing node according to the IP and port number of any existing relay node.

[0021] S2-2: When a new node is added, the node connected to the new node will perform a broadcast to synchronize the information of the new node to other relay chain nodes to facilitate subsequent consensus on the process of transferring data. Then, it will also transmit the IP and port numbers of other nodes to the newly added relay chain node.

[0022] Preferably, S3 includes the following steps:

[0023] S3-1: Start the client slot module of the gateway. This slot is the client of the RPC server described in S1-3, and the gateway system can implement the final read and write operations on the application chain through the slot module.

[0024] S3-2: Start the relay communication module of the gateway. This module is used to communicate with the relay chain, transmit the cross-chain data transfer data packet to the relay chain for further routing, or receive the data transfer data packet transmitted from other application chains from the relay chain.

[0025] Preferably, S4 includes the following steps:

[0026] S4-1: The source chain sends several data transfer requests to the plugin. The transfer requests include the address of the target gateway and the key-value of the data to be transferred. The plugin part will store these requests using a table structure with the key being the target gateway address target_addr and the value being a queue. Requests with the same target address will be stored in the same queue, and each request has a unique identifier req_id.

[0027] S4-2: The gateway polls the plugin at regular intervals. When the time is up, it will pack all the requests in the time window from the previous poll to this poll, that is, connect the head and tail of the queue to form a large data packet. Send this data packet to the relay chain for routing.

[0028] Preferably, S5 includes the following steps:

[0029] S5-1: The relay chain node that receives the request broadcasts the large data packet received from the gateway to other relay chain nodes so that all relay chain nodes have a copy of all the data packets.

[0030] S5-2: All relay chain nodes unpack all large data packets they possess, check whether the destination gateway address target_addr of each request belongs to the same gateway address corresponding to this node. If so, route the request to this gateway, and the gateway will submit it to the plugin for further data query.

[0031] S5-3: At the plugin, multi-threads will be started to allocate different query tasks to each node of the application chain. For example, there are 300 query tasks numbered from 1 to 300, and there are 3 nodes in the application chain. Then, tasks numbered from 1 to 100 will be assigned to node 1, tasks numbered from 101 to 200 will be assigned to node 2, and tasks numbered from 201 to 300 will be assigned to node 3 to achieve the purpose of parallel query, and the query results will be written into the result field of the request body.

[0032] Preferably, the S6 includes the following steps:

[0033] S6-1: Pack the processed request body and collect it back from the plugin to the gateway, and broadcast the processed request body to other relay chain nodes.

[0034] S6-2: Each relay chain node persists all request bodies in this query process to the machine where the relay chain node is located.

[0035] S6-3: Forward the requests with the same source gateway address and the gateway address corresponding to this relay chain to the application chain connected to the gateway, and then write the results into a write queue in the application chain gateway, allowing the subsequent actual writing program to consume. At this time, the gateway can start processing the next batch of request packets.

[0036] S6-4: The actual writing program continuously takes out the request keys and the values queried from the target application chain from the write queue, and writes the key-value pairs into the source application chain. When the writing is completed, the transfer of one piece of data is completely finished.

[0037] Advantages of the present invention:

[0038] Compared with the traditional cross-chain model that overemphasizes general-purpose and security scenarios, this method pays more attention to the performance issue when a large amount of data needs to be transferred between blockchains. Through packetized parallel transmission, multi-threaded parallel query, and the execution of the write process with queue-delayed time-consuming, the transmission rate in the scenario of large data transfer can be several times faster than the traditional method. Therefore, when a large amount of data needs to be transferred across blockchains in a scenario where security is not the most important consideration, this method can be used to achieve it. Description of the Drawings

[0039] Figure 1 It is a schematic flowchart of a trusted and efficient cross-blockchain data parallel transfer method based on a relay mechanism.

[0040] Figure 2 It is a schematic diagram of the overall structure of the cross-chain system in the scenario of two application chains.

[0041] Figure 3 It is a schematic diagram of the cross-chain request structure.

[0042] Figure 4 It is a schematic diagram of the storage structure of the cross-chain request by the application chain plugin.

[0043] Figure 5 It is a schematic diagram of the data packet structure packed by the gateway.

[0044] Figure 6 It is a schematic diagram of the process of parsing and routing the data packet at the gateway.

[0045] Figure 7 It is a schematic diagram of the process of the application chain plugin allocating query tasks to each node of the application chain.

[0046] Figure 8 At the relay chain, the request result is hashed and written into the relay chain.

[0047] Figure 9 It is a schematic diagram of the process of the gateway writing the query result into the queue and the application chain consuming the query result. Detailed implementation method

[0048] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the present invention, rather than limiting the present invention.

[0049] Embodiment 1: Please refer to Figures 1 to 4 As shown, the present invention provides a trusted and efficient cross-blockchain data parallel transfer method based on a relay mechanism, including the following steps:

[0050] S1: Build an application chain access plugin, connect to the application chain by using the client APIs of different blockchains. On the other hand, the plugin also needs to be started as an RPC server, encapsulating a unified operation protocol to provide an operation interface for the upper layer.

[0051] S2: Build a relay chain. Each blockchain participating in data transfer needs to start its own relay chain node. The relay chain has the roles of cross-chain transaction routing and on-chain data consensus endorsement.

[0052] S3: Build a gateway. The gateway acts as an intermediary, connecting to the application chain client and the relay chain respectively.

[0053] S4: The source chain initiates transfer requests in parallel. A number of requests will wait in the transaction queue and will be uniformly packaged and encapsulated by the gateway after a fixed time window, and then passed from the gateway to the relay chain.

[0054] S5: The relay chain nodes broadcast requests for synchronous consensus and route the requests to the corresponding gateways. The gateways then pass them to the destination chain for multi-threaded parallel querying. The query results are written into the result fields and returned to the gateways, and then further passed back to the relay chain.

[0055] S6: The relay chain broadcasts the requests with return results to other relay chain nodes. The relay chain nodes perform hash operations on all the received requests and then persistently store them, and send the request responses to the corresponding gateways, and then write the results to the corresponding application chains.

[0056] The above S1 includes the following steps:

[0057] S1-1: Deploy a contract on the corresponding application chain that can read and write the data to be transferred, and then record the name of the contract, the name of the corresponding call method in the contract, and the call parameters, etc.

[0058] S1-2: Implement the corresponding client according to the contract content deployed in step S1-1, ensuring that the implemented client can normally interact with the contract deployed in step S1-1 to retrieve the data to be queried from the application chain or write the data to be written into the application chain.

[0059] S1-3: Package the data read and write interfaces of the client into an RPC server, and package the read and write capabilities into a service to decouple subsequent components from specific application chain types. This part serves as an application link-in plugin.

[0060] The above S2 includes the following steps:

[0061] S2-1: The application chain starts a relay chain node as the representative in the cross-chain network.

[0062] If the current application chain is the first application chain in the cross-chain network, then directly start a relay chain node and record the IP of the server where the relay chain node is located and the port number of the starting node.

[0063] If the current application chain wants to join an existing cross-chain network, then connect the newly started relay node to the existing node according to the IP and port number of any existing relay node.

[0064] S2-2: When a new node is added, the nodes connected to the new node will broadcast once to synchronize the information of the new node to other relay chain nodes, which facilitates the subsequent consensus on the process of transferring data. Then, the IP and port numbers of other nodes will also be transmitted to the newly added relay chain node.

[0065] The said S3 includes the following steps:

[0066] S3-1: Start the client slot module of the gateway. This slot is the client of the RPC server described in S1-3, and the gateway system can implement the final read and write operations on the application chain through the slot module.

[0067] S3-2: Start the relay communication module of the gateway. This module is used to communicate with the relay chain, transmit the cross-chain data transfer data packet to the relay chain for further routing, or receive the data transfer data packet transmitted from other application chains from the relay chain.

[0068] The said S4 includes the following steps:

[0069] S4-1: The source chain sends several data transfer requests to the plugin. The transfer requests include the address of the target gateway and the key-value of the data to be transferred. The plugin part will store these requests using a table structure with the key as the target gateway address target_addr and the value as the queue. Requests with the same target address will be stored in the same queue, and each request has a unique identifier req_id.

[0070] S4-2: The gateway polls the plugin regularly. When the timing arrives, it will pack all the requests in the time window from the previous poll to this poll, that is, connect the head and tail of the queue to form a large data packet. Send this data packet to the relay chain for routing.

[0071] The said S5 includes the following steps:

[0072] S5-1: The relay chain node that receives the request broadcasts the large data packet received from the gateway to other relay chain nodes, so that all relay chain nodes have copies of all data packets.

[0073] S5-2: All relay chain nodes unpack all the large data packets they have and check whether the destination gateway address target_addr of each request belongs to the same gateway address corresponding to the node. If so, the request will be routed to this gateway, and the gateway will submit it to the plugin for further data query.

[0074] S5-3: At the plugin, multiple threads will be started to assign different query tasks to each node of the application chain. For example, there are 300 query tasks numbered from 1 to 300, and the application chain has 3 nodes. Then, the tasks numbered from 1 to 100 will be assigned to node 1, the tasks numbered from 101 to 200 will be assigned to node 2, and the tasks numbered from 201 to 300 will be assigned to node 3, so as to achieve the purpose of parallel query, and write the query results into the result field of the request body.

[0075] The said S6 includes the following steps:

[0076] S6-1: Pack the processed request body and collect it back from the plugin to the gateway, and broadcast the processed request body to other relay chain nodes.

[0077] S6-2: Each relay chain node persists all the request bodies in this query process to the machine where the relay chain node is located.

[0078] S6-3: Forward the requests with the same source gateway address and the gateway address corresponding to this relay chain to the application chain connected to the gateway, and then write the results in a write queue in the application chain gateway, so that the subsequent actual writing program can consume them. At this time, the gateway can start processing the next batch of request packets.

[0079] S6-4: The actual writing program continuously takes out the request keys and the values queried from the target application chain from the write queue, and writes the key-value pairs into the source application chain. When the writing is completed, the transfer of one piece of data is completely finished.

[0080] Embodiment 1

[0081] In this embodiment, two or more blockchains that have not been connected and exist in the form of isolated islands are mainly described, that is, components such as the relay chain and the gateway have not been started yet. At this time, in order to obtain the cross-chain data transfer ability, the startup process of relevant components needs to be completed. After successfully starting the relevant components, large-scale cross-chain data transfer can be carried out. Therefore, in the content described in this embodiment, the first half is about the startup steps of relevant components, and the second half is about the usage steps of the entire cross-chain system. Before starting the steps, it is necessary to ensure that there are two or more blockchains running normally, and smart contracts can be deployed on them, and there is a suitable client technology to call the smart contracts to obtain corresponding responses or write corresponding data.

[0082] Step 1: Build an application link access plugin, connect to the application chain, and provide an interface for gateway operations.

[0083] Connect to the application chain by using the client APIs of different blockchains. On the other hand, the plugin also needs to be started as an RPC server, encapsulating a unified operation protocol to provide an operation interface for the upper layer. Before performing this step, it is necessary to ensure that the application chain to be connected supports smart contracts and can call the deployed smart contracts through a specific client.

[0084] Deploy a contract on the corresponding application chain that can read and write the data to be transferred, and then record the name of the contract, the name of the corresponding call method in the contract, and the call parameters, etc. Implement the corresponding client according to the content of the deployed contract, ensuring that the implemented client can interact with the deployed contract normally to retrieve the data to be queried from the application chain or write the data to be written into the application chain. Finally, encapsulate the data read and write interfaces of the client into an RPC server, packaging the read and write capabilities as services to decouple subsequent components from specific application chain types.

[0085] Step 2: Each application chain starts its own relay chain node to enable multiple application chains to reach a consensus on data.

[0086] The application chain starts a relay chain node as a representative in the cross-chain network. The relay chain has the roles of cross-chain transaction routing and on-chain data consensus endorsement. If the current application chain is the first application chain in the cross-chain network, then directly start a relay chain node and record the IP of the server where the relay chain node is located and the port number of the starting node. If the current application chain wants to join an existing cross-chain network, then connect the newly started relay node to the existing node according to the IP and port number of any existing relay node.

[0087] When a new node joins, if there are already more than two nodes in the relay chain including the new node, the old relay chain node to which the new relay chain node connects when joining will broadcast the IP and port number of the new relay chain node to other old relay chain nodes, thereby reaching a consensus on the event of the newly joined node. At the same time, the old node will also transmit the IP and port numbers of other relay chain nodes to the new relay chain node for storage, facilitating subsequent broadcast operations on the relay chain.

[0088] Step 3: Set up gateways and start two gateway components to connect to the application chain client and the relay chain respectively.

[0089] The gateway part consists of two sub-components, which are responsible for connecting the application chain and the relay chain nodes respectively. First, the client slot module of the gateway is started. This slot serves as the client of the RPC server of the application link-in plugin as described above. The gateway system can perform read and write operations on the application chain through the slot module. Then, the relay communication module of the gateway is started. This module is used to communicate with the relay chain, transfer cross-chain data transfer data packets to the relay chain for further routing, or receive data transfer data packets transmitted from other application chains from the relay chain.

[0090] Step 4: The source chain initiates transfer requests in parallel. A number of requests will wait in the transaction queue and will be uniformly packed and taken away by the gateway after a fixed time window. The gateway passes them to the relay chain for routing consensus.

[0091] The source chain sends several data transfer requests to the plugin. The transfer requests include the address of the target gateway and the key-value of the data to be transferred. The plugin part will use a table structure with the key being the target gateway address target_addr and the value being the queue to store these requests. Requests with the same target address will be stored in the same queue, and each request has a unique identifier req_id. The gateway polls the plugin at regular intervals. When the time is up, it will pack all the requests in the time window from the previous poll to this poll, that is, connect the head and tail of the queue to form a large data packet. This data packet is sent to the relay chain for routing.

[0092] Step 5: The relay chain records the transaction endorsement, performs routing, and passes it to the corresponding gateway.

[0093] The relay chain node that receives the request broadcasts the large data packet received from the gateway to other nodes, so that all relay chain nodes have copies of all data packets. All relay chain nodes unpack all the large data packets they have and check whether the destination gateway address target_addr of each request belongs to the same gateway address corresponding to the node. If so, the request is routed to this gateway, and the gateway will submit it to the plugin for further data query. At the plugin, multi-threads will be started to allocate different query tasks to each node of the application chain. For example, there are 300 query tasks numbered from 1 to 300, and there are 3 nodes in the application chain. Then, the tasks numbered from 1 to 100 are assigned to node 1, the tasks numbered from 101 to 200 are assigned to node 2, and the tasks numbered from 201 to 300 are assigned to node 3 to achieve the purpose of parallel query, and the query results are written into the result field of the request body.

[0094] Step 6: The relay chain broadcasts the request for the return result to other relay chain nodes, performs hash operation on the request and persists it, and sends the request reply to the corresponding gateway, and then writes the result to the corresponding application chain.

[0095] Pack the processed request body and collect it back from the plugin to the gateway. Broadcast the processed request body to other relay chain nodes. Each relay chain node persists all the request bodies in this query process to the machine where the relay chain node is located. Forward the requests with the same source gateway address and the gateway address corresponding to this relay chain to the application chain connected to the gateway, and then write the results to a write queue in the application chain gateway for subsequent actual writing programs to consume. At this time, the gateway can start processing the next batch of request packets. The actual writing program continuously retrieves the request keys and the values queried from the target application chain from the write queue and writes the key-value pairs to the source application chain. When the writing is completed, the transfer of one piece of data is completely finished.

[0096] Embodiment 2

[0097] In this embodiment, it mainly describes a cross-chain network composed of two or more blockchains that have installed components such as gateways, relay chains, and application chain plugins. Therefore, in this embodiment, there is no need to install the relevant plugins again and it can directly start from step 4, that is, the source chain initiates transfer requests in parallel.

[0098] Step 4: The source chain initiates transfer requests in parallel. A number of requests will wait in the transaction queue and will be uniformly packed and taken away by the gateway after a fixed time window. The gateway passes them to the relay chain for routing consensus.

[0099] The source chain initiates several data transfer requests to the plugin. The transfer requests include the address of the target gateway and the key-value of the data to be transferred. The plugin part will store these requests using a table structure with the key being the target gateway address target_addr and the value being the queue. Requests with the same target address will be stored in the same queue, and each request has a unique identifier req_id. The gateway polls the plugin at regular intervals. When the time is up, it will pack all the requests in the time window from the previous poll to this poll, that is, connect the queue head to the tail to form a large data packet. Send this data packet to the relay chain for routing.

[0100] Step 5: The relay chain records the transaction endorsement, performs routing, and transfers it to the corresponding gateway.

[0101] The received relay chain node broadcasts the large data packet received from the gateway to other nodes, so that all relay chain nodes have copies of all data packets. All relay chain nodes unpack all the large data packets they have and check whether the destination gateway address target_addr of each request belongs to the same gateway address corresponding to the node. If so, the request is routed to the gateway, and the gateway submits it to the plugin for further data query. At the plugin, multiple threads are started to assign different query tasks to each node of the application chain. For example, there are 300 query tasks numbered from 1 to 300, and there are 3 nodes in the application chain. Then, the tasks numbered from 1 to 100 are assigned to node 1, the tasks numbered from 101 to 200 are assigned to node 2, and the tasks numbered from 201 to 300 are assigned to node 3 to achieve the purpose of parallel query, and the query results are written into the result field of the request body.

[0102] Step 6: The relay chain broadcasts the request for the return result to other relay chain nodes, performs a hash operation on the request and then persists it, and sends the request reply to the corresponding gateway, and then writes the result to the corresponding application chain.

[0103] The processed request body is packed and collected back from the plugin to the gateway, and the processed request body is broadcast to other relay chain nodes. Each relay chain node persists all the request bodies in this query process on the machine where the relay chain node is located. The request with the same source gateway address as the gateway address corresponding to the relay chain is forwarded to the application chain connected to the gateway, and then the result is written into a write queue in the application chain gateway for subsequent actual writing programs to consume. At this time, the gateway can start processing the next batch of request packets. The actual writing program continuously takes out the request key and the value queried from the target application chain from the write queue and writes the key-value pair into the source application chain. When the writing is completed, the transfer of one piece of data is completely completed.

[0104] Note that the above is only the preferred embodiment of the present invention and the applied technical principles. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described here, and various obvious changes, re-adjustments and substitutions can be made by those skilled in the art without departing from the protection scope of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments. Without departing from the concept of the present invention, more other equivalent embodiments can be included, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A trusted and efficient cross-blockchain data parallel transfer method based on a relay mechanism, characterized in that Including the following steps: S1: Set up the application link into the plugin. Connect to the application chain by using the client APIs of different blockchains. On the other hand, the plugin also needs to be started as a Remote Procedure Call server, i.e., an RPC server, and encapsulate a unified operation protocol to provide an operation interface for the upper layer. S2: Set up the relay chain. Each blockchain participating in data transfer needs to start its own relay chain node. The relay chain has the roles of cross-chain transaction routing and on-chain data consensus endorsement. S3: Set up the gateway. The gateway acts as an intermediary, connecting to the application chain client and the relay chain respectively. S4: The source chain initiates transfer requests in parallel. A number of requests will wait in the transaction queue and will be uniformly packaged and encapsulated by the gateway after a fixed time window, and then passed from the gateway to the relay chain. S5: The relay chain nodes broadcast requests for synchronization and consensus, and route the requests to the corresponding gateway. The gateway then passes them to the destination chain for multi-threaded parallel query, writes the query results into the result field and returns them to the gateway, and then further passes them back to the relay chain. S6: The relay chain broadcasts the requests with return results to other relay chain nodes. The relay chain nodes perform hash operations on all the received requests and then persistently store them, and send the request responses to the corresponding gateway, and then write the results to the corresponding application chain.

2. The trusted and efficient cross-blockchain data parallel transfer method based on the relay mechanism according to claim 1, wherein The S1 includes the following steps: S1-1: Deploy a contract on the corresponding application chain that can read and write the data to be transferred, and then record the name of the contract, the name of the corresponding call method in the contract, and the call parameters. S1-2: Implement the corresponding client according to the contract content deployed in step S1-1, ensuring that the implemented client can normally interact with the contract deployed in step S1-1 to retrieve the data to be queried from the application chain or write the data to be written into the application chain. S1-3: Package the data read and write interfaces of the client into an RPC server, package the read and write capabilities into a service, decouple the subsequent components from a specific application chain type, and use it as the application link into the plugin.

3. The trusted and efficient cross-blockchain data parallel transfer method based on the relay mechanism according to claim 1, wherein The S2 includes the following steps: S2-1: The application chain starts a relay chain node as the representative in the cross-chain network. If the current application chain is the first application chain in the cross-chain network, directly start a relay chain node and record the IP of the server where the relay chain node is located and the port number of the starting node. If the current application chain wants to join an existing cross-chain network, connect the newly started relay node to the existing node according to the IP and port number of any existing relay node. S2-2: When a new node joins, the node connected to the new node will perform a broadcast to synchronize the information of the new node to other relay chain nodes to facilitate subsequent consensus on the data transfer process, and then also transmit the IP and port numbers of other nodes to the newly joined relay chain node.

4. The trusted and efficient cross-blockchain data parallel transfer method based on the relay mechanism according to claim 1, characterized in that, The S3 includes the following steps: S3-1: Start the client slot module of the gateway. This slot is the client of the RPC server described in S1-3. The gateway system can perform read and write operations on the application chain through the slot module. S3-2: Start the relay communication module of the gateway. This module is used to communicate with the relay chain, transfer cross-chain data transfer data packets to the relay chain for further routing, or receive data transfer data packets transmitted from other application chains from the relay chain.

5. The trusted and efficient cross-blockchain data parallel transfer method based on a relay mechanism according to claim 1, wherein The S4 includes the following steps: S4-1: The source chain sends several data transfer requests to the plugin. The transfer requests include the address of the target gateway and the key-value of the data to be transferred. The plugin part will store these requests using a table structure with the key as the target gateway address target_addr and the value as a queue. Requests with the same target address will be stored in the same queue, and each request has a unique identifier req_id. S4-2: The gateway polls the plugin at regular intervals. When the timing arrives, it will pack all the requests in the time window from the previous poll to this poll, that is, connect the head and tail of the queue to form a large data packet, and send this data packet to the relay chain for routing.

6. The trusted and efficient cross-blockchain data parallel transfer method based on the relay mechanism according to claim 1, wherein The S5 includes the following steps: S5-1: The relay chain node that receives the request broadcasts the large data packet received from the gateway to other relay chain nodes, so that all relay chain nodes have copies of all data packets. S5-2: All relay chain nodes unpack all the large data packets they have and check whether the destination gateway address target_addr of each request belongs to the gateway address corresponding to this node. If so, the request will be routed to this gateway, and the gateway will submit it to the plugin for further data query. S5-3: At the plugin, multi-threads will be started to allocate different query tasks to each node of the application chain. There are 300 query tasks numbered from 1 to 300. If the application chain has 3 nodes, then the tasks numbered from 1 to 100 will be assigned to node 1, the tasks numbered from 101 to 200 will be assigned to node 2, and the tasks numbered from 201 to 300 will be assigned to node 3 to achieve the purpose of parallel query, and the query results will be written into the result field of the request body.

7. The method for parallel transfer of cross-blockchain data based on a relay mechanism according to claim 1, characterized in that The S6 includes the following steps: S6-1: Pack the processed request body and collect it back to the gateway from the plugin, and broadcast the processed request body to other relay chain nodes. S6-2: Each relay chain node persists all the request bodies in this query process to the machine where the relay chain node is located. S6-3: Forward the requests with the same source gateway address and the gateway address corresponding to this relay chain to the application chain connected to the gateway, and then write the results in a write queue in the application chain gateway, so that the subsequent actual writing program can consume them. At this time, the gateway can start processing the next batch of request packets. S6-4: The actual writing program continuously takes out the request keys and the values queried from the target application chain from the write queue, and writes the key-value pairs into the source application chain. When the writing is completed, a data transfer is completely completed.

Images