Cross-blockchain system for performing transactions, cross-chain transaction method and device

By introducing a relayer with a trusted execution environment into cross-chain transactions, the trustworthiness issue of cross-chain transactions is solved, ensuring the accuracy and integrity of transaction results and realizing trusted execution of cross-chain transactions.

CN114255031BActive Publication Date: 2026-04-10HUAWEI TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-09-23
Publication Date
2026-04-10

AI Technical Summary

Technical Problem

How to ensure the credibility of cross-chain processes, especially to achieve secure and reliable cross-chain transactions between heterogeneous blockchain platforms.

Method used

By introducing relays with trusted execution environments into cross-chain transactions, the trustworthiness of cross-chain transactions is ensured. The relays verify and sign transaction results within their trusted execution environments and record transaction states in the cross-chain management contract, ensuring the durability and consistency of cross-chain transactions.

Benefits of technology

It achieves the credibility of cross-chain transactions, ensures the accuracy and integrity of transaction results, prevents malicious tampering, and ensures the isolation and consistency of cross-chain transactions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114255031B_ABST
    Figure CN114255031B_ABST
Patent Text Reader

Abstract

The application provides a cross-blockchain system, a cross-chain transaction method and equipment for performing a transaction, wherein the method comprises: sending a first instruction for indicating performing a first sub-transaction to a first node, and sending a request of a cross-chain transaction to a second relay, wherein the first node maintains a first blockchain, the second relay corresponds to a second blockchain, the cross-chain transaction comprises the first sub-transaction performed on the first blockchain and a second sub-transaction performed on the second blockchain; receiving an execution result of the first sub-transaction from the first node, and receiving an execution result of the second sub-transaction from the second relay; and determining an execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction in a trusted execution environment of the first relay. By using the embodiment of the application, the cross-chain process can be ensured to be credible, the cross-chain transaction can be isolated, and the cross-chain transaction can be atomic.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, and particularly relates to a cross-blockchain system for executing transactions, a cross-chain transaction method and equipment. BACKGROUND

[0002] The blockchain technology is applied to many fields due to its advantages of decentralization, non-tamperability and traceability. With the rapid development of the blockchain technology and the great support of national policies, the research on the underlying technology of the blockchain and the exploration of industrial applications show an explosive growth trend. At present, the blockchain technology has been widely applied to financial, government services, Internet of Things and many other business scenarios. Many blockchain platforms have emerged at home and abroad. Foreign platforms include Ethereum, Hyperledger Fabric, and domestic platforms include self-developed blockchain platforms of Ali, Tencent, Blockv, WeChain and other enterprises. At present, various enterprises focus on building differentiated blockchain platforms according to their own businesses, thus various heterogeneous and independent underlying blockchain platforms are born, forming many isolated 'information islands'. With the development of the application ecology, the demand for building a blockchain ecological network that embraces differences, mutual cooperation and multi-win is urgent. It has become the research focus of the current blockchain technology to realize multi-chain security, interconnection and value transfer across heterogeneous platforms. Cross-chain technology has become the key technology and core competitiveness of the current blockchain platform. However, how to realize the cross-chain process credibility is a problem that needs to be solved urgently. SUMMARY

[0003] The embodiments of the present application disclose a cross-blockchain system for executing transactions, a cross-chain transaction method and equipment, which can ensure the cross-chain process credibility.

[0004] The first aspect of the embodiments of the present application discloses a cross-blockchain system for performing a transaction, comprising a first relay, a second relay, a first node, and a second node. When a cross-chain transaction needs to be performed between a heterogeneous first blockchain and a second blockchain, the first relay sends a first instruction for indicating the execution of a first sub-transaction to the first node and sends a request for the cross-chain transaction to the second relay after obtaining the request for the cross-chain transaction. The first relay is a relay connected to the first node, the first node maintains the first blockchain, the second relay is a relay connected to the second node, the second node maintains the second blockchain, and the cross-chain transaction performed by the cross-blockchain system comprises the first sub-transaction performed on the first blockchain and the second sub-transaction performed on the second blockchain. The second relay sends a second instruction for indicating the execution of the second sub-transaction to the second node after receiving the request for the cross-chain transaction from the first relay. The first node performs the first sub-transaction and sends the execution result of the first sub-transaction to the first relay after receiving the first instruction. The second node performs the second sub-transaction and sends the execution result of the second sub-transaction to the second relay after receiving the second instruction. The second relay sends the execution result of the second sub-transaction to the first relay after receiving the execution result of the second sub-transaction. The first relay determines the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction in a trusted execution environment thereof after receiving the execution result of the first sub-transaction and the execution result of the second sub-transaction. It should be understood that the relay determines the execution result of the cross-chain transaction in the trusted execution environment, determines whether the execution result of the cross-chain transaction is trusted, and thus makes the cross-chain transaction process trusted. It should be noted that a blockchain network comprises a plurality of nodes, the plurality of nodes collectively maintain the blockchain, i.e., the blockchain network is a hardware architecture comprising the plurality of nodes, and realizes functions such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. For the first blockchain, the first node is any one of the plurality of nodes collectively maintaining the first blockchain. For the second blockchain, the second node is any one of the plurality of nodes collectively maintaining the second blockchain.

[0005] In an exemplary embodiment, the cross-chain management contract can record a keyword of a cross-chain transaction and a state of the keyword of the cross-chain transaction, and when there is a record of the keyword in the cross-chain management contract, other cross-chain transactions or ordinary transactions on the node need to be aborted or directly fail to execute; the record of the keyword includes the keyword and the state of the keyword; after receiving the first instruction, the first node first queries whether there is a record of the keyword of the cross-chain transaction in the first cross-chain management contract; if there is a record of the keyword in the first cross-chain management contract, it indicates that the first blockchain is still in the last cross-chain process, and the first node sends the first execution result of the first sub-transaction to the first relay, wherein the first execution result of the first sub-transaction indicates that the first sub-transaction fails to execute; if there is no record of the keyword, it indicates that the first blockchain is not in the cross-chain process, the first node executes the first sub-transaction to obtain the first state of the keyword, records the first state of the keyword in the first cross-chain management contract, and sends the second execution result of the first sub-transaction to the first relay. It should be understood that before executing the cross-chain transaction, it is first queried whether there is a record of the keyword of the cross-chain transaction in the first cross-chain management contract, and when there is a record of the keyword in the first cross-chain management contract, the cross-chain transaction is aborted or directly fails to execute, so that the cross-chain transaction does not interfere with the last cross-chain transaction; when there is no record of the keyword in the first cross-chain management contract, the first node executes the first sub-transaction to obtain the first state of the keyword, records the first state of the keyword in the first cross-chain management contract, and then other cross-chain transactions or ordinary transactions on the first node are aborted or directly fail to execute, so that other cross-chain transactions or ordinary transactions do not interfere with the cross-chain transaction, thereby realizing cross-chain transaction isolation.

[0006] In an exemplary embodiment, after confirming the execution result of the cross-chain transaction, the first relay sends a third instruction to the first node; if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the third instruction sent by the first relay to the first node is used to indicate that the cross-chain transaction is successful; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction sent by the first relay to the first node is used to indicate that the cross-chain transaction fails. It should be understood that whether the cross-chain transaction is successful or not, the first relay informs the first node of the success or failure of the cross-chain transaction through the third instruction, so that the first node performs corresponding operations according to different situations of the success or failure of the cross-chain transaction, so as to ensure the persistence and consistency of the cross-chain transaction.

[0007] In an exemplary embodiment, if the third instruction indicates that the cross-chain transaction is successful, the first node persists the first state of the keyword and deletes the first state of the keyword recorded in the first cross-chain management contract; if the third instruction indicates that the cross-chain transaction fails, the first node restores the state of the keyword to the state before the first sub-transaction is executed, and deletes the first state of the keyword recorded in the first cross-chain management contract. It should be understood that if the cross-chain transaction is successful, the first node persists the state of the keyword; if the cross-chain transaction fails, the first node restores the state of the keyword to the state before the cross-chain transaction, thereby achieving the persistence and consistency of the cross-chain transaction; and regardless of whether the cross-chain transaction is successful or not, the first node deletes the record of the keyword on the first cross-chain management contract, so that other cross-chain transactions or ordinary transactions on the first node will not be disturbed by this cross-chain transaction, thereby achieving the isolation of the cross-chain transaction.

[0008] In an exemplary embodiment, after receiving the second instruction, the second node first queries whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract; if the second cross-chain management contract has a record of the keyword, it means that the second blockchain is still in the last cross-chain process, and the first execution result of the second sub-transaction is sent to the second relay, wherein the first execution result of the second sub-transaction indicates that the second sub-transaction fails; if there is no record of the keyword, it means that the second blockchain is not in the cross-chain process, then the second sub-transaction is executed to obtain the second state of the keyword, and the second state of the keyword is recorded in the second cross-chain management contract, and the second execution result of the second sub-transaction is sent to the second relay. It should be understood that before executing the cross-chain transaction, it is first queried whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract, when there is a record of the keyword in the second cross-chain management contract, the cross-chain transaction is aborted or directly fails, so that the cross-chain transaction will not disturb the last cross-chain transaction; when there is no record of the keyword in the second cross-chain management contract, the second sub-transaction is executed to obtain the second state of the keyword, and the second state of the keyword is recorded in the second cross-chain management contract, and then other cross-chain transactions or ordinary transactions on the second node will be aborted or directly fail, so that other cross-chain transactions or ordinary transactions will not disturb the cross-chain transaction, thereby achieving the isolation of the cross-chain transaction.

[0009] In an example implementation, the first relay sends a third instruction to the second relay after confirming the execution result of the cross-chain transaction; the second relay forwards the third instruction to the second node after receiving the third instruction; if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the third instruction sent by the first relay is used to indicate that the cross-chain transaction is successful; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction sent by the first relay is used to indicate that the cross-chain transaction fails. It should be understood that whether the cross-chain transaction is successful or not, the first relay informs the second node of the success or failure of the cross-chain transaction through the third instruction, so that the second node performs corresponding operations according to different situations of the success or failure of the cross-chain transaction, so as to ensure the persistence and consistency of the cross-chain transaction. It should be noted that the second relay performs data format conversion on the third instruction after receiving the third instruction from the first relay, converts the third instruction into a data format that can be recognized by the second node, and then forwards the third instruction after data format conversion to the second node.

[0010] In an example implementation, the first relay signs the third instruction using the private key of the first relay in the trusted execution environment of the first relay to obtain fifth signature data; and sends the fifth signature data to the second relay. It should be understood that since the third instruction is signed by the first relay, it is beneficial for the second relay to determine whether the third instruction is trusted, thereby ensuring that the cross-chain process is trusted.

[0011] In an example implementation, the second relay has a third root certificate, and after receiving the fifth signature data containing the third instruction and the identity certificate of the first relay, the second relay verifies the identity certificate of the first relay using the third root certificate in the trusted execution environment of the second relay, extracts the public key of the first relay from the identity certificate of the first relay after verification, and verifies the fifth signature data using the public key of the first relay to determine whether the third instruction is trusted, and then forwards the third instruction to the second node, which is beneficial to ensure that the cross-chain process is trusted. In addition, whether the cross-chain transaction is successful or not, the first relay informs the second node of the success or failure of the cross-chain transaction through the second relay through the third instruction, so that the second node performs corresponding operations according to different situations of the success or failure of the cross-chain transaction, so as to ensure the persistence and consistency of the cross-chain transaction.

[0012] In an exemplary embodiment, if the third instruction indicates that the cross-chain transaction is successful, the second node persists the second state of the keyword, and deletes the second state of the keyword recorded in the second cross-chain management contract; if the third instruction indicates that the cross-chain transaction fails, the second node restores the state of the keyword to the state before the second sub-transaction is executed, and deletes the second state of the keyword recorded in the second cross-chain management contract. It should be understood that, if the cross-chain transaction is successful, the second node persists the state of the keyword; if the cross-chain transaction fails, the second node restores the state of the keyword to the state before the cross-chain transaction, thereby realizing the persistence and consistency of the cross-chain transaction; and regardless of whether the cross-chain transaction is successful or not, the second node deletes the record of the keyword on the second cross-chain management contract, so that other cross-chain transactions or ordinary transactions on the second node will not be disturbed by this cross-chain transaction, thereby realizing the isolation of the cross-chain transaction.

[0013] In an exemplary embodiment, the first relay, in the trusted execution environment thereof, signs the request of the cross-chain transaction by using the private key of the first relay to obtain first signature data, and then sends the first signature data and the identity certificate of the first relay to the second relay, so as to facilitate the second relay to verify the first signature data by using the identity certificate of the first relay to determine that the request of the cross-chain transaction is trusted, and to facilitate the second relay to instruct the second node to execute the corresponding cross-chain instruction according to the request of the cross-chain transaction, thereby ensuring that the cross-chain process is trusted.

[0014] In an exemplary embodiment, the second relay has a third root certificate, and after receiving the first signature data containing the request of the cross-chain transaction and the identity certificate of the first relay, the second relay, in the trusted execution environment thereof, verifies the identity certificate of the first relay by using the third root certificate, extracts the public key of the first relay from the identity certificate of the first relay after the verification is passed, and verifies the first signature data by using the public key of the first relay to determine whether the request of the cross-chain transaction is trusted, and facilitates the second relay to instruct the second node to execute the corresponding cross-chain instruction according to the request of the cross-chain transaction, thereby ensuring that the cross-chain process is trusted.

[0015] In an exemplary embodiment, when sending the execution result of the first sub-transaction to the first relay, the first node signs the execution result of the first sub-transaction by using the private key of the first node to obtain second signature data, and then sends the second signature data and the identity certificate of the first node to the first relay, so that the first relay verifies the second signature data by using the identity certificate of the first node, so that the first relay determines whether the execution result of the first sub-transaction is trusted, thereby ensuring that the cross-chain transaction is trusted.

[0016] In an exemplary embodiment, the first relay holds a first root certificate of the first node (i.e. the first blockchain), and after receiving the second signed data containing the execution result of the first sub-transaction and the identity certificate of the first node, the first relay verifies the identity certificate of the first node using the first root certificate in the trusted execution environment of the first relay, and after verification, extracts the public key of the first node from the identity certificate of the first node, and verifies the second signed data using the public key of the first node to determine whether the execution result of the first sub-transaction is trustworthy, thereby ensuring that the cross-chain transaction is trustworthy.

[0017] In an exemplary embodiment, the first relay verifies the execution result of the first sub-transaction in the trusted execution environment of the first relay to determine whether the first sub-transaction is executed correctly. Specifically, the trusted execution environment of the first relay holds a preset transaction verification policy, which can be used to verify the execution result of the first sub-transaction to determine whether the first sub-transaction is executed correctly. Thus, it can be ensured that the first node (i.e. the first blockchain) honestly uses correct cross-chain sub-transaction parameters to call the function of the correct smart contract, preventing the first node (i.e. the first blockchain) from being malicious or data being maliciously tampered with, and ensuring that the cross-chain process is trustworthy.

[0018] In an exemplary embodiment, the second node signs the execution result of the second sub-transaction using the private key of the second node to obtain third signed data when sending the execution result of the second sub-transaction to the second relay, and then sends the third signed data and the identity certificate of the second node to the second relay, so that the second relay verifies the third signed data using the identity certificate of the second node, and determines whether the execution result of the second sub-transaction is trustworthy, thereby ensuring that the cross-chain transaction is trustworthy.

[0019] In an exemplary embodiment, the second relay holds a second root certificate, and after receiving the third signed data and the identity certificate of the second node from the second node, the second relay verifies the identity certificate of the second node using the second root certificate in the trusted execution environment of the second relay, and after verification, extracts the public key of the second node from the identity certificate of the second node, and verifies the third signed data using the public key of the second node to determine whether the execution result of the second sub-transaction is trustworthy, thereby ensuring that the cross-chain transaction is trustworthy.

[0020] In an exemplary embodiment, the second relay verifies the execution result of the second sub-transaction in the trusted execution environment of the second relay to determine whether the second sub-transaction is executed correctly. Specifically, the trusted execution environment of the second relay holds a preset transaction verification policy, which can be used to verify the execution result of the second sub-transaction to determine whether the second sub-transaction is executed correctly.

[0021] In an exemplary embodiment, the second relay, in its trusted execution environment, signs the execution result of the second sub-transaction with the private key of the second relay to obtain fourth signature data; and then sends the fourth signature data to the first relay. Since the execution result of the second sub-transaction is signed, it is beneficial for the first relay to determine whether it is trusted. It should be understood that the second relay will perform data format conversion on the execution result of the second sub-transaction after determining whether the execution result of the second sub-transaction is trusted, and convert it into a data format that the first relay can recognize, and then forward the execution result of the second sub-transaction after data format conversion to the first relay.

[0022] In an exemplary embodiment, the first relay has a third root certificate. After the first relay receives the fourth signature data and the identity certificate of the second relay, the first relay, in its trusted execution environment, verifies the identity certificate of the second relay with the third root certificate, extracts the public key of the second relay from the identity certificate of the second relay after verification, and verifies the fourth signature data with the public key of the second relay to determine whether the execution result of the second sub-transaction is trusted. As a possible implementation, the first relay can also further verify the execution result of the second sub-transaction with the preset transaction verification strategy after receiving the execution result of the second sub-transaction from the second relay.

[0023] In an exemplary embodiment, the first relay is configured to: if the execution result of the first sub-transaction indicates that the first sub-transaction is executed successfully and the execution result of the second sub-transaction indicates that the second sub-transaction is executed successfully, determine that the cross-chain transaction is successful; otherwise, determine that the cross-chain transaction fails. It should be understood that if the execution result of the first sub-transaction indicates that the first sub-transaction is executed successfully and the execution result of the second sub-transaction indicates that the second sub-transaction is executed successfully, the first relay determines that the cross-chain transaction is successful; otherwise, the first relay determines that the cross-chain transaction fails, thereby ensuring the atomicity of the cross-chain transaction.

[0024] The second aspect of the embodiments of the present application discloses a cross-chain transaction method applied to a first relay device with a trusted execution environment, the first relay device corresponding to a first blockchain, and the method comprises the following steps: the first relay device sends a first instruction for indicating execution of a first sub-transaction to a first node, and sends a request for a cross-chain transaction to a second relay device, wherein the first node maintains the first blockchain, the second relay device corresponds to a second blockchain, the cross-chain transaction comprises the first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain; the first relay device receives an execution result of the first sub-transaction from the first node, and receives an execution result of the second sub-transaction from the second relay device; after receiving the execution result of the first sub-transaction and the execution result of the second sub-transaction, the first relay device determines an execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction in the trusted execution environment of the first relay device. It should be understood that, since the first relay device has the trusted execution environment, the first relay device determines whether the execution result of the cross-chain transaction is trusted in the trusted execution environment, so that the cross-chain transaction process is trusted. In addition, the first relay device corresponds to the first blockchain, which means that the blockchain network where the first blockchain is located comprises a plurality of nodes, and the first relay device is a relay device connected to any one of the plurality of nodes; the second relay device corresponds to the second blockchain, which means that the blockchain network where the second blockchain is located comprises another plurality of nodes, and the second relay device is a relay device connected to any one of the another plurality of nodes. When the first blockchain and the heterogeneous second blockchain perform cross-chain transaction, the first relay device and the second relay device can implement cross-chain as a relay platform, wherein cross-chain data is sent to the relay platform, the relay platform performs data analysis and conversion into a message format recognizable by the blockchain, and then sends the cross-chain instruction and data to the blockchain for processing.

[0025] In an exemplary embodiment, the method further comprises: the first relay device sends a third instruction to the first node based on the execution result of the cross-chain transaction; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the third instruction is used to indicate that the cross-chain transaction is successful; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails. It should be understood that, regardless of whether the cross-chain transaction is successful or not, the first relay device informs the first node of whether the cross-chain transaction is successful or not through the third instruction, so that the first node performs corresponding operations according to different situations of whether the cross-chain transaction is successful or not, so as to ensure the persistence and consistency of the cross-chain transaction.

[0026] In an example implementation, sending the request for cross-chain transaction to the second relay includes: signing the request for cross-chain transaction with a private key of the first relay to obtain first signature data in a trusted execution environment of the first relay; and sending the first signature data to the second relay. It should be understood that since the request for cross-chain transaction sent by the first relay to the second relay is signed with data in the trusted execution environment of the first relay, the second relay can verify the first signature data to ensure that the request for cross-chain transaction is trusted, so as to ensure that the cross-chain process is trusted. Further, the first relay can send the first signature data and the identity certificate of the first relay to the second relay, so that the second relay can verify the first signature data with the identity certificate of the first relay to determine that the request for cross-chain transaction is trusted, which is conducive to the second relay to instruct the second node to execute the corresponding cross-chain instruction according to the request for cross-chain transaction, so as to further ensure that the cross-chain process is trusted.

[0027] In an example implementation, the first relay stores a first root certificate, the execution result of the first sub-transaction is carried in the second signature data, and after receiving the second signature data and the identity certificate of the first node, the first relay verifies the identity certificate of the first node with the first root certificate in a trusted execution environment of the first relay, extracts the public key of the first node from the identity certificate of the first node after verification, and verifies the second signature data with the public key of the first node to determine whether the execution result of the first sub-transaction indicated by the second signature data is trusted. It should be understood that the first relay stores the first root certificate of the first node (i.e., the first blockchain), and after receiving the second signature data containing the execution result of the first sub-transaction and the identity certificate of the first node, the first relay verifies the identity certificate of the first node with the first root certificate in a trusted execution environment of the first relay, extracts the public key of the first node from the identity certificate of the first node after verification, and verifies the second signature data with the public key of the first node to determine whether the execution result of the first sub-transaction is trusted, so as to ensure that the cross-chain transaction is trusted. It should be noted that the first relay receiving the second signature data and receiving the identity certificate of the first node can be one action or two actions. For example, a message carries the second signature data and the identity certificate of the first node at the same time, the first node sends the message to the first relay, and the first relay receives the message, i.e., receives the second signature data and the identity certificate of the first node. Alternatively, the first node sends the second signature data and the identity certificate of the first node to the first relay through two messages respectively. The present application does not make a specific limitation in this regard.

[0028] In an example implementation, after receiving the execution result of the first sub-transaction from the first node, the method further comprises: determining, in the trusted execution environment of the first relay, whether the first sub-transaction is executed correctly based on the execution result of the first sub-transaction. It should be understood that the first relay verifies the execution result of the first sub-transaction in its trusted execution environment, so that it can be ensured that the first node (i.e., the first blockchain) honestly invokes the function of the correct smart contract with the correct cross-chain sub-transaction parameters, prevents the first node (i.e., the first blockchain) from being malicious or data being maliciously tampered with, and ensures that the cross-chain process is trustworthy.

[0029] In an example implementation, the first relay has a third root certificate, the execution result of the second sub-transaction is carried in fourth signature data, and after receiving the fourth signature data and the identity certificate of the second relay from the second relay, the identity certificate of the second relay is verified using the third root certificate in the trusted execution environment of the first relay, the public key of the second relay is extracted from the identity certificate of the second relay after verification, and the fourth signature data is verified using the public key of the second relay to determine whether the execution result of the second sub-transaction indicated by the fourth signature data is trustworthy. It should be understood that the first relay has a third root certificate of the second relay, and after the first relay receives the fourth signature data containing the execution result of the second sub-transaction and the identity certificate of the second relay, the identity certificate of the second relay is verified using the third root certificate in the trusted execution environment of the first relay, and the public key of the second relay is extracted from the identity certificate of the second relay after verification, and the fourth signature data is verified using the public key of the second relay to determine whether the execution result of the second sub-transaction is trustworthy, so as to ensure that the cross-chain transaction is trustworthy. It should be noted that the first relay receiving the fourth signature data and receiving the identity certificate of the second relay can be one action or two actions. For example, a message carries the fourth signature data and the identity certificate of the second relay, the second relay sends the message to the first relay, the first relay receives the message, i.e., receives the fourth signature data and the identity certificate of the second relay; or the second relay sends the fourth signature data and the identity certificate of the second relay to the first relay through two messages; the present application does not make a specific limitation thereon.

[0030] In a third aspect, the embodiments of the present application disclose a cross-chain transaction method applied to a node A, wherein the node A maintains a blockchain A, and the node A comprises a cross-chain management contract A, which can record a keyword and a state of the keyword; when the keyword record exists in the cross-chain management contract A, other cross-chain transactions or normal transactions on the node A need to be aborted or directly failed; after receiving an instruction for indicating execution of a sub-transaction A from a relay A or a node C, the node A first queries whether the keyword record of the cross-chain transaction exists in the cross-chain management contract A; if the keyword record exists in the cross-chain management contract A, it indicates that the blockchain A is still in the last cross-chain process, and the node A sends a first execution result of the sub-transaction A to the relay A or the node C, wherein the first execution result of the sub-transaction A indicates that the sub-transaction A is failed; if the keyword record does not exist, it indicates that the blockchain A is not in the cross-chain process, and the node A executes the sub-transaction A to obtain a state A of the keyword, records the state A of the keyword in the cross-chain management contract A, and sends a second execution result of the sub-transaction A to the relay A or the node C. It should be understood that before the cross-chain transaction is executed, it is first queried whether the keyword record of the cross-chain transaction exists in the cross-chain management contract A, when the keyword record exists in the cross-chain management contract A, the cross-chain transaction is aborted or directly failed, so that the cross-chain transaction does not interfere with the last cross-chain transaction; when the keyword record does not exist in the cross-chain management contract A, the sub-transaction A is executed to obtain the state A of the keyword, and the state A of the keyword is recorded in the cross-chain management contract A, and then other cross-chain transactions or normal transactions on the node A are aborted or directly failed, so that other cross-chain transactions or normal transactions do not interfere with the cross-chain transaction, thereby realizing cross-chain transaction isolation.

[0031] In an exemplary embodiment, the node A receives a third instruction from the relay A or the node C; if the third instruction indicates that the cross-chain transaction is successful, the state A of the keyword is persisted, and the state A of the keyword recorded in the cross-chain management contract A is deleted; if the third instruction indicates that the cross-chain transaction is failed, the state of the keyword recorded in the node A is restored to the state before the sub-transaction A is executed according to the state A of the keyword recorded in the cross-chain management contract A, and the state A of the keyword recorded in the cross-chain management contract A is deleted. It should be understood that when the cross-chain transaction is successful, the node A persists the state of the keyword; when the cross-chain transaction is failed, the node A restores the state of the keyword to the state before the cross-chain transaction, thereby realizing the persistence and consistency of the cross-chain transaction; and no matter whether the cross-chain transaction is successful or not, the node A deletes the keyword record on the cross-chain management contract A, so that other cross-chain transactions or normal transactions after the cross-chain transaction are not interfered by the cross-chain transaction, thereby realizing the isolation of the cross-chain transaction.

[0032] The fourth aspect of the embodiment of the application discloses a cross-chain transaction device applied to a first relay with a trusted execution environment, the first relay corresponding to a first block chain, the device comprising: a sending unit configured to send a first instruction for indicating execution of a first sub-transaction to a first node, and send a request for a cross-chain transaction to a second relay, wherein the first node maintains the first block chain, the second relay corresponds to a second block chain, the cross-chain transaction comprising the first sub-transaction executed on the first block chain and a second sub-transaction executed on the second block chain; a receiving unit configured to receive an execution result of the first sub-transaction from the first node, and receive an execution result of the second sub-transaction from the second relay; and a determining unit configured to determine an execution result of the cross-chain transaction based on the execution result of the first sub-transaction and the execution result of the second sub-transaction in the trusted execution environment of the first relay.

[0033] In an exemplary embodiment, the sending unit is further configured to send a third instruction to the first node based on the execution result of the cross-chain transaction, wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the third instruction is used to indicate that the cross-chain transaction is successful, and if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

[0034] In an exemplary embodiment, the sending unit is configured to, in the trusted execution environment of the first relay, sign the request for the cross-chain transaction by using a private key of the first relay to obtain first signature data, and send the first signature data to the second relay.

[0035] In an exemplary embodiment, the first relay stores a first root certificate, and the execution result of the first sub-transaction is carried in second signature data, and the receiving unit is further configured to receive an identity certificate of the first node from the first node, verify the identity certificate of the first node by using the first root certificate in the trusted execution environment of the first relay, and extract a public key of the first node from the identity certificate of the first node after verification, and verify the second signature data by using the public key of the first node to determine whether the execution result of the first sub-transaction indicated by the second signature data is trusted.

[0036] In an exemplary embodiment, the determining unit is further configured to determine whether the first sub-transaction is executed correctly based on the execution result of the first sub-transaction in the trusted execution environment of the first relay.

[0037] In an example implementation, the first relay holds a third root certificate, the execution result of the second sub-transaction is carried in fourth signature data, and the receiving unit is further configured to receive the fourth signature data and an identity certificate of the second relay from the second relay, verify the identity certificate of the second relay using the third root certificate in the trusted execution environment of the first relay, extract the public key of the second relay from the identity certificate of the second relay after verification, and verify the fourth signature data using the public key of the second relay to determine whether the execution result of the second sub-transaction indicated by the fourth signature data is trusted.

[0038] In a fifth aspect, the present application discloses a cross-chain transaction device applied to a node A, the node A maintaining a blockchain A, and the node A including a cross-chain management contract A, the device including: a receiving unit configured to receive an instruction from a relay A or a node C, the instruction being used to indicate execution of a sub-transaction A, the sub-transaction A being a sub-transaction executed by the blockchain A when the blockchain A and a blockchain B perform cross-chain transaction; the relay A being a relay connected to the node A; the node C being a consensus node on a blockchain C, the blockchain C being a relay chain of the blockchain A and the blockchain B; a querying unit configured to query, in the cross-chain management contract A, whether there is a record of a keyword of cross-chain transaction; and a sending unit configured to send, if there is the record of the keyword, a first execution result of the sub-transaction A to the relay A or the node C, the first execution result of the sub-transaction A indicating that the sub-transaction A fails to execute; and the sending unit is further configured to execute the sub-transaction A to obtain a state A of the keyword, record the state A of the keyword in the cross-chain management contract A, and send a second execution result of the sub-transaction A to the relay A or the node C, if there is no record of the keyword.

[0039] In an example implementation, the receiving unit is further configured to receive a third instruction from the relay A or the node C, persist the state A of the keyword, and delete the record of the state A of the keyword in the cross-chain management contract A if the third instruction indicates that the cross-chain transaction succeeds, and restore the state of the keyword to a state before the sub-transaction A is executed and delete the record of the state A of the keyword in the cross-chain management contract A if the third instruction indicates that the cross-chain transaction fails.

[0040] It can be understood that, since the method embodiment and the device embodiment are different presentation forms of the same technical concept, the content of the second aspect of the present application embodiment should be synchronously adapted to the fourth aspect of the present application embodiment, and the content of the third aspect of the present application embodiment should be synchronously adapted to the fifth aspect of the present application embodiment, which will not be described here.

[0041] The sixth aspect of the embodiments of the present application discloses a first relay device with a trusted execution environment, comprising a processor, a memory, a communication interface, and one or more programs, the one or more programs are stored in the memory and configured to be executed by the processor, and the programs comprise instructions for performing the steps in the method of any one of the second aspect.

[0042] The seventh aspect of the embodiments of the present application discloses a node A, comprising a processor, a memory, a communication interface, and one or more programs, the one or more programs are stored in the memory and configured to be executed by the processor, and the programs comprise instructions for performing the steps in the method of any one of the third aspect.

[0043] The eighth aspect of the embodiments of the present application discloses a chip, characterized in that comprising: a processor, configured to call and run a computer program from a memory, so that a device installed with the chip executes the method of any one of the second aspect or the third aspect.

[0044] The ninth aspect of the embodiments of the present application discloses a computer readable storage medium, which stores a computer program for electronic data exchange, wherein the computer program causes a computer to execute the method of any one of the second aspect or the third aspect.

[0045] The tenth aspect of the embodiments of the present application discloses a computer program product, which causes a computer to execute the method of any one of the second aspect or the third aspect. BRIEF DESCRIPTION OF DRAWINGS

[0046] The drawings used in the embodiments of the present application are introduced as follows.

[0047] Figure 1 is a flowchart of a process for cross-chain implementation using a hash time lock provided by the embodiments of the present application;

[0048] Figure 2 is a topological diagram of a relay chain provided by the embodiments of the present application;

[0049] Figure 3 is a schematic diagram of a non-trusted cross-chain transaction of a relay platform provided by the embodiments of the present application;

[0050] Figure 4 is a schematic diagram of cross-chain transaction isolation provided by the embodiments of the present application;

[0051] Figure 5 is an architectural schematic diagram of a cross-blockchain system for executing transactions provided by the embodiments of the present application;

[0052] Figure 6is a cross-chain processing flow schematic diagram inside a repeater provided by an embodiment of the present application;

[0053] Figure 7 is another architecture schematic diagram of a cross-blockchain transaction execution system provided by an embodiment of the present application;

[0054] Figure 8 is a cross-chain transaction method flow schematic diagram provided by an embodiment of the present application;

[0055] Figure 9 is a whole step schematic diagram of a cross-chain transaction method provided by an embodiment of the present application;

[0056] Figure 10 is another whole step schematic diagram of a cross-chain transaction method provided by an embodiment of the present application;

[0057] Figure 11 is another architecture schematic diagram of a cross-blockchain transaction execution system provided by an embodiment of the present application;

[0058] Figure 12 is another cross-chain transaction method flow schematic diagram provided by an embodiment of the present application;

[0059] Figure 13 is another whole step schematic diagram of a cross-chain transaction method provided by an embodiment of the present application;

[0060] Figure 14 is another architecture schematic diagram of a cross-blockchain transaction execution system provided by an embodiment of the present application;

[0061] Figure 15 is another cross-chain transaction method flow schematic diagram provided by an embodiment of the present application;

[0062] Figure 16 is another whole step schematic diagram of a cross-chain transaction method provided by an embodiment of the present application;

[0063] Figure 17 is another cross-chain transaction method flow schematic diagram provided by an embodiment of the present application;

[0064] Figure 18 is a cross-chain transaction device structure schematic diagram provided by an embodiment of the present application;

[0065] Figure 19 is another cross-chain transaction device structure schematic diagram provided by an embodiment of the present application;

[0066] Figure 20 is a first repeater structure schematic diagram provided by an embodiment of the present application;

[0067] Figure 21 is a structural schematic diagram of a node A provided by an embodiment of the present application. DETAILED DESCRIPTION

[0068] The embodiments of the present application are described below with reference to the accompanying drawings.

[0069] First, some terms in the present application are explained to facilitate understanding by those skilled in the art.

[0070] (1) Rich Execution Environment (REE): It is the execution environment of the operating system and various applications above it, and various information runs in the interconnected network world.

[0071] (2) Trusted Execution Environment (TEE): It is implemented based on the TrustZone technology of ARM. This technology divides a secure area on the main processor of a mobile device (including smartphones, tablets, set-top boxes, smart TVs, etc.), which can guarantee the security, confidentiality and integrity of the code and data loaded into the environment. The execution space provided by TEE has a higher level of security than the execution space provided by common mobile operating systems (such as Linux, Android, etc.). The trusted execution environment described in the present application includes but is not limited to ARM TrustZone and Intel SGX.

[0072] (3) Blockchain: A block record concatenated and protected by cryptography, where each block contains the hash value of the previous block, a timestamp and transaction data. A distributed ledger implemented using blockchain technology can effectively record transactions between two or more parties, and the transactions cannot be forged and are permanently verifiable.

[0073] (4) Cross-chain: A process that converts assets originally stored on a certain blockchain into assets on another chain, thereby realizing the circulation of value. In a broad sense, cross-chain is not limited to asset conversion. Any operation that coordinates multiple chains and has an impact on multiple chains can be considered cross-chain. The cross-chain process of the present solution also refers to the broad concept.

[0074] (5) Cross-chain transaction: A transaction that requires multiple sub-transactions on multiple blockchains to be jointly effective. The cross-chain transaction corresponds to multiple sub-transactions on multiple blockchains that are successful or failed at the same time. Cross-chain needs to be implemented through the execution of cross-chain transactions, that is, the cross-chain function needs to be implemented through the execution of cross-chain transactions.

[0075] (6) Sidechain: Not specifically referring to a certain blockchain, but rather all blockchains that comply with the sidechain protocol. This term is used in contrast to the main chain.

[0076] (7) Sidechain protocol: A protocol that allows digital assets to be securely transferred from the main chain to other blockchains and vice versa.

[0077] (8) Relay: A device that connects two networks by retransmitting or forwarding data signals. In cross-chain, the relay can convert data sent by one blockchain into a data structure recognizable by other chains and send cross-chain instructions to the blockchain by calling the API of the blockchain, coordinating all blockchains involved in cross-chain transactions.

[0078] (9) Relay chain: A blockchain with the same function as a relay, used to connect multiple blockchains.

[0079] Secondly, analyze and propose the technical problems to be solved in this application. The purpose of cross-chain is to establish a channel for asset value and information data transmission. The main difficulties of current cross-chain technology are as follows:

[0080] (1) Interoperability between heterogeneous platforms

[0081] With the development and application of blockchain technology, the future blockchain ecosystem will inevitably be a multi-chain coexistence and interconnected ecosystem. Interconnection is not only between multiple chains on the same blockchain platform, but also across heterogeneous platforms to achieve interconnection between multiple chains on different blockchain platforms. How to design a universal cross-chain platform mechanism that allows other heterogeneous blockchain platforms to modify the underlying technology as little as possible to facilitate, fast, and secure access to the cross-chain platform is the first problem to be solved in cross-chain technology.

[0082] (2) Cross-chain transaction management

[0083] A complete cross-chain transaction includes several sub-transactions on several participating blockchain systems, and each sub-transaction is processed in its respective blockchain system. All cross-chain sub-transactions constitute a cross-chain transaction, which needs to be managed by the cross-chain platform to ensure the four characteristics of transaction management (ACID): atomicity, consistency, isolation, and durability. Cross-chain transaction atomicity and consistency mean that all cross-chain sub-transactions in a cross-chain request need to be successful or failed, with no other intermediate state; cross-chain transaction isolation ensures that cross-chain transactions do not affect each other and other ordinary transactions; cross-chain transaction durability means that once the cross-chain transaction is completed, each blockchain needs to persist the relevant transactions and state.

[0084] (3) Cross-chain security guarantee

[0085] The cross-chain platform establishes a connection channel between heterogeneous blockchain systems, needs to perform data analysis and assembly, can verify the transaction status of cross-chain sub-transactions on each heterogeneous platform, and determines the next cross-chain action according to the status of each sub-transaction. Therefore, it is very important to ensure the security and credibility of the cross-chain platform. If the cross-chain platform is attacked and imitated, the entire cross-chain process is invalid, and even a fatal attack on each blockchain platform.

[0086] In order to facilitate understanding of the embodiments of the present application, further analysis and the technical problems to be solved by the present application are proposed. In the prior art, regarding the heterogeneous blockchain cross-chain technology, there are various technical solutions, and the following exemplary commonly used solution is listed as follows.

[0087] Solution one: notary mechanism

[0088] The notary mechanism is to introduce a trusted third party as a notary. The notary continuously collects data on each blockchain and also performs transaction confirmation and verification. Since blockchain 1 and blockchain 2 cannot trust each other, a third party trusted by blockchain 1 and blockchain 2 is introduced as a notary as an intermediary to realize indirect trust between blockchain 1 and blockchain 2. The notary mechanism is a relatively simple one in cross-chain technology, belongs to a two-way cross-chain, and can realize cross-chain asset exchange and transfer, and is easy to operate.

[0089] The notary mechanism is used to realize the cross-chain process. This solution is a relatively simple one in cross-chain technology, but its disadvantage is that centralization is easy to occur. If the notary is tampered with or imitated, each participant in the cross-chain can arbitrarily operate the cross-chain, because each blockchain participating in the cross-chain fully trusts the notary.

[0090] Solution two: hash time lock

[0091] The hash time lock is used to realize the cross-chain process. The principle of the hash lock technology is as follows: blockchain 1 and blockchain 2 reach an agreement to lock 1 asset 1. Before time T arrives, if blockchain 2 can show the correct R to blockchain 1, so that the hash value of R is equal to the value Hash(R) agreed in advance, blockchain 2 can obtain the 1 asset 1. If after time T, blockchain 2 still cannot provide the correct R, then the 1 asset 1 will be unlocked and returned to blockchain 1.

[0092] Please refer to Figure 1 , Figure 1 is a process diagram for realizing cross-chain using hash time lock, which is a process of using 1 asset 1 of blockchain 1 to exchange 1000 assets 2 of blockchain 2:

[0093] (1) Blockchain 1 locks its 1 asset 1 using a hash time lock, and tells Blockchain 2 the hash value H, and Blockchain 2 locks 1000 assets 2 in a smart contract, which claims that whoever can provide R such that Hash(R) = H can obtain the 1000 assets 2.

[0094] (2) Blockchain 1 provides R to Blockchain 2, since it is easy to calculate the hash value H from R, but difficult to reverse R from the hash value H, so it is difficult for others to provide the correct R to Blockchain 2 earlier than Blockchain 1, and thus Blockchain 1 can obtain the 1000 assets 2.

[0095] (3) After Blockchain 2 provides the correct R, it can also obtain the 1 asset 1 from Blockchain 1, and thus the asset transfer process between Blockchain 1 and Blockchain 2 is completed.

[0096] Hash time lock is suitable for scenarios where both parties exchange assets, and both parties are driven by the value of interest, and may need to wait for a long confirmation period to unlock the corresponding currency on the chain; secondly, the hash time lock scheme is not suitable for asset transfer, such as one-way transfer from a node on Blockchain 1 to a node on Blockchain 2, which limits its application scenarios.

[0097] Scheme three: side chain / relay

[0098] Compared with the notary mechanism, the side chain / relay is more flexible, only acting as a data collector, and the target chain verifies the data itself to complete the transaction confirmation. Side chain technology is to start another blockchain to transfer assets from the main chain to the side chain, and vice versa. The main chain and the side chain generate cross-chain transactions. If the side chain connects two or more blockchains, it is called a relay chain, and COSMOS is a typical relay chain, whose topology is shown in Figure 2 ; wherein the hub connects other blockchains zone as a relay chain. The relay adopts a central radiation design and does not belong to a certain main chain, but rather a dispatch center responsible for data transmission. Both side chain and relay methods collect information from the original chain to establish a cross-chain operation layer to process cross-chain transactions, in order to avoid excessive technical limitations of the original chain.

[0099] Side chain / relay is also a commonly used method, which needs to ensure the security and credibility of the relay to ensure the credibility of the cross-chain process; secondly, it needs to ensure the atomicity and isolation of cross-chain transactions. There is a way to use a relay chain to record the state of cross-chain transactions on the blockchain to prevent cross-chain transactions from being tampered with. This method needs to design the relay platform as a blockchain and implement a consensus mechanism to ensure the credibility of cross-chain instructions, which has a complex business process and low efficiency. Cross-chain technology solutions should modify the kernel code of heterogeneous blockchain systems as little as possible to reduce the complexity of access.

[0100] In view of the above description and deficiencies of the prior art, the application adopts a relay mode to design a cross-chain process, realizes interconnection and intercommunication between heterogeneous blockchain networks, and mainly solves the following technical problems:

[0101] (1) Cross-chain process credibility problem

[0102] The cross-chain is realized by using a relay mode, in which cross-chain data is sent to a relay platform, the relay platform analyzes and converts the data into a message format recognizable by a blockchain, and then sends the cross-chain instruction and data to the blockchain for processing. The relay platform is a key part of the cross-chain process, and the cross-chain action instruction is determined by the relay platform and sent to each blockchain, so it is crucial to ensure the credibility and security of the relay.

[0103] Please refer to Figure 3 , Figure 3 is a non-trustworthy cross-chain transaction schematic diagram of a relay platform provided by an embodiment of the application. Consider the following scenario: node 1 on blockchain 1 makes a transfer to node 2 on blockchain 2. If the sub-transaction on node 2 fails, the cross-chain transaction should also fail. However, if the relay platform is maliciously attacked, the relay platform still initiates a persistent instruction to node 1, and the asset of node 1 is reduced to 90, and the asset balance of node 2 is not increased. This is unacceptable in a real-world scenario.

[0104] (2) Cross-chain transaction isolation problem

[0105] If a cross-chain transaction performs a write operation on a certain key, and before the cross-chain transaction is completed and the modification of the key is not persistent, another ordinary transaction or cross-chain transaction needs to perform a read or write operation on the key. Taking the above-mentioned Figure 3 transfer scenario as an example:

[0106] Please refer to Figure 4 , Figure 4 is a schematic diagram of cross-chain transaction isolation provided by an embodiment of the application. Blockchain 2 receives a cross-chain transaction instruction, needs to increase the asset of node 2 by 10, and at the same time, there is another transaction that reduces the asset of node 2 by 10. At this time, the other transaction cannot be directly executed and should be waited or directly failed.

[0107] (3) Cross-chain transaction atomicity problem

[0108] Cross-chain transactions usually involve cross-chain sub-transactions on each participating blockchain. The cross-chain technology needs to ensure that these cross-chain sub-transactions are successful or failed at the same time. As long as one cross-chain sub-transaction fails, the cross-chain transaction fails, and all chains should be restored to the state before the cross-chain, that is, the cross-chain transaction atomicity is guaranteed.

[0109] In combination with the above problems, the technical scheme provided by the present application is mainly as follows:

[0110] (1) Based on the trusted execution environment, the identity of the relay is trusted and the cross-chain process is trusted.

[0111] The present application uses the trusted execution environment for cross-chain process trusted processing, and the cross-chain data analysis and instruction distribution are carried out in the trusted execution environment of the relay, thereby preventing the cross-chain transaction state from being maliciously tampered with. Secondly, the identity certificate, root certificate (Root CA) and private key of the relay are stored in the form of private data ciphertext, and can only be decrypted and obtained inside the trusted hardware. Specifically, the relay is loaded with a trusted execution environment, the identity certificate, root certificate and private key of the relay are encrypted and stored in the rich execution environment, and can only be decrypted in the trusted execution environment, thereby ensuring that the identity of the relay cannot be faked. The trusted execution environment of the relay is preloaded with a transaction verification strategy for verifying the execution result of the cross-chain sub-transaction. The cross-chain transaction state is encrypted and stored in the rich execution environment, and can only be decrypted in the trusted execution environment. After the plaintext of the cross-chain transaction state is decrypted, the next cross-chain instruction is sent to the rich execution environment according to the processing result.

[0112] (2) By deploying a cross-chain management contract, transaction isolation is realized to ensure transaction atomicity.

[0113] When the cross-chain transaction is executed, the key related to the cross-chain transaction needs to be locked, and subsequent other ordinary transactions or cross-chain transactions related to the key should be aware that the key is in the cross-chain process, and then the current transaction should be waiting or failed, that is, the problem of transaction isolation needs to be solved. Specifically, the state of the key is recorded in the cross-chain management contract, and when other cross-chain transactions or ordinary transactions call the user business contract on the blockchain, the user business contract will first call the cross-chain management contract to query the state of the related key to determine whether the key is currently in the cross-chain process. If the key is currently in the cross-chain process, other ordinary transactions or cross-chain transactions related to the key cannot be directly executed and should be waiting or directly failed. When the cross-chain transaction ends, the state of the key in the cross-chain management contract is deleted, so that other ordinary transactions or cross-chain transactions related to the key can be executed, realizing transaction isolation.

[0114] After the relay receives the results of each cross-chain sub-transaction, the cross-chain transaction result is determined according to the cross-chain sub-transaction result. Specifically, if a sub-transaction fails, the cross-chain transaction is determined to fail, and a final confirmation transaction is initiated to each participating blockchain to ensure transaction atomicity.

[0115] The technical scheme provided by the present application will be described in detail in combination with the specific embodiments.

[0116] Please refer to Figure 5 ,Figure 5 is a schematic diagram of an architecture of a cross-blockchain system for performing a transaction provided by an embodiment of the present application. Figure 5 The cross-blockchain system for performing a transaction shown includes a first relay, a second relay, a first node, and a second node; wherein the first node maintains a first blockchain, the second node maintains a second blockchain, and a cross-chain transaction performed by the cross-blockchain system includes a first sub-transaction performed on the first blockchain and a second sub-transaction performed on the second blockchain.

[0117] The first relay is configured to send a first instruction indicating execution of the first sub-transaction to the first node, and send a request for the cross-chain transaction to the second relay.

[0118] The second relay is configured to send a second instruction indicating execution of the second sub-transaction to the second node according to the received request for the cross-chain transaction.

[0119] The second relay is further configured to send an execution result of the second sub-transaction from the second node to the first relay.

[0120] The first relay is further configured to determine an execution result of the cross-chain transaction according to the execution result of the first sub-transaction from the first node and the execution result of the second sub-transaction from the second relay within a trusted execution environment of the first relay.

[0121] It should be understood that the cross-chain transaction can be triggered by a client, i.e., the request for the cross-chain transaction comes from the client, and the first relay is further configured to send the execution result of the cross-chain transaction to the client.

[0122] It should be understood that a blockchain network includes a plurality of nodes, and the plurality of nodes collectively maintain the blockchain, i.e., the blockchain network is a hardware architecture with the plurality of nodes to implement functions such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm; for the first blockchain, the first node is any one of the plurality of nodes that collectively maintain the first blockchain; for the second blockchain, the second node is any one of the plurality of nodes that collectively maintain the second blockchain.

[0123] The first blockchain and the second blockchain are heterogeneous, and the first relay and the second relay both have a trusted execution environment and a rich execution environment. The first relay sends the first instruction to the first node by calling a first SDK, and the first SDK can be an SDK of the first blockchain; the second relay sends the second instruction to the second node by calling a second SDK, and the second SDK can be an SDK of the second blockchain. The relay stores a root certificate of the relay for verification when communicating between relays; the relay also stores a root certificate of the blockchain for the relay to verify messages sent by the blockchain.

[0124] It should be understood that the first relay stores the identity certificate of the first relay, the public and private keys of the first relay, the first root certificate of the first node, the first relay has a trusted execution environment and a rich execution environment, the identity certificate of the first relay, the public and private keys of the first relay, and the first root certificate of the first node are encrypted and stored in the rich execution environment of the first relay, and are only visible in the trusted execution environment of the first relay; or, the identity certificate of the first relay, the public and private keys of the first relay, and the first root certificate of the first node can also be stored in the trusted execution environment of the first relay; the message received by the first relay from the first node is signed by the first root certificate of the first node in the trusted execution environment of the first relay. For example, the trusted execution environment of the first relay stores the root certificate of the first blockchain; in the trusted execution environment of the first relay, the root certificate of the first blockchain can be used to verify whether the execution result of the first sub-transaction is trustworthy, that is, whether the first blockchain is honest in executing the first instruction. Among them, the cross-chain business processing logic of the first relay is deployed in the trusted execution environment of the first relay, the cross-chain transaction state is only decryptable in the trusted execution environment of the first relay, the next cross-chain instruction is determined according to the cross-chain transaction state in the trusted execution environment of the first relay, the cross-chain message is assembled, and the cross-chain process is ensured to be trustworthy.

[0125] Similarly, the second relay stores the identity certificate of the second relay, the public and private keys of the second relay, and the second root certificate of the second node, and the second relay has a trusted execution environment and a rich execution environment. The identity certificate of the second relay, the public and private keys of the second relay, and the second root certificate of the second node are encrypted and stored in the rich execution environment of the second relay, and are only visible in the trusted execution environment of the second relay; or, the identity certificate of the second relay, the public and private keys of the second relay, and the second root certificate of the second node are encrypted and stored in the trusted execution environment of the second relay; the message received by the second relay from the second node is signed by the second root certificate of the second node in the trusted execution environment of the second relay. For example, the trusted execution environment of the second relay stores the root certificate of the second blockchain; in the trusted execution environment of the second relay, the root certificate of the second blockchain can be used to verify whether the execution result of the second sub-transaction is trustworthy, that is, whether the second blockchain is honest in executing the second instruction. Among them, the cross-chain business processing logic of the second relay is deployed in the trusted execution environment of the second relay, the cross-chain transaction state is only decryptable in the trusted execution environment of the second relay, the next cross-chain instruction is determined according to the cross-chain transaction state in the trusted execution environment of the second relay, the cross-chain message is assembled, and the cross-chain process is ensured to be trustworthy.

[0126] The message received by the first relay and the second relay is first transmitted to the rich execution environment and then to the trusted execution environment for signature verification or decryption. The message sent by the first relay and the second relay is first signed in the trusted execution environment, then transmitted to the rich execution environment, and then sent out from the rich execution environment.

[0127] In addition, the first relay and the second relay store the same third root certificate, which is stored in the rich execution environment of the first relay and the second relay and is only visible in the trusted execution environment of the first relay and the second relay. Alternatively, the third root certificate can also be stored in the trusted execution environment of the first relay and the second relay. The first relay receives the message from the second relay and verifies the signature using the third root certificate stored in the first relay in the trusted execution environment of the first relay. The second relay receives the message from the first relay and verifies the signature using the third root certificate stored in the second relay in the trusted execution environment of the second relay. In this way, the identity of the relay can be trusted. Specifically, when the first blockchain performs cross-chain transactions with the heterogeneous second blockchain, the first node maintains the first blockchain, the second node maintains the second blockchain, the first relay connected to the first node and the second relay connected to the second node perform data forwarding and processing, the same third root certificate is stored in the trusted execution environment of the first relay and the second relay, the public and private keys of the first relay and the second relay are generated based on the third root certificate, the messages transmitted between the first relay and the second relay are signed by the private key, and the peer uses the third root certificate to verify the public key, then uses the public key to verify the signature, and then takes out the message content for further processing.

[0128] Please refer to Figure 6 , Figure 6 is a cross-chain processing flow diagram inside a relay provided by an embodiment of the present application, as Figure 6As shown, the rich execution environment of the relay device can only access the encrypted cross-chain transaction state, that is, the cross-chain transaction state ciphertext and the sub-transaction execution result plaintext in the rich execution environment of the relay device; the cross-chain transaction state ciphertext and the sub-transaction execution result plaintext are transmitted from the rich execution environment of the relay device to the trusted execution environment of the relay device, and whether the execution result of each sub-transaction is trusted is verified in the trusted execution environment of the relay device; the cross-chain transaction state and the cross-chain data are decrypted, the cross-chain transaction state is updated, the preset cross-chain logic is executed, the next cross-chain instruction is determined, the updated cross-chain transaction state is encrypted and transmitted to the rich execution environment of the relay device, and the next cross-chain instruction is transmitted to the rich execution environment of the relay device; the rich execution environment of the relay device calls the SDK of the related block chain to execute the next cross-chain instruction. Since the cross-chain transaction state is encrypted in the rich execution environment of the relay device, the cross-chain business logic is performed in the trusted execution environment of the relay device, the rich execution environment of the relay device only transmits data and calls the block chain SDK to execute the cross-chain instruction issued by the trusted execution environment of the relay device, and the trustworthiness of the cross-chain process is ensured.

[0129] Among them, the cross-chain transaction state refers to: for a cross-chain transaction, the relay platform needs the execution results of several sub-transactions of several blockchains, and some blockchains have returned the execution results of the sub-transactions, which are encrypted and cannot be decrypted to obtain plaintext in the rich execution environment. The essence is the execution results of some cross-chain sub-transactions.

[0130] It should be understood that Figure 6 The cross-chain processing flow described in the relay device can be in the first relay device or in the second relay device.

[0131] It can be seen that in the embodiment, when a cross-chain transaction needs to be performed between the heterogeneous first blockchain and the second blockchain, the first relay sends, after obtaining the request of the cross-chain transaction, a first instruction for instructing to perform a first sub-transaction to the first node and sends the request of the cross-chain transaction to the second relay; the first relay is a relay connected with the first node, the first node maintains the first blockchain, the second relay is a relay connected with the second node, the second node maintains the second blockchain, the cross-chain transaction performed by the cross-blockchain system includes the first sub-transaction performed on the first blockchain and the second sub-transaction performed on the second blockchain; the second relay sends, after receiving the request of the cross-chain transaction from the first relay, a second instruction for instructing to perform the second sub-transaction to the second node; the first node performs the first sub-transaction after receiving the first instruction and sends the execution result of the first sub-transaction to the first relay; the second node performs the second sub-transaction after receiving the second instruction and sends the execution result of the second sub-transaction to the second relay; the second relay sends the execution result of the second sub-transaction to the first relay after receiving the execution result of the second sub-transaction; the first relay determines the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction in the trusted execution environment thereof after receiving the execution result of the first sub-transaction and the execution result of the second sub-transaction; it should be understood that since the relay has the trusted execution environment, the relay determines the execution result of the cross-chain transaction in the trusted execution environment, whether the execution result of the cross-chain transaction is trusted, so that the cross-chain transaction process is trusted.

[0132] In an exemplary embodiment, the first relay is configured to: sign, in the trusted execution environment of the first relay, the request of the cross-chain transaction by using a private key of the first relay to obtain first signature data; and send the first signature data to the second relay.

[0133] It can be seen that in the example, the first relay signs, in the trusted execution environment thereof, the request of the cross-chain transaction by using the private key of the first relay to obtain the first signature data, and then sends the first signature data and the identity certificate of the first relay to the second relay, so as to facilitate the second relay to verify the first signature data by using the identity certificate of the first relay to determine that the request of the cross-chain transaction is trusted, which is beneficial for the second relay to instruct the second node to perform the corresponding cross-chain instruction according to the request of the cross-chain transaction, so as to ensure that the cross-chain process is trusted.

[0134] In an example implementation, the second relay holds a third root certificate, and the second relay is further configured to: receive the first signed data and the identity certificate of the first relay from the first relay; verify the identity certificate of the first relay using the third root certificate in a trusted execution environment of the second relay, extract the public key of the first relay from the identity certificate of the first relay after the verification is passed, and verify the first signed data using the public key of the first relay to determine whether the request for cross-chain transaction is authentic.

[0135] It should be understood that after determining whether the request for cross-chain transaction is authentic, the second relay sends the second instruction to the second node, i.e., calling the SDK of the second blockchain to send the second instruction to the second blockchain.

[0136] As can be seen, in this example, the second relay holds a third root certificate, and after receiving the first signed data containing the request for cross-chain transaction and the identity certificate of the first relay, the second relay verifies the identity certificate of the first relay using the third root certificate in a trusted execution environment of the second relay, extracts the public key of the first relay from the identity certificate of the first relay after the verification is passed, and verifies the first signed data using the public key of the first relay to determine whether the request for cross-chain transaction is authentic, which is conducive to the second relay instructing the second node to execute the corresponding cross-chain instruction according to the request for cross-chain transaction, thereby ensuring that the cross-chain process is authentic.

[0137] It should be understood that after receiving the first instruction, the first node will execute the first instruction, and after executing the first instruction, the first node will send the execution result of the first sub-transaction to the first relay.

[0138] In an example implementation, the first node is configured to: sign the execution result of the first sub-transaction using a private key of the first node to obtain second signed data; and send the second signed data to the first relay.

[0139] As can be seen, in this example, when sending the execution result of the first sub-transaction to the first relay, the first node signs the execution result of the first sub-transaction using a private key of the first node to obtain second signed data, and then sends the second signed data and the identity certificate of the first node to the first relay, so that the first relay verifies the second signed data using the identity certificate of the first node, so that the first relay determines whether the execution result of the first sub-transaction is authentic, thereby ensuring that the cross-chain transaction is authentic.

[0140] In an example implementation, the first relay holds a first root certificate, and the first relay is configured to: receive the second signed data and an identity certificate of the first node; verify, in the trusted execution environment of the first relay, the identity certificate of the first node using the first root certificate, and upon verification, extract a public key of the first node from the identity certificate of the first node, and verify the second signed data using the public key of the first node to determine whether the execution result of the first sub-transaction is authentic.

[0141] As can be seen, in this example, the first relay holds a first root certificate of a first node (i.e., a first blockchain), and upon receiving the second signed data containing the execution result of the first sub-transaction and the identity certificate of the first node, the first relay verifies, in the trusted execution environment of the first relay, the identity certificate of the first node using the first root certificate, and upon verification, extracts a public key of the first node from the identity certificate of the first node, and verifies the second signed data using the public key of the first node to determine whether the execution result of the first sub-transaction is authentic, thereby ensuring the authenticity of cross-chain transactions.

[0142] It should be understood that upon receiving the execution result of the first sub-transaction from the first node, the first relay verifies whether the first sub-transaction is executed correctly.

[0143] In an example implementation, the first relay is further configured to: verify, in the trusted execution environment of the first relay, the execution result of the first sub-transaction to determine whether the first sub-transaction is executed correctly.

[0144] For example, the trusted execution environment of the first relay holds a preset transaction verification policy, and the execution result of the first sub-transaction can be verified using the preset transaction verification policy to determine whether the first sub-transaction is executed correctly.

[0145] As can be seen, in this example, the first relay verifies, in the trusted execution environment thereof, the execution result of the first sub-transaction using the preset transaction verification policy to determine whether the first sub-transaction is executed correctly, thereby ensuring that the first node (i.e., the first blockchain) honestly uses correct cross-chain sub-transaction parameters to invoke the function of a correct smart contract, preventing the first node (i.e., the first blockchain) from being malicious or data from being maliciously tampered with, and ensuring the authenticity of cross-chain processes.

[0146] It should be understood that upon receiving the second instruction, the second node executes the second instruction, and sends the execution result of the second sub-transaction to the second relay after executing the second instruction.

[0147] In an example implementation, the second node is configured to: sign the execution result of the second sub-transaction using a private key of the second node to obtain third signed data; and send the third signed data to the second relay.

[0148] In an example implementation, the second relay holds a second root certificate, and the second relay is further configured to: receive third signed data and an identity certificate of the second node from the second node; verify the identity certificate of the second node using the second root certificate in the trusted execution environment of the second relay, and extract a public key of the second node from the identity certificate of the second node upon verification, and verify the third signed data using the public key of the second node to determine whether the execution result of the second sub-transaction is trustworthy.

[0149] It should be understood that the second relay, upon receiving the execution result of the second sub-transaction from the second node, verifies whether the second sub-transaction is executed correctly, and forwards the execution result of the second sub-transaction to the first relay.

[0150] In an example implementation, the second relay is further configured to: verify the execution result of the second sub-transaction in the trusted execution environment of the second relay to determine whether the second sub-transaction is executed correctly.

[0151] For example, the trusted execution environment of the second relay holds a preset transaction verification policy, and the preset transaction verification policy can be used to verify the execution result of the second sub-transaction to determine whether the second sub-transaction is executed correctly.

[0152] In an example implementation, the second relay is further configured to: sign the execution result of the second sub-transaction using a private key of the second relay in the trusted execution environment of the second relay to obtain fourth signed data; and send the fourth signed data to the first relay.

[0153] In an example implementation, the first relay holds a third root certificate, and the first relay is further configured to: receive fourth signed data and an identity certificate of the second relay from the second relay; verify the identity certificate of the second relay using the third root certificate in the trusted execution environment of the first relay, and extract a public key of the second relay from the identity certificate of the second relay upon verification, and verify the fourth signed data using the public key of the second relay to determine whether the execution result of the second sub-transaction is trustworthy.

[0154] As a possible implementation, the first relay, upon receiving the execution result of the second sub-transaction from the second relay, can further verify the execution result of the second sub-transaction using the preset transaction verification policy.

[0155] It should be understood that the first relay, upon receiving the execution result of the first sub-transaction and the execution result of the second sub-transaction, determines the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction.

[0156] In an example implementation, the first relay is configured to determine that the cross-chain transaction is successful if the execution result of the first sub-transaction indicates that the first sub-transaction is executed successfully and the execution result of the second sub-transaction indicates that the second sub-transaction is executed successfully; otherwise, determine that the cross-chain transaction is failed.

[0157] It can be seen that in the example, if the execution result of the first sub-transaction indicates that the first sub-transaction is executed successfully and the execution result of the second sub-transaction indicates that the second sub-transaction is executed successfully, the first relay determines that the cross-chain transaction is successful; otherwise, the first relay determines that the cross-chain transaction is failed, thereby ensuring the atomicity of the cross-chain transaction.

[0158] It should be understood that each node participating in the cross-chain can be deployed with a user business contract and a cross-chain management contract, wherein the user business contract is configured to execute the sub-transaction of the cross-chain, that is, to execute the cross-chain instruction from the relay, including executing the first instruction or the second instruction; the cross-chain management contract records the state log of the key in the cross-chain transaction, and is deleted from the cross-chain management contract after the cross-chain transaction is executed. When executing other transactions, the cross-chain management contract is queried first to check whether the key in the transaction is in the cross-chain state, and then the subsequent operation is determined, so as to realize the isolation of the transaction; after the relay receives the cross-chain sub-transaction result of each blockchain, as long as it is analyzed that one cross-chain sub-transaction fails, it is determined that the cross-chain transaction fails, and the transaction content of the cross-chain transaction failure and the recovery state of each blockchain is sent to each blockchain for execution, thereby ensuring the atomicity of the transaction. Specifically, the efficient isolation of the transaction is realized by deploying the cross-chain management contract, the key in the cross-chain transaction is recorded in the cross-chain management contract, and when the relay sends the final confirmation instruction, if the cross-chain has a sub-transaction execution failure, the initial value of the key is re-written; if the cross-chain transaction is successful, the state of the key after the cross-chain transaction is persisted, and finally the state log of the key is deleted from the cross-chain management contract, thereby ensuring the atomicity of the transaction; when the blockchain executes other cross-chain transactions or ordinary transactions to call the user business contract, the business logic of the user business contract calls the cross-chain management contract to obtain the key, and if the key is in the cross-chain process, the transaction waits or directly returns a failure, thereby realizing the isolation of the transaction.

[0159] In an example implementation, the first node is configured to query whether there is a record of the key of the cross-chain transaction in the first cross-chain management contract based on the first instruction; if there is a record of the key, send the first execution result of the first sub-transaction to the first relay, wherein the first execution result of the first sub-transaction indicates that the first sub-transaction is executed unsuccessfully; if there is no record of the key, execute the first sub-transaction to obtain the first state of the key, record the first state of the key in the first cross-chain management contract, and send the second execution result of the first sub-transaction to the first relay.

[0160] Specifically, the first node includes a first cross-chain management contract and a first user business contract, and the first node executes an operation based on the first instruction by invoking the first user business contract.

[0161] The second execution result of the first sub-transaction sent by the first node to the first relay can indicate that the first sub-transaction is executed successfully or failed. Regardless of whether the second execution result of the first sub-transaction indicates that the first sub-transaction is executed successfully or failed, the first node sends the second execution result of the first sub-transaction to the first relay. In addition, before the first node sends the second execution result of the first sub-transaction to the first relay, the first node can know whether the second execution result of the first sub-transaction indicates that the first sub-transaction is executed successfully or failed.

[0162] It can be seen that in the present example, before the cross-chain transaction is executed, it is first queried in the first cross-chain management contract whether there is a record of the keyword of the cross-chain transaction. When there is a record of the keyword in the first cross-chain management contract, the present cross-chain transaction is aborted or directly failed, so that the present cross-chain transaction will not interfere with the previous cross-chain transaction. When there is no record of the keyword in the first cross-chain management contract, the first sub-transaction is executed to obtain the first state of the keyword, and the first state of the record of the keyword is recorded in the first cross-chain management contract. Subsequently, other cross-chain transactions or ordinary transactions on the first node are aborted or directly failed, so that other cross-chain transactions or ordinary transactions will not interfere with the present cross-chain transaction, thereby realizing cross-chain transaction isolation.

[0163] In an exemplary embodiment, the first relay is further configured to send a third instruction to the first node, wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the third instruction is used to indicate that the cross-chain transaction is successful, and if the execution result of the cross-chain transaction indicates that the cross-chain transaction is failed, the third instruction is used to indicate that the cross-chain transaction is failed.

[0164] It can be seen that in the present example, regardless of whether the cross-chain transaction is successful or failed, the first relay informs the first node of whether the cross-chain transaction is successful or failed through the third instruction, so as to enable the first node to perform corresponding operations according to different situations of whether the cross-chain transaction is successful or failed, thereby ensuring the persistence and consistency of the cross-chain transaction.

[0165] In an exemplary embodiment, the first node is further configured to, if the third instruction indicates that the cross-chain transaction is successful, persist the first state of the keyword and delete the first state of the keyword recorded in the first cross-chain management contract, and if the third instruction indicates that the cross-chain transaction is failed, restore the state of the keyword to the state before the first sub-transaction is executed and delete the first state of the keyword recorded in the first cross-chain management contract.

[0166] Specifically, if the third instruction indicates that the cross-chain transaction fails, the state of the keyword corresponding to the first blockchain can be restored to the state before the first sub-transaction is executed according to the first state of the keyword recorded in the first cross-chain management contract.

[0167] It can be seen that, in the present example, the cross-chain transaction succeeds, and the first node persists the state of the keyword; the cross-chain transaction fails, and the first node restores the state of the keyword to the state before the cross-chain transaction, thereby achieving the persistence and consistency of the cross-chain transaction; and regardless of whether the cross-chain transaction succeeds or fails, the first node deletes the record of the keyword on the first cross-chain management contract, so that other cross-chain transactions or ordinary transactions on the first node after this time will not be disturbed by the cross-chain transaction, thereby achieving the isolation of the cross-chain transaction.

[0168] In an exemplary embodiment, the second node is configured to, based on the second instruction, query whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract; if there is a record of the keyword, send the first execution result of the second sub-transaction to the second relay, wherein the first execution result of the second sub-transaction indicates that the second sub-transaction fails to execute; and if there is no record of the keyword, execute the second sub-transaction to obtain the second state of the keyword, record the second state of the keyword in the second cross-chain management contract, and send the second execution result of the second sub-transaction to the second relay.

[0169] Specifically, the second node includes a second cross-chain management contract and a second user business contract, and the second node executes the operation based on the second instruction by calling the second user business contract.

[0170] It can be seen that, in the present example, before the cross-chain transaction is executed, it is first queried whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract, and when there is a record of the keyword in the second cross-chain management contract, the present cross-chain transaction is aborted or directly fails to execute, so that the present cross-chain transaction will not disturb the last cross-chain transaction; when there is no record of the keyword in the second cross-chain management contract, the second sub-transaction is executed to obtain the second state of the keyword, and the second state of the keyword is recorded in the second cross-chain management contract, and other cross-chain transactions or ordinary transactions on the second node after this time will be aborted or directly fail to execute, so that other cross-chain transactions or ordinary transactions will not disturb the present cross-chain transaction, thereby achieving cross-chain transaction isolation.

[0171] In an exemplary embodiment, the second relay is further configured to: receive the third instruction from the first relay; and send the third instruction to the second node; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction succeeds, the third instruction is used to indicate that the cross-chain transaction succeeds; and if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

[0172] In a possible implementation, the first relay is configured to: in the trusted execution environment of the first relay, sign the third instruction by using a private key of the first relay to obtain fifth signature data; and send the fifth signature data to the second relay.

[0173] It should be understood that, since the third instruction is signed by the first relay, the second relay can determine whether the third instruction is trusted, thereby ensuring that the cross-chain process is trusted.

[0174] In a possible implementation, the first relay, in the trusted execution environment thereof, signs the execution result of the cross-chain transaction by using a private key of the first relay to obtain fifth signature data, and then sends the fifth signature data and the identity certificate of the first relay to the second relay; the second relay generates the third instruction according to the execution result of the cross-chain transaction, and then sends the third instruction to the second node. That is, the third instruction sent by the second relay to the second node can be generated by the first relay or the second relay, which is not limited in the present application.

[0175] In a possible implementation, the second relay stores a third root certificate, and the second relay is further configured to: receive the fifth signature data and the identity certificate of the first relay from the first relay; in the trusted execution environment of the second relay, verify the identity certificate of the first relay by using the third root certificate, extract the public key of the first relay from the identity certificate of the first relay after verification, and verify the fifth signature data by using the public key of the first relay to determine whether the third instruction is trusted.

[0176] It should be understood that the second relay stores a third root certificate, and after the second relay receives the fifth signature data containing the third instruction and the identity certificate of the first relay, the second relay, in the trusted execution environment thereof, verifies the identity certificate of the first relay by using the third root certificate, extracts the public key of the first relay from the identity certificate of the first relay after verification, and verifies the fifth signature data by using the public key of the first relay to determine whether the third instruction is trusted, and then forwards the third instruction to the second node, which is conducive to ensuring that the cross-chain process is trusted.

[0177] It should be understood that, after the second relay receives the third instruction from the first relay, or after the second relay receives the execution result of the cross-chain transaction from the first relay and generates the third instruction according to the execution result of the cross-chain transaction, the second relay sends the third instruction to the second node.

[0178] It can be seen that, regardless of whether the cross-chain transaction is successful or not, the first relay informs the second node of whether the cross-chain transaction is successful or not through the third instruction, so that the second node performs corresponding operations according to different situations of whether the cross-chain transaction is successful or not, thereby ensuring the persistence and consistency of the cross-chain transaction.

[0179] In an example embodiment, the second node is further configured to: if the third instruction indicates that the cross-chain transaction is successful, persist the second state of the keyword and delete the second state of the keyword recorded in the second cross-chain management contract; and if the third instruction indicates that the cross-chain transaction is failed, restore the state of the keyword to the state before the second sub-transaction is executed and delete the second state of the keyword recorded in the second cross-chain management contract.

[0180] Specifically, if the third instruction indicates that the cross-chain transaction is failed, the state of the keyword corresponding to the second blockchain can be restored to the state before the second sub-transaction is executed according to the second state of the keyword recorded in the second cross-chain management contract.

[0181] It can be seen that, in the example, if the cross-chain transaction is successful, the second node persists the state of the keyword; if the cross-chain transaction is failed, the second node restores the state of the keyword to the state before the cross-chain transaction, thereby achieving the persistence and consistency of the cross-chain transaction; and regardless of whether the cross-chain transaction is successful or not, the second node deletes the record of the keyword on the second cross-chain management contract, so that other cross-chain transactions or ordinary transactions on the second node will not be disturbed by the cross-chain transaction, thereby achieving the isolation of the cross-chain transaction.

[0182] Please refer to Figure 7 , Figure 7 is another architecture schematic diagram of a cross-blockchain system for executing transactions provided by an embodiment of the present application. Figure 7 The cross-blockchain system for executing transactions shown includes a first relay, a second relay, a first node, and a second node; the first node maintains a first blockchain, the second node maintains a second blockchain, and the cross-chain transaction executed by the cross-blockchain system includes a first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain;

[0183] The first relay is configured to send a first instruction for instructing the execution of the first sub-transaction to the first node and send a request for the cross-chain transaction to the second relay;

[0184] The second relay is configured to send a second instruction for instructing the execution of the second sub-transaction to the second node according to the received request for the cross-chain transaction;

[0185] The second relay is further configured to send the execution result of the second sub-transaction from the second node to the first relay;

[0186] The first relay is further configured to determine the execution result of the cross-chain transaction according to the execution result of the first sub-transaction from the first node and the execution result of the second sub-transaction from the second relay in a trusted execution environment of the first relay.

[0187] It should be understood that the first blockchain and the second blockchain are heterogeneous.

[0188] In order to ensure the isolation of cross-chain transactions, in addition to using the cross-chain management contract, a two-phase commit interface of a transaction can also be used. The above relays have a trusted execution environment, and the cross-chain process is still executed in the trusted execution environment of the relay. When the rich execution environment of the relay calls the SDK of the blockchain participating in cross-chain according to the cross-chain instruction from the trusted execution environment of the relay, the blockchain participating in cross-chain needs to implement the interface of the two-phase commit of the transaction, and implement the pre-commit and confirmation or rollback of the transaction.

[0189] As shown in Figure 7 The above node includes a pre-commit interface Prepare() of the blockchain, a confirmation interface Commit(), and a rollback interface Rollback(). The pre-commit interface Prepare() implements the pre-commit function of the transaction, and the confirmation interface Commit() and the rollback interface Rollback() implement the confirmation of the transaction. Specifically, the relay first calls the pre-commit interface Prepare() of the blockchain to submit the instruction of executing the sub-transaction; the relay determines the execution result of the cross-chain transaction after receiving the execution result of each cross-chain sub-transaction; if all cross-chain sub-transactions are executed successfully, the confirmation interface Commit() of the blockchain is called to perform state persistence after cross-chain, indicating that the cross-chain transaction is successful; if one cross-chain sub-transaction fails, the rollback interface Rollback() of the blockchain is called to perform transaction state rollback, indicating that the cross-chain transaction fails.

[0190] In an exemplary embodiment, the first relay is configured to call a first pre-commit interface to send a first instruction to the first node; and the first node is configured to execute a first sub-transaction to obtain a first state of a keyword of the cross-chain transaction, and send an execution result of the first sub-transaction to the first relay.

[0191] The first pre-commit interface is the pre-commit interface Prepare() of the first blockchain.

[0192] As can be seen, in the present example, the relay calls the first phase commit interface of the two-phase commit interface of the transaction to send the instruction of the cross-chain transaction to the node, that is, the first relay calls the first pre-commit interface to send the first instruction to the first node; the first node executes the first sub-transaction to obtain the first state of the keyword of the cross-chain transaction, and returns the execution result of the first sub-transaction to the first relay. It should be understood that, since the two-phase commit interface of the transaction is an independent interface newly added on the existing blockchain, the first pre-commit interface is different from the ordinary transaction interface of the blockchain, and therefore sending the first instruction of the cross-chain to the first node by calling the first pre-commit interface will not interfere with the ordinary transaction on the first blockchain, and the isolation of the cross-chain transaction is achieved.

[0193] In an example implementation, the first relay is further configured to: if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, invoke the first confirmation interface to send a third instruction to the first node, wherein the third instruction is used to indicate that the cross-chain transaction is successful; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, invoke the first rollback interface to send the third instruction to the first node, wherein the third instruction is used to indicate that the cross-chain transaction fails; and the first node is further configured to: if the third instruction indicates that the cross-chain transaction is successful, persist the first state of the key; and if the third instruction indicates that the cross-chain transaction fails, restore the state of the key to the state before the first sub-transaction is executed.

[0194] The first confirmation interface is also a confirmation interface Commit() of the first blockchain, and the first rollback interface is also a rollback interface Rollback() of the first blockchain.

[0195] It can be seen that in the example, the relay invokes the second phase of the two-phase commit interface of the transaction to send the instruction of the cross-chain transaction to the node, i.e., if the cross-chain transaction is successful, the first relay invokes the first confirmation interface to send a third instruction to the first node, wherein the third instruction is used to indicate that the cross-chain transaction is successful; if the cross-chain transaction fails, the first relay invokes the first rollback interface to send the third instruction to the first node, wherein the third instruction is used to indicate that the cross-chain transaction is successful; if the third instruction indicates that the cross-chain transaction is successful, the first node persists the first state of the key; and if the third instruction indicates that the cross-chain transaction fails, the first node restores the state of the key to the state before the first sub-transaction is executed. It should be understood that since the two-phase commit interface of the transaction is an independent interface newly added on the existing blockchain, the first confirmation interface or the first rollback interface is different from the ordinary transaction interface of the blockchain, and therefore sending the third instruction of the cross-chain transaction by invoking the first confirmation interface or the first rollback interface will not interfere with the ordinary transaction on the first blockchain, and cross-chain transaction isolation is achieved.

[0196] In an example implementation, the second relay is configured to invoke a second pre-commit interface to send a second instruction to the second node; and the second node is configured to indicate execution of a second sub-transaction to obtain a second state of the key of the cross-chain transaction, and send an execution result of the second sub-transaction to the second relay.

[0197] The second pre-commit interface is also a pre-commit interface Prepare() of the second blockchain.

[0198] It can be seen that in the present example, the first-stage commit interface in the two-stage commit interface of the relay transaction sends the cross-chain transaction instruction to the node, that is, the second pre-commit interface called by the second relay sends the second instruction to the second node; the second node executes the second sub-transaction to obtain the second state of the keyword of the cross-chain transaction, and returns the execution result of the second sub-transaction to the second relay. It should be understood that since the two-stage commit interface of the transaction is an independent interface newly added on the existing blockchain, the second pre-commit interface is different from the ordinary transaction interface of the second blockchain, and therefore calling the second pre-commit interface to send the second cross-chain instruction to the second node will not interfere with the ordinary transaction on the second blockchain, which is conducive to realizing cross-chain transaction isolation.

[0199] In an exemplary embodiment, the first relay is further configured to: in the trusted execution environment of the first relay, sign the execution result of the cross-chain transaction using a private key of the first relay to obtain sixth signature data; and send the sixth signature data to the second relay.

[0200] It can be seen that in the present example, the first relay signs the execution result of the cross-chain transaction using a private key of the first relay in the trusted execution environment thereof to obtain sixth signature data, and then sends the sixth signature data and the identity certificate of the first relay to the second relay, so that the second relay verifies the sixth signature data through the identity certificate of the first relay, so that the first relay determines whether the execution result of the cross-chain transaction is trusted, which is conducive to the second relay instructing the second node to execute the corresponding cross-chain instruction according to the execution result of the cross-chain transaction, thereby ensuring that the cross-chain process is trusted.

[0201] It should be understood that the first relay and the second relay have the same third root certificate, which is stored in the rich execution environment of the first relay and the second relay and is only visible in the trusted execution environment of the first relay and the second relay; or the third root certificate can also be stored in the trusted execution environment of the first relay and the second relay; the first relay receives the message from the second relay, and verifies the signature in the trusted execution environment of the first relay using the third root certificate stored in the first relay; the second relay receives the message from the first relay, and verifies the signature in the trusted execution environment of the second relay using the third root certificate stored in the second relay. In this way, the identity of the relay can be guaranteed to be trusted.

[0202] In an example implementation, the second relay holds a third root certificate, and the second relay is further configured to: receive the sixth signed data and the identity certificate of the first relay from the first relay; verify the identity certificate of the first relay using the third root certificate in the trusted execution environment of the second relay, extract the public key of the first relay from the identity certificate of the first relay after the verification is passed, and verify the sixth signed data using the public key of the first relay to determine whether the execution result of the cross-chain transaction is trustworthy.

[0203] As can be seen, in the example, the second relay holds the third root certificate, and after receiving the sixth signed data containing the execution result of the cross-chain transaction and the identity certificate of the first relay, the second relay verifies the identity certificate of the first relay using the third root certificate in the trusted execution environment of the second relay, extracts the public key of the first relay from the identity certificate of the first relay after the verification is passed, and verifies the sixth signed data using the public key of the first relay to determine whether the execution result of the cross-chain transaction is trustworthy, which is conducive to the second relay instructing the second node to execute a corresponding cross-chain instruction according to the execution result of the cross-chain transaction, thereby ensuring that the cross-chain process is trustworthy.

[0204] In an example implementation, the second relay is further configured to: if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, invoke the second confirmation interface to send a third instruction to the second node, where the third instruction is used to indicate that the cross-chain transaction is successful; and if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, invoke the second rollback interface to send a third instruction to the second node, where the third instruction is used to indicate that the cross-chain transaction fails; and the second node is further configured to: if the third instruction indicates that the cross-chain transaction is successful, persist the second state of the key; and if the third instruction indicates that the cross-chain transaction fails, restore the state of the key to the state before the second sub-transaction is executed.

[0205] The first confirmation interface is also the confirmation interface Commit() of the first blockchain, and the first rollback interface is also the rollback interface Rollback() of the first blockchain.

[0206] It can be seen that, in the present example, the second phase commit interface in the two-phase commit interface of the relay transaction sends the cross-chain transaction instruction to the node, that is, if the cross-chain transaction is successful, the second relay calls the second confirmation interface to send the third instruction to the second node, in which case the third instruction is used to indicate that the cross-chain transaction is successful; if the cross-chain transaction fails, the second relay calls the second rollback interface to send the third instruction to the second node, in which case the third instruction is used to indicate that the cross-chain transaction fails; if the third instruction indicates that the cross-chain transaction is successful, the second node persists the second state of the keyword; if the third instruction indicates that the cross-chain transaction fails, the second node restores the state of the keyword to the state before the second sub-transaction is executed. It should be understood that, since the two-phase commit interface of the transaction is an independent interface newly added on the existing blockchain, the second confirmation interface or the second rollback interface is different from the ordinary transaction interface of the second blockchain, so that calling the second confirmation interface or the second rollback interface to send the third cross-chain instruction will not interfere with the ordinary transaction on the second blockchain, which is conducive to realizing cross-chain transaction isolation.

[0207] It should be understood that, Figure 7 The system for executing cross-blockchain transactions shown in Figure 5 The system for executing cross-blockchain transactions shown in Figure 7 The system for executing cross-blockchain transactions shown in Figure 5 The system for executing cross-blockchain transactions shown in Figure 5 The system for executing cross-blockchain transactions shown in

[0208] Please refer to Figure 8 , Figure 8 is a flowchart of a cross-chain transaction method provided by the embodiments of the present application. The method can be applied to Figure 5 or Figure 7 the system for executing cross-blockchain transactions described above, and the method comprises the following steps:

[0209] In step 801, the first relay sends a first instruction for indicating execution of a first sub-transaction to a first node, and sends a cross-chain transaction request to a second relay, wherein the first node maintains a first blockchain, the second relay corresponds to a second blockchain, and the cross-chain transaction comprises the first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain.

[0210] The first relay and the second relay both have a trusted execution environment. The first relay sends the first instruction to the first node, that is, calls the SDK of the first blockchain to send the first instruction to the first blockchain. In addition, the first blockchain and the second blockchain are heterogeneous.

[0211] It should be understood that the first relay and the second relay store the same third root certificate, which is stored in the rich execution environment of the first relay and the second relay in an encrypted manner and is only visible in the trusted execution environment of the first relay and the second relay; or the third root certificate can also be stored in the trusted execution environment of the first relay and the second relay; the first relay receives the message from the second relay, and the trusted execution environment of the first relay uses the third root certificate stored by the first relay to verify the signature; the second relay receives the message from the first relay, and the trusted execution environment of the second relay uses the third root certificate stored by the second relay to verify the signature. In this way, the identity of the relay can be guaranteed to be trusted.

[0212] In an exemplary embodiment, the request for cross-chain transaction is sent to the second relay, comprising: in the trusted execution environment of the first relay, signing the request for cross-chain transaction by using the private key of the first relay to obtain first signature data; and sending the first signature data to the second relay.

[0213] Step 802, the second relay receives the request for cross-chain transaction from the first relay.

[0214] In an exemplary embodiment, the request for cross-chain transaction is carried in the first signature data, and the method further comprises: the second relay receives the identity certificate of the first relay from the first relay; the second relay verifies the identity certificate of the first relay by using the third root certificate in the trusted execution environment of the second relay, extracts the public key of the first relay from the identity certificate of the first relay after verification, and verifies the first signature data by using the public key of the first relay to determine whether the request for cross-chain transaction indicated by the first signature data is trusted.

[0215] It should be noted that the second relay receiving the first signature data and receiving the identity certificate of the first relay can be one action or two actions; for example, one message carries the first signature data and the identity certificate of the first relay, the first relay sends the message to the second relay, and the second relay receives the message, that is, receives the first signature data and the identity certificate of the first relay; or the first relay sends the first signature data and the identity certificate of the first relay to the second relay by two messages; the present application does not make specific limitation thereto.

[0216] Step 803, the second relay sends a second instruction for indicating to execute a second sub-transaction to a second node, wherein the second node maintains a second blockchain.

[0217] It should be understood that the second relay sends the second instruction to the second node after determining whether the request for cross-chain transaction is trusted, that is, calls the SDK of the second blockchain to send the second instruction to the second blockchain.

[0218] Step 804, the second relay receives the execution result of the second sub-transaction from the second node.

[0219] The second relay stores the second root certificate of the second node, and the second relay receives the message from the second node, and the trusted execution environment of the second relay verifies the message from the second node by using the second root certificate of the second node. For example, the trusted execution environment of the second relay stores the root certificate of the second blockchain, and the trusted execution environment of the second relay verifies whether the execution result of the second sub-transaction is trusted by using the root certificate of the second blockchain, that is, whether the second blockchain is honest in executing the second instruction.

[0220] In an exemplary embodiment, the second relay stores the second root certificate, and the execution result of the second sub-transaction is carried in third signature data. The method further includes: the second relay receives the identity certificate of the second node from the second node, wherein the third signature data is signed by the second node by using the private key of the second node on the execution result of the second sub-transaction; the second relay verifies the identity certificate of the second node by using the second root certificate in the trusted execution environment of the second relay, and extracts the public key of the second node from the identity certificate of the second node after verification, and verifies the third signature data by using the public key of the second node to determine whether the execution result of the second sub-transaction indicated by the third signature data is trusted.

[0221] It should be noted that the second relay receiving the third signature data and receiving the identity certificate of the second node can be one action or two actions. For example, one message carries the third signature data and the identity certificate of the second node, and the second node sends the message to the second relay, and the second relay receives the message, that is, receives the third signature data and the identity certificate of the second node. Alternatively, the second node sends the third signature data and the identity certificate of the second node to the second relay through two messages. The present application does not make a specific limitation hereon.

[0222] It should be understood that after the second relay receives the execution result of the second sub-transaction from the second node, the second relay verifies whether the second sub-transaction is executed correctly, and forwards the execution result of the second sub-transaction to the first relay.

[0223] In an exemplary embodiment, the method further includes: the second relay verifies the execution result of the second sub-transaction in the trusted execution environment of the second relay to determine whether the second sub-transaction is executed correctly.

[0224] Step 805, the second relay sends the execution result of the second sub-transaction to the first relay.

[0225] In an exemplary embodiment, sending the execution result of the second sub-transaction to the first relay includes: signing the execution result of the second sub-transaction with a private key of the second relay in a trusted execution environment of the second relay to obtain fourth signature data; and sending the fourth signature data to the first relay.

[0226] At step 806, the first relay receives the execution result of the first sub-transaction from the first node and receives the execution result of the second sub-transaction from the second relay.

[0227] The first relay stores a first root certificate of the first node, and the message received by the first relay from the first node is signed with the first root certificate of the first node in a trusted execution environment of the first relay. For example, the trusted execution environment of the first relay stores a root certificate of the first blockchain; in the trusted execution environment of the first relay, the root certificate of the first blockchain is used to verify whether the execution result of the first sub-transaction is trustworthy, i.e., whether the first blockchain is honest in executing the first instruction.

[0228] In an exemplary embodiment, the first relay stores a first root certificate, and the execution result of the first sub-transaction is carried in second signature data. The method further includes: the first relay receiving an identity certificate of the first node from the first node, wherein the second signature data is obtained by signing the execution result of the first sub-transaction with a private key of the first node; the first relay verifying the identity certificate of the first node with the first root certificate in a trusted execution environment of the first relay, and extracting a public key of the first node from the identity certificate of the first node after verification, and verifying the second signature data with the public key of the first node to determine whether the execution result of the first sub-transaction indicated by the second signature data is trustworthy.

[0229] It should be noted that the first relay receiving the second signature data and receiving the identity certificate of the first node can be one action or two actions. For example, a message carries the second signature data and the identity certificate of the first node at the same time, the first node sends the message to the first relay, and the first relay receives the message, i.e., receives the second signature data and the identity certificate of the first node; or the first node sends the second signature data and the identity certificate of the first node to the first relay through two messages respectively; the present application does not make a specific limitation in this regard.

[0230] In an exemplary embodiment, after receiving the execution result of the first sub-transaction from the first node, the method further includes: verifying the execution result of the first sub-transaction in a trusted execution environment of the first relay to determine whether the first sub-transaction is executed correctly.

[0231] Specifically, after receiving the execution result of the first sub-transaction of the cross-chain on the first blockchain, the first relay verifies the public key of the blockchain organization by using the first root certificate of the first blockchain stored in the trusted execution environment thereof, and then verifies the signature by using the public key. After the signature verification is successful, the first relay analyzes the data to obtain the content related to the first sub-transaction for verification, and after the verification, the first relay encrypts and stores the execution result of the first sub-transaction. The transaction content can include contract information and parameter information, etc. The verification is performed to ensure that the blockchain has called the correct contract, used the correct parameters, and executed the correct function, so as to ensure the credibility of the transaction result and prevent the blockchain from being malicious or the data from being tampered with.

[0232] In an exemplary embodiment, the first relay stores a third root certificate, and the execution result of the second sub-transaction is carried in fourth signature data. The method further includes: the first relay receiving an identity certificate of the second relay from the second relay, wherein the fourth signature data is obtained by the second relay signing the execution result of the second sub-transaction by using a private key of the second relay in a trusted execution environment of the second relay; and the first relay verifying the identity certificate of the second relay by using the third root certificate in the trusted execution environment of the first relay, extracting the public key of the second relay from the identity certificate of the second relay after the verification is passed, and verifying the signature of the fourth signature data by using the public key of the second relay to determine whether the execution result of the second sub-transaction indicated by the fourth signature data is credible.

[0233] Specifically, the first relay verifies the public key of the second relay according to the third root certificate in the trusted execution environment thereof, and then verifies the signature by using the public key of the second relay after the verification is passed. After the signature verification is passed, the first relay analyzes the transaction content of the second sub-transaction, and encrypts and stores the execution result of the second sub-transaction.

[0234] It should be noted that the first relay receiving the fourth signature data and receiving the identity certificate of the second relay can be one action or two actions. For example, a message carries the fourth signature data and the identity certificate of the second relay, the second relay sends the message to the first relay, and the first relay receives the message, that is, receives the fourth signature data and the identity certificate of the second relay. Alternatively, the second relay sends the fourth signature data and the identity certificate of the second relay to the first relay by two messages. The present application does not make a specific limitation in this regard.

[0235] As one possible implementation, the first relay can further verify the execution result of the second sub-transaction after receiving the execution result of the second sub-transaction from the second relay.

[0236] Step 807: The first relay determines the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction in the trusted execution environment of the first relay.

[0237] In one exemplary implementation, determining the execution result of a cross-chain transaction based on the execution result of the first sub-transaction and the execution result of the second sub-transaction includes: if the execution result of the first sub-transaction indicates that the first sub-transaction was executed successfully and the execution result of the second sub-transaction indicates that the second sub-transaction was executed successfully, then the cross-chain transaction is determined to be successful; otherwise, the cross-chain transaction is determined to be unsuccessful.

[0238] As can be seen in this embodiment, when a cross-chain transaction needs to be performed between the heterogeneous first and second blockchains, after receiving the cross-chain transaction request, the first relay sends a first instruction to the first node to instruct the execution of the first sub-transaction, and sends a cross-chain transaction request to the second relay. The first relay is connected to the first node, which maintains the first blockchain; the second relay is connected to the second node, which maintains the second blockchain. The cross-chain transaction executed by the cross-blockchain system includes a first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain. After receiving the cross-chain transaction request from the first relay, the second relay sends a second instruction to the second node to instruct the execution of the second sub-transaction. The first node receives... Upon receiving the first instruction, the first sub-transaction is executed, and the execution result of the first sub-transaction is sent to the first relayer. Upon receiving the second instruction, the second node executes the second sub-transaction and sends the execution result of the second sub-transaction to the second relayer. Upon receiving the execution result of the second sub-transaction, the second relayer sends the execution result of the second sub-transaction to the first relayer. Upon receiving both the execution results of the first and second sub-transactions, the first relayer, within its trusted execution environment, determines the execution result of the cross-chain transaction based on the execution results of the first and second sub-transactions. It should be understood that because the relayer possesses a trusted execution environment, the relayer determines the execution result of the cross-chain transaction within this environment. This determination of the reliability of the cross-chain transaction execution result ensures the reliability of the cross-chain transaction process.

[0239] When this cross-chain transaction method is applied Figure 5 In the cross-blockchain system shown for executing transactions, the first node includes a first cross-blockchain management contract and a first user business contract, and the second node includes a second cross-blockchain management contract and a second user business contract. The first node achieves cross-blockchain transaction isolation through the first cross-blockchain management contract, and the second node achieves cross-blockchain transaction isolation through the second cross-blockchain management contract. A detailed description follows.

[0240] It should be understood that after receiving the first instruction, the first node can query whether there is a record of the keyword of the cross-chain transaction in the first cross-chain management contract based on the first instruction; if there is a record of the keyword, the first node sends the first execution result of the first sub-transaction to the first relay, wherein the first execution result of the first sub-transaction indicates that the first sub-transaction fails to execute; if there is no record of the keyword, the first node executes the first sub-transaction to obtain the first state of the keyword, records the first state of the keyword in the first cross-chain management contract, and sends the second execution result of the first sub-transaction to the first relay. Specifically, the first node executes the operation based on the first instruction by invoking the first user business contract.

[0241] In an exemplary embodiment, the method further comprises: the first relay sending a third instruction to the first node; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction succeeds, the third instruction is used to indicate that the cross-chain transaction succeeds; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

[0242] It should be understood that if the third instruction indicates that the cross-chain transaction succeeds, the first node, after receiving the third instruction, will persist the first state of the keyword and delete the first state of the keyword recorded in the first cross-chain management contract; if the third instruction indicates that the cross-chain transaction fails, the first node, after receiving the third instruction, will restore the state of the keyword to the state before executing the first sub-transaction and delete the first state of the keyword recorded in the first cross-chain management contract.

[0243] It can be seen that in the present example, whether the cross-chain transaction succeeds or fails, the first relay informs the first node of the success or failure of the cross-chain transaction through the third instruction, so that the first node performs corresponding operations according to different situations of the success or failure of the cross-chain transaction, so as to ensure the persistence and consistency of the cross-chain transaction.

[0244] It should be understood that after receiving the second instruction, the second node can query whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract based on the second instruction; if there is a record of the keyword, the second node sends the first execution result of the second sub-transaction to the second relay, wherein the first execution result of the second sub-transaction indicates that the second sub-transaction fails to execute; if there is no record of the keyword, the second node executes the second sub-transaction to obtain the second state of the keyword, records the second state of the keyword in the second cross-chain management contract, and sends the second execution result of the second sub-transaction to the second relay. Specifically, the second node executes the operation based on the second instruction by invoking the second user business contract.

[0245] In an example implementation, the method further comprises: receiving, by the second relay, the third instruction from the first relay; and sending, by the second relay, the third instruction to the second node, wherein the third instruction is configured to indicate that the cross-chain transaction is successful if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, and the third instruction is configured to indicate that the cross-chain transaction is failed if the execution result of the cross-chain transaction indicates that the cross-chain transaction is failed.

[0246] In a possible implementation, the method further comprises: signing, by the first relay, the third instruction with a private key of the first relay to obtain fifth signature data in a trusted execution environment of the first relay; and sending, by the first relay, the fifth signature data to the second relay.

[0247] It should be understood that, since the third instruction is signed by the first relay, it is beneficial for the second relay to determine whether the third instruction is trusted, thereby ensuring that the cross-chain process is trusted.

[0248] In a possible implementation, the second relay stores a third root certificate, and the third instruction is carried in the fifth signature data, and the method further comprises: receiving, by the second relay, an identity certificate of the first relay from the first relay; verifying, by the second relay, the identity certificate of the first relay with the third root certificate in a trusted execution environment of the second relay, extracting a public key of the first relay from the identity certificate of the first relay after the verification is passed, and verifying the fifth signature data with the public key of the first relay to determine whether the third instruction indicated by the fifth signature data is trusted.

[0249] It should be noted that the reception of the fifth signature data and the reception of the identity certificate of the first relay by the second relay can be one action or two actions, for example, a message carrying the fifth signature data and the identity certificate of the first relay is sent by the first relay to the second relay, and the second relay receives the message, that is, the fifth signature data and the identity certificate of the first relay are received; or the first relay sends the fifth signature data and the identity certificate of the first relay to the second relay through two messages; the present application does not make a specific limitation thereon.

[0250] It should be understood that the second relay stores the third root certificate, and after the second relay receives the fifth signature data containing the third instruction and the identity certificate of the first relay, the second relay verifies the fifth signature data to determine whether the third instruction is trusted, and then forwards the third instruction to the second node, which is beneficial to ensure that the cross-chain process is trusted.

[0251] It should be understood that if the third instruction indicates that the cross-chain transaction is successful, the second node will persist the second state of the keyword after receiving the third instruction, and delete the second state of the keyword recorded in the second cross-chain management contract; if the third instruction indicates that the cross-chain transaction fails, the second node will restore the state of the keyword to the state before executing the second sub-transaction, and delete the second state of the keyword recorded in the second cross-chain management contract.

[0252] It can be seen that whether the cross-chain transaction is successful or not, the first relay informs the second node of the success or failure of the cross-chain transaction through the third instruction, so that the second node performs corresponding operations according to different situations of the success or failure of the cross-chain transaction, so as to ensure the persistence and consistency of the cross-chain transaction.

[0253] Please refer to Figure 9 , Figure 9 is a whole step schematic diagram of a cross-chain transaction method provided by the embodiment of the application. The specific steps are as follows:

[0254] (1) The client sends a request for a cross-chain transaction to the first relay.

[0255] (2) The first relay manages the cross-chain transaction state in its trusted execution environment and schedules the execution of the cross-chain transaction; the first relay calls the SendTx() interface of the first blockchain to send a first instruction to the first blockchain; the first relay sends a message (Msg) including the request for the cross-chain transaction to the second relay. Wherein, SendTx() is an interface provided by the blockchain SDK to initiate a transaction, which is represented as SendTx() here, and all blockchain systems have this interface, which is a general interface; the relay calls the SendTx() interface of the blockchain SDK to send a transaction to the blockchain.

[0256] (3) The first blockchain sends Tx() to the first user business contract. Wherein, Tx() refers to the execution of a transaction by the blockchain system, that is, calling a smart contract to execute a transaction.

[0257] (4) The first user business contract queries whether there is a keyword record of the cross-chain transaction in the first cross-chain management contract, wherein the first cross-chain management contract can record the state log of the keyword. Specifically, if there is a keyword record of the cross-chain transaction in the first cross-chain management contract, it indicates that the keyword is still in the last cross-chain process, and the first sub-transaction of the current cross-chain fails; if there is no keyword in the cross-chain management contract, execute the first sub-transaction of the current cross-chain to obtain the state of the keyword, and call the first cross-chain management contract to record the state of the keyword, which indicates that the keyword is currently in the cross-chain process.

[0258] (5) The first user service contract returns Tx() to the first blockchain, i.e., returns the execution result of the first sub-transaction to the first blockchain. Specifically, the first user service contract is called to execute the first sub-transaction.

[0259] (6) The first blockchain returns SendTx() to the first relay, i.e., returns the execution result of the first sub-transaction to the first relay.

[0260] (7) After the second relay receives the message (Msg) of the request of the cross-chain transaction, the SendTx() interface of the second blockchain is called to send the second instruction to the second blockchain.

[0261] (8) The second blockchain sends Tx() to the second user service contract, specifically, the second user service contract is called to execute the second sub-transaction.

[0262] (9) The second user service contract queries whether there is a keyword record of the cross-chain transaction in the second cross-chain management contract, where the second cross-chain management contract can record the state log of the keyword. Specifically, if there is a keyword record of the cross-chain transaction in the second cross-chain management contract, it indicates that the keyword is still in the last cross-chain process, and the second sub-transaction of the current cross-chain fails to execute; if there is no keyword in the cross-chain management contract, the second sub-transaction of the current cross-chain is executed to obtain the state of the keyword, and the second cross-chain management contract is called to record the state of the keyword, indicating that the keyword is currently in the cross-chain process.

[0263] (10) The second user service contract returns Tx() to the second blockchain, i.e., returns the execution result of the second sub-transaction to the second blockchain.

[0264] (11) The second blockchain returns SendTx() to the second relay, i.e., returns the execution result of the second sub-transaction to the second relay.

[0265] (12) The second relay sends a message (Msg) including the execution result of the second sub-transaction to the first relay.

[0266] (13) After the first relay receives the execution result of the first sub-transaction and the execution result of the second sub-transaction, it manages the cross-chain transaction state in its trusted execution environment, sends a cross-chain result confirmation instruction to the first blockchain and the second relay, i.e., calls the SendTx() interface of the first blockchain to send a third instruction to the first blockchain, and sends a message (Msg) including the third instruction to the second relay.

[0267] (14) The first blockchain sends Tx() to the first user business contract, that is, executes the third instruction. Specifically, after receiving the cross-chain result confirmation instruction, the first blockchain parses the cross-chain result, and if the cross-chain transaction is failed, the state of the keyword of the cross-chain transaction is restored to the state before the execution of the first sub-transaction using the state log of the keyword recorded in the first cross-chain management contract; if the cross-chain transaction is successful, the updated state of the keyword of the cross-chain transaction is persisted; and finally, the record of the state of the keyword of the cross-chain transaction in the first cross-chain management contract is deleted.

[0268] (15) The first user business contract rolls back or submits (that is, persists) the state of the keyword, and deletes the record of the state of the keyword in the first cross-chain management contract.

[0269] (16) The first user business contract returns Tx() to the first blockchain, that is, returns the execution result of the third instruction to the first blockchain.

[0270] (17) The first blockchain returns SendTx() to the first relay, that is, returns the execution result of the third instruction to the first relay.

[0271] (18) The second relay sends the cross-chain result confirmation instruction to the second blockchain, that is, calls the SendTx() interface of the second blockchain to send the third instruction to the second blockchain.

[0272] (19) The second blockchain sends Tx() to the second user business contract, that is, executes the third instruction. Specifically, after receiving the cross-chain result confirmation instruction, the second blockchain parses the cross-chain result, and if the cross-chain transaction is failed, the state of the keyword of the cross-chain transaction is restored to the state before the execution of the second sub-transaction using the state log of the keyword recorded in the second cross-chain management contract; if the cross-chain transaction is successful, the updated state of the keyword of the cross-chain transaction is persisted; and finally, the record of the state of the keyword of the cross-chain transaction in the second cross-chain management contract is deleted.

[0273] (20) The second user business contract rolls back or submits (that is, persists) the state of the keyword, and deletes the record of the state of the keyword in the second cross-chain management contract.

[0274] (21) The second user business contract returns Tx() to the second blockchain, that is, returns the execution result of the third instruction to the second blockchain.

[0275] (22) The second blockchain returns SendTx() to the second relay, that is, returns the execution result of the third instruction to the second relay.

[0276] (23) The second relay sends a message (Msg) including the execution result of the third instruction to the first relay

[0277] (24) The first relay returns the execution result of the cross-chain transaction to the client.

[0278] It should be understood that Figure 9 The described cross-chain steps of the blockchain, the relay can send cross-chain transaction instructions by calling the normal transaction interface of the blockchain, without embedded modification of the kernel code of the blockchain system. After deploying the cross-chain management contract, only the user business contract needs to call the related interface of the cross-chain management contract, and the original other processes in the blockchain system are not affected, and the heterogeneous blockchain system can be simply and quickly connected to the cross-chain platform.

[0279] When the cross-chain transaction method is applied Figure 7 As shown in the cross-blockchain system for executing transactions, the first node includes a first user business contract and a two-phase commit interface of transactions, and the two-phase commit interface of transactions of the first node is also a first pre-commit interface, a first confirmation interface, and a first rollback interface. The second node includes a second user business contract and a two-phase commit interface of transactions, and the two-phase commit interface of transactions of the second node is also a second pre-commit interface, a second confirmation interface, and a second rollback interface. The first relay implements cross-chain transaction isolation of the first node (i.e., the first blockchain) by calling the first pre-commit interface, the first confirmation interface, and the first rollback interface for two-phase commit of transactions. The second relay implements cross-chain transaction isolation of the second node (i.e., the second blockchain) by calling the second pre-commit interface, the second confirmation interface, and the second rollback interface for two-phase commit of transactions. The specific description is as follows:

[0280] In an exemplary embodiment, the first relay sends a first instruction for indicating execution of a first sub-transaction to the first node, including: the first relay calling the first pre-commit interface to send the first instruction to the first node.

[0281] The first pre-commit interface is also a pre-commit interface Prepare() of the first blockchain.

[0282] It should be understood that after the first node receives the first instruction, the first sub-transaction is executed to obtain a first state of a cross-chain transaction key, and the execution result of the first sub-transaction is sent to the first relay.

[0283] As can be seen, in this example, since the two-phase commit interface of transactions is an independent interface newly added to the existing blockchain, the first pre-commit interface is different from the normal transaction interface of the blockchain, and therefore calling the first pre-commit interface to send the first instruction of cross-chain to the first node does not interfere with the normal transaction on the first blockchain, and cross-chain transaction isolation is achieved.

[0284] In an example implementation, the method further comprises: if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the first relay device calling the first confirmation interface to send a third instruction to the first node, wherein the third instruction is used to indicate that the cross-chain transaction is successful; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the first relay device calling the first rollback interface to send the third instruction to the first node, wherein the third instruction is used to indicate that the cross-chain transaction fails.

[0285] The first confirmation interface is a confirmation interface Commit() of the first blockchain, and the first rollback interface is a rollback interface Rollback() of the first blockchain.

[0286] It should be understood that after the first node receives the third instruction, if the third instruction indicates that the cross-chain transaction is successful, the first state of the key is persisted; if the third instruction indicates that the cross-chain transaction fails, the state of the key is restored to the state before the first sub-transaction is executed.

[0287] It can be seen that in the example, since the two-phase commit interface of the transaction is an independent interface newly added on the existing blockchain, the first confirmation interface or the first rollback interface is different from the normal transaction interface of the blockchain, and therefore, sending the cross-chain third instruction by calling the first confirmation interface or the first rollback interface does not interfere with the normal transaction on the first blockchain, and cross-chain transaction isolation is achieved.

[0288] In an example implementation, the second relay device sending the first instruction for executing the second sub-transaction to the second node comprises: the second relay device calling a second pre-commit interface to send the second instruction to the second node.

[0289] The second pre-commit interface is a pre-commit interface Prepare() of the second blockchain.

[0290] It should be understood that after the second node receives the second instruction, the second node executes the second sub-transaction to obtain the second state of the key of the cross-chain transaction, and sends an execution result of the second sub-transaction to the second relay device.

[0291] It can be seen that in the example, since the two-phase commit interface of the transaction is an independent interface newly added on the existing blockchain, the second pre-commit interface is different from the normal transaction interface of the second blockchain, and therefore, sending the cross-chain second instruction by calling the second pre-commit interface to the second node does not interfere with the normal transaction on the second blockchain, which is conducive to achieving cross-chain transaction isolation.

[0292] In an example implementation, the method further comprises: the first relay device signing the execution result of the cross-chain transaction by using a private key of the first relay device in a trusted execution environment of the first relay device to obtain sixth signature data; and the first relay device sending the sixth signature data to the second relay device.

[0293] It can be seen that in the present example, the first relay, in its trusted execution environment, signs the execution result of the cross-chain transaction with the private key of the first relay to obtain sixth signature data, and then sends the sixth signature data and the identity certificate of the first relay to the second relay, so that the second relay verifies the sixth signature data through the identity certificate of the first relay, so that the first relay determines whether the execution result of the cross-chain transaction is trusted, which is conducive to the second relay instructing the second node to execute the corresponding cross-chain instruction according to the execution result of the cross-chain transaction, thereby ensuring that the cross-chain process is trusted.

[0294] In an exemplary embodiment, the second relay stores a third root certificate, and the method further includes: the second relay receiving the sixth signature data and the identity certificate of the first relay from the first relay; the second relay, in a trusted execution environment of the second relay, verifying the identity certificate of the first relay with the third root certificate, extracting the public key of the first relay from the identity certificate of the first relay after verification, and verifying the sixth signature data with the public key of the first relay to determine whether the execution result of the cross-chain transaction is trusted.

[0295] It should be noted that the second relay receiving the sixth signature data and receiving the identity certificate of the first relay can be one action or two actions; for example, a message carries the sixth signature data and the identity certificate of the first relay, and the first relay sends the message to the second relay, and the second relay receives the message, that is, receives the sixth signature data and the identity certificate of the first relay; or the first relay sends the sixth signature data and the identity certificate of the first relay to the second relay through two messages; the present application does not make a specific limitation thereon.

[0296] It can be seen that in the present example, the second relay stores a third root certificate, and the second relay receives the sixth signature data containing the execution result of the cross-chain transaction and the identity certificate of the first relay, and in its trusted execution environment, verifies the identity certificate of the first relay with the third root certificate, extracts the public key of the first relay from the identity certificate of the first relay after verification, and verifies the sixth signature data with the public key of the first relay to determine whether the execution result of the cross-chain transaction is trusted, which is conducive to the second relay instructing the second node to execute the corresponding cross-chain instruction according to the execution result of the cross-chain transaction, thereby ensuring that the cross-chain process is trusted.

[0297] In an example embodiment, the method further comprises: if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the second relay calls the second confirmation interface to send a third instruction to the second node, wherein the third instruction is used to indicate that the cross-chain transaction is successful; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the second relay calls the second rollback interface to send a third instruction to the second node, wherein the third instruction is used to indicate that the cross-chain transaction fails.

[0298] The first confirmation interface is a confirmation interface Commit() of the first blockchain, and the first rollback interface is a rollback interface Rollback() of the first blockchain.

[0299] It should be understood that after the second node receives the third instruction, if the third instruction indicates that the cross-chain transaction is successful, the second state of the key is persisted; if the third instruction indicates that the cross-chain transaction fails, the state of the key is restored to the state before the second sub-transaction is executed.

[0300] It can be seen that in the example, since the two-phase commit interface of the transaction is an independent interface newly added on the existing blockchain, the second confirmation interface or the second rollback interface is different from the normal transaction sending interface of the second blockchain, and therefore sending the third instruction of the cross-chain transaction by calling the second confirmation interface or the second rollback interface does not interfere with the normal transaction on the second blockchain, which is conducive to realizing cross-chain transaction isolation.

[0301] Please refer to Figure 10 , Figure 10 is a schematic diagram of the overall steps of another cross-chain transaction method provided by the embodiments of the present application. The specific steps are as follows:

[0302] (1) The client sends a request of a cross-chain transaction to a first relay.

[0303] (2) The first relay manages the cross-chain transaction state in a trusted execution environment and schedules the execution of the cross-chain transaction; the first relay calls a Prepare() interface of the first blockchain to send a first instruction to the first blockchain; and the first relay sends a message (Msg) including the request of the cross-chain transaction to a second relay.

[0304] (3) The first blockchain sends Tx() to the first user business contract. The Tx() means that the blockchain system executes a transaction, that is, the first user business contract is called to execute a first sub-transaction to obtain the state of the key of the cross-chain transaction.

[0305] (4) The first user business contract returns Tx() to the first blockchain, that is, returns the execution result of the first sub-transaction to the first blockchain.

[0306] (5) The first blockchain returns the execution result of the first sub-transaction to the first relay.

[0307] (6) After receiving the message (Msg) of the request of the cross-chain transaction, the second relay calls the Prepare() interface of the second blockchain to send the second instruction to the second blockchain.

[0308] (7) The second blockchain sends Tx() to the second user business contract. Wherein, Tx() refers to the execution of the transaction of the blockchain system, that is, calling the second user business contract to execute the second sub-transaction to obtain the state of the keyword of the cross-chain transaction.

[0309] (8) The second user business contract returns Tx() to the second blockchain, that is, returns the execution result of the second sub-transaction to the second blockchain.

[0310] (9) The second blockchain returns the execution result of the second sub-transaction to the second relay.

[0311] (10) The second relay sends the message (Msg) including the execution result of the second sub-transaction to the first relay.

[0312] (11) After receiving the execution result of the first sub-transaction and the execution result of the second sub-transaction, the first relay manages the cross-chain transaction state in the trusted execution environment, sends the cross-chain result confirmation instruction to the first blockchain and the second relay, that is, calls the Commit() interface or the Rollback() interface of the first blockchain to send the third instruction to the first blockchain, and sends the message (Msg) including the third instruction to the second relay.

[0313] (12) The first blockchain sends Tx() to the first user business contract, that is, executes the third instruction. Specifically, after receiving the cross-chain result confirmation instruction, the first blockchain parses the cross-chain result therein, if the cross-chain transaction is failed, the state of the keyword of the cross-chain transaction is restored to the state before the execution of the first sub-transaction, if the cross-chain transaction is successful, the obtained state of the keyword of the cross-chain transaction is persisted.

[0314] (13) The first user business contract returns Tx() to the first blockchain, that is, returns the execution result of the third instruction to the first blockchain.

[0315] (14) The first blockchain returns the execution result of the third instruction to the first relay.

[0316] (15) The second relay sends the cross-chain result confirmation instruction to the second blockchain, that is, calls the Commit() interface or the Rollback() interface of the second blockchain to send the third instruction to the second blockchain.

[0317] (16) The second blockchain sends Tx() to the second user business contract, that is, executes the third instruction. Specifically, after receiving the cross-chain result confirmation instruction, the second blockchain parses the cross-chain result, and if the cross-chain transaction is failed, the state of the key of the cross-chain transaction is restored to the state before the execution of the second sub-transaction; if the cross-chain transaction is successful, the obtained state of the key of the cross-chain transaction is persisted.

[0318] (17) The second user business contract returns Tx() to the second blockchain, that is, returns the execution result of the third instruction to the second blockchain.

[0319] (18) The second blockchain returns the execution result of the third instruction to the second relay.

[0320] (19) The second relay sends a message (Msg) including the execution result of the third instruction to the first relay.

[0321] (20) The first relay returns the execution result of the cross-chain transaction to the client.

[0322] It should be understood that, Figure 10 The described cross-chain steps of the blockchain, the relay calls the corresponding Prepare() interface and Commit() interface or Rollback() interface of the SDK of the blockchain to perform the two-phase commit of the cross-chain transaction, that is, Figure 10 The described blockchain needs to add the two-phase commit interface of the transaction.

[0323] The present embodiment can simply and efficiently realize the identity trust of the relay and the trust of the cross-chain process with the natural advantages of the hardware trusted execution environment. First, the identity of the relay is trusted when communicating between relays. The root certificate and the public and private keys of the relay are visible in the trusted execution environment. The public key is verified using the root certificate of the relay, and the message is signed using the public key, ensuring that the identity of the relay cannot be tampered with or forged. Second, the transaction cross-chain transaction state of each cross-chain sub-transaction is encrypted and stored in the rich execution environment, and only in the trusted execution environment can the plaintext be decrypted and obtained. The cross-chain sub-transaction execution result of each blockchain can be verified in the trusted execution environment of the relay, ensuring that the blockchain uses the correct cross-chain sub-transaction parameters to call the correct function of the smart contract, preventing the blockchain from being malicious or the data from being maliciously tampered with. The cross-chain execution logic is deployed in the trusted execution environment of the relay, and the next cross-chain execution action is calculated according to the decrypted cross-chain transaction state in the trusted execution environment, the instruction content is assembled and signed using the private key, and then transmitted to the rich execution environment, ensuring the trust of the cross-chain process processing. The above process realizes the scheduling of the cross-chain process through the relay with a trusted execution environment, without the need for a more complex structure and business logic like the relay chain to ensure the trust of the cross-chain process.

[0324] The embodiment also designs a cross-chain management contract to efficiently isolate cross-chain transactions. In the cross-chain management contract, when a keyword is in the cross-chain process, the keyword is in a locked state, and any subsequent transaction related to the keyword should directly fail or wait for the completion of the cross-chain transaction. How to more concisely and efficiently isolate transactions and enable various blockchain systems to more quickly and conveniently access the cross-chain platform is a key link that needs to be considered in the cross-chain process. The embodiment uses a cross-chain management contract. A keyword in the cross-chain process is recorded in the cross-chain management contract. When the cross-chain ends, the keyword is deleted from the cross-chain management contract. Other transactions related to the keyword query the state of the keyword in the cross-chain management contract. If the keyword is in the cross-chain process, the keyword is locked, and the subsequent transaction cannot be executed. If the cross-chain management contract does not record the state of the keyword, the keyword is not in the cross-chain process, and the subsequent transaction can be normally executed. The cross-chain management contract does not need to be embedded in the kernel code of the blockchain, does not need to provide additional functions for the blockchain system, and only needs to call the interface of the cross-chain management contract when the user writes the user business contract. This can enable various heterogeneous blockchain systems to simply and quickly access the cross-chain platform and participate in cross-chain operations. Each blockchain system can also implement transaction isolation by implementing a two-phase commit interface. This method requires each blockchain system to modify the underlying code and add a two-phase commit interface.

[0325] Please refer to Figure 11 , Figure 11 is another architecture schematic diagram of a cross-blockchain system for executing transactions provided by the embodiment of the present application. Figure 11 The cross-blockchain system for executing transactions includes a relay node, a first node, and a second node. The first node maintains a first blockchain, the second node maintains a second blockchain, and the relay node is a consensus node on a relay chain of the first blockchain and the second blockchain. The cross-chain transaction executed by the cross-blockchain system includes a first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain.

[0326] The relay node is configured to send a first instruction indicating execution of the first sub-transaction to the first node and send a second instruction indicating execution of the second sub-transaction to the second node.

[0327] The first node is configured to send an execution result of the first sub-transaction to the relay node.

[0328] The second node is configured to send an execution result of the second sub-transaction to the relay node.

[0329] The relay node is further configured to determine an execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction.

[0330] The first blockchain and the second blockchain are heterogeneous. In addition, the cross-chain transaction can be triggered by a client or a blockchain node. For example, a request for the cross-chain transaction is sent to the relay node by another blockchain node other than the first node and the second node; the relay node is also the corresponding relay node of the other blockchain node. If the cross-chain transaction is triggered by the client, the request for the cross-chain transaction comes from the client, and the relay node is further configured to send an execution result of the cross-chain transaction to the client. If the cross-chain transaction is triggered by the other blockchain node, the request for the cross-chain transaction comes from the other blockchain node, and the relay node is further configured to send an execution result of the cross-chain transaction to the other blockchain node.

[0331] It should be understood that if the relay platform does not have a hardware trusted execution environment, the cross-chain process can be realized in the form of a relay chain, and the SDK of each blockchain is called by the relay chain to initiate a transaction to each blockchain. The relay chain is a blockchain system, the cross-chain transaction state is recorded on the relay chain to ensure that the cross-chain transaction state cannot be tampered with, the cross-chain instruction is issued after on-chain consensus, and the isolation and atomicity of the cross-chain transaction are realized by using a cross-chain management contract.

[0332] In an exemplary embodiment, the first node is configured to query, based on the first instruction, whether a record of the keyword of the cross-chain transaction exists in the first cross-chain management contract; if the record of the keyword exists, the first node is configured to send a first execution result of the first sub-transaction to the relay node, where the first execution result of the first sub-transaction indicates that the first sub-transaction fails; if the record of the keyword does not exist, the first node is configured to execute the first sub-transaction to obtain a first state of the keyword, record the first state of the keyword in the first cross-chain management contract, and send a second execution result of the first sub-transaction to the relay node.

[0333] Specifically, the first node includes a first cross-chain management contract and a first user business contract, and the first node executes the operation based on the first instruction by calling the first user business contract.

[0334] In an exemplary embodiment, the second node is configured to query, based on the second instruction, whether a record of the keyword of the cross-chain transaction exists in the second cross-chain management contract; if the record of the keyword exists, the second node is configured to send a first execution result of the second sub-transaction to the relay node, where the first execution result of the second sub-transaction indicates that the second sub-transaction fails; if the record of the keyword does not exist, the second node is configured to execute the second sub-transaction to obtain a second state of the keyword, record the second state of the keyword in the second cross-chain management contract, and send a second execution result of the second sub-transaction to the relay node.

[0335] Specifically, the second node includes a second cross-chain management contract and a second user business contract, and the second node executes the operation based on the second instruction by calling the second user business contract.

[0336] In an example implementation, the relay node is further configured to: send the third instruction to the first node, and send the third instruction to the second node; wherein the third instruction is configured to indicate that the cross-chain transaction is successful if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, and the third instruction is configured to indicate that the cross-chain transaction is failed if the execution result of the cross-chain transaction indicates that the cross-chain transaction is failed.

[0337] In an example implementation, the first node is further configured to: if the third instruction indicates that the cross-chain transaction is successful, persist the first state of the keyword and delete the first state of the keyword recorded in the first cross-chain management contract; and if the third instruction indicates that the cross-chain transaction is failed, restore the state of the keyword to the state before the first sub-transaction is executed, and delete the first state of the keyword recorded in the first cross-chain management contract.

[0338] In an example implementation, the second node is further configured to: if the third instruction indicates that the cross-chain transaction is successful, persist the second state of the keyword and delete the second state of the keyword recorded in the second cross-chain management contract; and if the third instruction indicates that the cross-chain transaction is failed, restore the state of the keyword to the state before the second sub-transaction is executed, and delete the second state of the keyword recorded in the second cross-chain management contract.

[0339] It can be seen that in the present embodiment, before the cross-chain transaction is executed, it is first inquired whether there is a record of the keyword of the cross-chain transaction in the first cross-chain management contract. When there is a record of the keyword in the first cross-chain management contract, the present cross-chain transaction is aborted or directly executed to fail, so that the present cross-chain transaction will not interfere with the previous cross-chain transaction. When there is no record of the keyword in the first cross-chain management contract, the first sub-transaction is executed to obtain the first state of the keyword, and the first state of the keyword is recorded in the first cross-chain management contract. Thereafter, other cross-chain transactions or ordinary transactions on the first node are aborted or directly executed to fail, so that other cross-chain transactions or ordinary transactions will not interfere with the present cross-chain transaction. Similarly, before the cross-chain transaction is executed, it is first inquired whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract. When there is a record of the keyword in the second cross-chain management contract, the present cross-chain transaction is aborted or directly executed to fail, so that the present cross-chain transaction will not interfere with the previous cross-chain transaction. When there is no record of the keyword in the second cross-chain management contract, the second sub-transaction is executed to obtain the second state of the keyword, and the second state of the keyword is recorded in the second cross-chain management contract. Thereafter, other cross-chain transactions or ordinary transactions on the second node are aborted or directly executed to fail, so that other cross-chain transactions or ordinary transactions will not interfere with the present cross-chain transaction. Thus, cross-chain transaction isolation can be achieved.

[0340] Please refer to Figure 12 , Figure 12is a flowchart of another cross-chain transaction method provided by an embodiment of the present application; the method can be applied to Figure 11 The cross-blockchain system for performing transactions described above is particularly applicable to Figure 11 The relay node of the cross-blockchain system for performing transactions described above, the method comprises:

[0341] Step 1201, the relay node sends a first instruction for indicating the execution of the first sub-transaction to the first node, and sends a second instruction for indicating the execution of the second sub-transaction to the second node, wherein the first node maintains the first blockchain, the second node maintains the second blockchain, the relay node is a consensus node on the relay chain of the first blockchain and the second blockchain, and the cross-chain transaction comprises the first sub-transaction executed on the first blockchain and the second sub-transaction executed on the second blockchain.

[0342] Wherein the first blockchain and the second blockchain are heterogeneous.

[0343] Wherein the first node comprises a first cross-chain management contract, after receiving the first instruction, the first node queries whether there is a record of the key of the cross-chain transaction in the first cross-chain management contract based on the first instruction; if there is a record of the key, the first node sends a first execution result of the first sub-transaction to the relay node, wherein the first execution result of the first sub-transaction indicates that the first sub-transaction fails to execute; if there is no record of the key, the first node executes the first sub-transaction to obtain a first state of the key, records the first state of the key in the first cross-chain management contract, and sends a second execution result of the first sub-transaction to the relay node.

[0344] Wherein the second node comprises a second cross-chain management contract, after receiving the second instruction, the second node queries whether there is a record of the key of the cross-chain transaction in the second cross-chain management contract based on the second instruction; if there is a record of the key, the second node sends a first execution result of the second sub-transaction to the relay node, wherein the first execution result of the second sub-transaction indicates that the second sub-transaction fails to execute; if there is no record of the key, the second node executes the second sub-transaction to obtain a second state of the key, records the second state of the key in the second cross-chain management contract, and sends a second execution result of the second sub-transaction to the relay node.

[0345] Step 1202, the relay node receives the execution result of the first sub-transaction from the first node, and receives the execution result of the second sub-transaction from the second node.

[0346] Step 1203, the relay node determines the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction.

[0347] Specifically, determining the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction comprises: if the execution result of the first sub-transaction indicates that the first sub-transaction is executed successfully and the execution result of the second sub-transaction indicates that the second sub-transaction is executed successfully, determining that the cross-chain transaction is successful; otherwise, determining that the cross-chain transaction fails.

[0348] In an exemplary embodiment, the method further comprises: the relay node sending a third instruction to the first node and sending the third instruction to the second node; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the third instruction is used to indicate that the cross-chain transaction is successful; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

[0349] It should be understood that if the third instruction indicates that the cross-chain transaction is successful, the first node will persist the first state of the keyword after receiving the third instruction, and delete the first state of the keyword recorded in the first cross-chain management contract; if the third instruction indicates that the cross-chain transaction fails, the first node will restore the state of the keyword to the state before executing the first sub-transaction, and delete the first state of the keyword recorded in the first cross-chain management contract.

[0350] It should be understood that if the third instruction indicates that the cross-chain transaction is successful, the second node will persist the second state of the keyword after receiving the third instruction, and delete the second state of the keyword recorded in the second cross-chain management contract; if the third instruction indicates that the cross-chain transaction fails, the second node will restore the state of the keyword to the state before executing the second sub-transaction, and delete the second state of the keyword recorded in the second cross-chain management contract.

[0351] Please refer to Figure 13 , Figure 13 is a schematic diagram of the overall steps of another cross-chain transaction method provided by the embodiments of the present application. The specific steps are as follows:

[0352] (1) The client sends a request for a cross-chain transaction to the relay chain.

[0353] (2) The relay chain calls the SendTx() interface of the first blockchain to send a first instruction to the first blockchain, and calls the SendTx() interface of the second blockchain to send a second instruction to the second blockchain. Wherein, SendTx() is an interface provided by the blockchain SDK to initiate a transaction, represented by SendTx() here, and this interface is a general interface in a general blockchain system; the relay chain calls the SendTx() interface of the blockchain SDK to send a transaction to the blockchain.

[0354] (3) The first blockchain sends Tx() to the first user business contract. Wherein, Tx() refers to the blockchain system executing a transaction, i.e., calling the smart contract to execute the transaction, specifically, calling the first user business contract to execute the first sub-transaction.

[0355] (4) The first user business contract queries whether there is a keyword record of the cross-chain transaction in the first cross-chain management contract. Wherein, the first cross-chain management contract can record the state log of the keyword. Specifically, if there is a keyword record of the cross-chain transaction in the first cross-chain management contract, it indicates that the keyword is still in the last cross-chain process, and the first sub-transaction of the current cross-chain fails to execute; if there is no keyword in the cross-chain management contract, the first sub-transaction of the current cross-chain is executed to obtain the state of the keyword, and the first cross-chain management contract is called to record the state of the keyword, indicating that the keyword is currently in the cross-chain process.

[0356] (5) The first user business contract returns Tx() to the first blockchain, i.e., returns the execution result of the first sub-transaction to the first blockchain.

[0357] (6) The first blockchain returns SendTx() to the relay chain, i.e., returns the execution result of the first sub-transaction to the relay chain.

[0358] (7) The second blockchain sends Tx() to the second user business contract, specifically, calling the second user business contract to execute the second sub-transaction.

[0359] (8) The second user business contract queries whether there is a keyword record of the cross-chain transaction in the second cross-chain management contract. Wherein, the second cross-chain management contract can record the state log of the keyword. Specifically, if there is a keyword record of the cross-chain transaction in the second cross-chain management contract, it indicates that the keyword is still in the last cross-chain process, and the second sub-transaction of the current cross-chain fails to execute; if there is no keyword in the cross-chain management contract, the second sub-transaction of the current cross-chain is executed to obtain the state of the keyword, and the second cross-chain management contract is called to record the state of the keyword, indicating that the keyword is currently in the cross-chain process.

[0360] (9) The second user business contract returns Tx() to the second blockchain, i.e., returns the execution result of the second sub-transaction to the second blockchain.

[0361] (10) The second blockchain returns SendTx() to the relay chain, i.e., returns the execution result of the second sub-transaction to the relay chain.

[0362] (11) After receiving the execution result of the first sub-transaction and the execution result of the second sub-transaction, the relay chain manages the cross-chain transaction state, and sends a cross-chain result confirmation instruction to the first blockchain and the second blockchain, that is, calls the SendTx() interface of the first blockchain to send the third instruction to the first blockchain, and calls the SendTx() interface of the second blockchain to send the third instruction to the second blockchain.

[0363] (12) The first blockchain sends Tx() to the first user business contract, that is, executes the third instruction. Specifically, after receiving the cross-chain result confirmation instruction, the first blockchain parses the cross-chain result in the cross-chain result confirmation instruction, if the cross-chain transaction is failed, the state of the keyword of the cross-chain transaction is restored to the state before the execution of the first sub-transaction using the state log of the keyword recorded in the first cross-chain management contract; if the cross-chain transaction is successful, the updated state of the keyword of the cross-chain transaction is persisted; and finally, the record of the state of the keyword of the cross-chain transaction in the first cross-chain management contract is deleted.

[0364] (13) The first user business contract reverts or commits (that is, persists) the keyword state, and deletes the record of the state of the keyword in the first cross-chain management contract.

[0365] (14) The first user business contract returns Tx() to the first blockchain, that is, returns the execution result of the third instruction to the first blockchain.

[0366] (15) The first blockchain returns SendTx() to the relay chain, that is, returns the execution result of the third instruction to the relay chain.

[0367] (16) The second blockchain sends Tx() to the second user business contract, that is, executes the third instruction. Specifically, after receiving the cross-chain result confirmation instruction, the second blockchain parses the cross-chain result in the cross-chain result confirmation instruction, if the cross-chain transaction is failed, the state of the keyword of the cross-chain transaction is restored to the state before the execution of the second sub-transaction using the state log of the keyword recorded in the second cross-chain management contract; if the cross-chain transaction is successful, the updated state of the keyword of the cross-chain transaction is persisted; and finally, the record of the state of the keyword of the cross-chain transaction in the second cross-chain management contract is deleted.

[0368] (17) The second user business contract reverts or commits (that is, persists) the keyword state, and deletes the record of the state of the keyword in the second cross-chain management contract.

[0369] (18) The second user business contract returns Tx() to the second blockchain, that is, returns the execution result of the third instruction to the second blockchain.

[0370] (19) The second blockchain returns SendTx() to the relay chain, that is, returns the execution result of the third instruction to the relay chain.

[0371] (20) The relay chain returns the execution result of the cross-chain transaction to the client.

[0372] It can be seen that in the present embodiment, before executing the cross-chain transaction, it is first inquired whether there is a record of the keyword of the cross-chain transaction in the first cross-chain management contract. When there is a record of the keyword in the first cross-chain management contract, the present cross-chain transaction is aborted or directly fails to execute, so that the present cross-chain transaction will not interfere with the previous cross-chain transaction. When there is no record of the keyword in the first cross-chain management contract, the first sub-transaction is executed to obtain the first state of the keyword, and the first state of the keyword is recorded in the first cross-chain management contract. After that, other cross-chain transactions or ordinary transactions on the first node will be aborted or directly fail to execute, so that other cross-chain transactions or ordinary transactions will not interfere with the present cross-chain transaction. Similarly, before executing the cross-chain transaction, it is first inquired whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract. When there is a record of the keyword in the second cross-chain management contract, the present cross-chain transaction is aborted or directly fails to execute, so that the present cross-chain transaction will not interfere with the previous cross-chain transaction. When there is no record of the keyword in the second cross-chain management contract, the second sub-transaction is executed to obtain the second state of the keyword, and the second state of the keyword is recorded in the second cross-chain management contract. After that, other cross-chain transactions or ordinary transactions on the second node will be aborted or directly fail to execute, so that other cross-chain transactions or ordinary transactions will not interfere with the present cross-chain transaction. Thus, cross-chain transaction isolation can be achieved.

[0373] Please refer to Figure 14 , Figure 14 is another architecture schematic diagram of a cross-blockchain system for executing transactions provided by the present embodiment; Figure 14 The cross-blockchain system for executing transactions shown in the figure comprises a relay, a first node and a second node. The first node maintains a first blockchain, and the second node maintains a second blockchain. The first blockchain and the second blockchain are isomorphic. The relay has a trusted execution environment. The cross-chain transaction executed by the cross-blockchain system comprises a first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain.

[0374] The relay is configured to send a first instruction for instructing execution of the first sub-transaction to the first node, and send a second instruction for instructing execution of the second sub-transaction to the second node.

[0375] The first node is configured to send an execution result of the first sub-transaction to the relay.

[0376] The second node is configured to send an execution result of the second sub-transaction to the relay.

[0377] The relay is also configured to determine the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction in the trusted execution environment of the relay.

[0378] In an example implementation, the first node is configured to sign the execution result of the first sub-transaction with a private key of the first node to obtain second signature data, and send the second signature data to the relay.

[0379] In an example implementation, the relay stores a first root certificate, and the relay is further configured to receive the second signature data and an identity certificate of the first node from the first node, verify the identity certificate of the first node with the first root certificate in the trusted execution environment of the relay, and extract a public key of the first node from the identity certificate of the first node after verification is passed, and verify the second signature data with the public key of the first node to determine whether the execution result of the first sub-transaction is trustworthy.

[0380] The first root certificate is a root certificate of the first node, and specifically can be a root certificate of the first blockchain.

[0381] In an example implementation, the relay is further configured to verify the execution result of the first sub-transaction in the trusted execution environment of the relay to determine whether the first sub-transaction is executed correctly.

[0382] For example, the trusted execution environment of the relay stores a preset transaction verification policy, and the execution result of the first sub-transaction can be verified with the preset transaction verification policy to determine whether the first sub-transaction is executed correctly.

[0383] In an example implementation, the second node is configured to sign the execution result of the second sub-transaction with a private key of the second node to obtain third signature data, and send the third signature data to the relay.

[0384] In an example implementation, the relay stores a second root certificate, and the relay is further configured to receive the third signature data and an identity certificate of the second node from the second node, verify the identity certificate of the second node with the second root certificate in the trusted execution environment of the relay, and extract a public key of the second node from the identity certificate of the second node after verification is passed, and verify the third signature data with the public key of the second node to determine whether the execution result of the second sub-transaction is trustworthy.

[0385] The second root certificate is a root certificate of the second node, and specifically can be a root certificate of the second blockchain.

[0386] In an example implementation, the relay is further configured to verify the execution result of the second sub-transaction in the trusted execution environment of the relay to determine whether the second sub-transaction is executed correctly.

[0387] For example, the preset transaction verification policy is stored in the trusted execution environment of the relay, and the preset transaction verification policy can be used to verify the execution result of the second sub-transaction to determine whether the second sub-transaction is executed correctly.

[0388] In an example embodiment, the first node is configured to, based on the first instruction, query whether there is a record of the keyword of the cross-chain transaction in the first cross-chain management contract; if there is the record of the keyword, send the first execution result of the first sub-transaction to the relay, wherein the first execution result of the first sub-transaction indicates that the first sub-transaction fails; if there is no record of the keyword, execute the first sub-transaction to obtain the first state of the keyword, record the first state of the keyword in the first cross-chain management contract, and send the second execution result of the first sub-transaction to the relay.

[0389] Specifically, the first node includes the first cross-chain management contract and the first user business contract, and the first node executes the operation based on the first instruction by invoking the first user business contract.

[0390] In an example embodiment, the second node is configured to, based on the second instruction, query whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract; if there is the record of the keyword, send the first execution result of the second sub-transaction to the relay, wherein the first execution result of the second sub-transaction indicates that the second sub-transaction fails; if there is no record of the keyword, execute the second sub-transaction to obtain the second state of the keyword, record the second state of the keyword in the second cross-chain management contract, and send the second execution result of the second sub-transaction to the relay.

[0391] Specifically, the second node includes the second cross-chain management contract and the second user business contract, and the second node executes the operation based on the second instruction by invoking the second user business contract.

[0392] In an example embodiment, the relay is further configured to: send the third instruction to the first node and send the third instruction to the second node; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction succeeds, the third instruction is used to indicate that the cross-chain transaction succeeds; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

[0393] In an example embodiment, the first node is further configured to: if the third instruction indicates that the cross-chain transaction succeeds, persist the first state of the keyword and delete the first state of the keyword recorded in the first cross-chain management contract; if the third instruction indicates that the cross-chain transaction fails, restore the state of the keyword to the state before executing the first sub-transaction, and delete the first state of the keyword recorded in the first cross-chain management contract.

[0394] In an example implementation, the second node is further configured to: if the third instruction indicates that the cross-chain transaction is successful, persist the second state of the keyword and delete the second state of the keyword recorded in the second cross-chain management contract; and if the third instruction indicates that the cross-chain transaction fails, restore the state of the keyword to the state before the second sub-transaction is executed and delete the second state of the keyword recorded in the second cross-chain management contract.

[0395] It can be seen that, in the present embodiment, for the cross-chain transaction between the homogeneous blockchains, the relay has a trusted execution environment, and the cross-chain transaction result is determined in the trusted execution environment of the relay, so that the cross-chain transaction result is trusted, i.e., the cross-chain process is trusted.

[0396] Referring to Figure 15 , Figure 15 is a flowchart of another cross-chain transaction method provided by the present embodiment; the method can be applied to Figure 14 the cross-blockchain system for executing transactions described above, and in particular to Figure 14 the relay of the cross-blockchain system for executing transactions described above, and the method comprises the following steps.

[0397] Step 1501: sending a first instruction for instructing to execute a first sub-transaction to a first node and sending a second instruction for instructing to execute a second sub-transaction to a second node, wherein the first node maintains a first blockchain, the second node maintains a second blockchain, the first blockchain and the second blockchain are homogeneous, and a cross-chain transaction comprises the first sub-transaction executed on the first blockchain and the second sub-transaction executed on the second blockchain.

[0398] Step 1502: receiving an execution result of the first sub-transaction from the first node and receiving an execution result of the second sub-transaction from the second node.

[0399] Step 1503: determining an execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction in a trusted execution environment of the relay.

[0400] In an example implementation, the relay has a first root certificate, and the execution result of the first sub-transaction is carried in second signature data, wherein the second signature data is obtained by signing the execution result of the first sub-transaction by the first node using a private key of the first node, and the method further comprises: the relay receives an identity certificate of the first node from the first node; the relay verifies the identity certificate of the first node using the first root certificate in the trusted execution environment of the relay, extracts a public key of the first node from the identity certificate of the first node after the verification is passed, and verifies the second signature data using the public key of the first node to determine whether the execution result of the first sub-transaction indicated by the second signature data is trusted.

[0401] The first root certificate is a root certificate of the first node, and specifically can be a root certificate of the first blockchain.

[0402] It should be noted that the receiving of the second signature data and the receiving of the identity certificate of the first node can be one action or two actions. For example, a message carries the second signature data and the identity certificate of the first node at the same time, the first node sends the message to the relay, and the relay receives the message, that is, receives the second signature data and the identity certificate of the first node. Alternatively, the first node sends the second signature data and the identity certificate of the first node to the relay through two messages respectively. The present application does not make a specific limitation in this regard.

[0403] In an exemplary embodiment, the method further comprises: verifying, in the trusted execution environment of the relay, the execution result of the first sub-transaction to determine whether the first sub-transaction is executed correctly.

[0404] In an exemplary embodiment, the relay stores a second root certificate, and the execution result of the second sub-transaction is carried in third signature data, wherein the third signature data is obtained by signing the execution result of the second sub-transaction by the second node using a private key of the second node. The method comprises: receiving an identity certificate of the second node from the second node; verifying, in the trusted execution environment of the relay, the identity certificate of the second node using the second root certificate, and extracting the public key of the second node from the identity certificate of the second node after verification, and verifying the third signature data using the public key of the second node to determine whether the execution result of the second sub-transaction indicated by the third signature data is trustworthy.

[0405] It should be noted that the receiving of the third signature data and the receiving of the identity certificate of the second node can be one action or two actions. For example, a message carries the third signature data and the identity certificate of the second node at the same time, the second node sends the message to the relay, and the relay receives the message, that is, receives the third signature data and the identity certificate of the second node. Alternatively, the second node sends the third signature data and the identity certificate of the second node to the relay through two messages respectively. The present application does not make a specific limitation in this regard.

[0406] The second root certificate is a root certificate of the second node, and specifically can be a root certificate of the second blockchain.

[0407] In an exemplary embodiment, the method further comprises: verifying, in the trusted execution environment of the relay, the execution result of the second sub-transaction to determine whether the second sub-transaction is executed correctly.

[0408] The first node includes a first cross-chain management contract. After receiving the first instruction, the first node queries, based on the first instruction, whether there is a record of the keyword of the cross-chain transaction in the first cross-chain management contract. If there is a record of the keyword, the first node sends a first execution result of the first sub-transaction to the relay, where the first execution result of the first sub-transaction indicates that the first sub-transaction fails. If there is no record of the keyword, the first node executes the first sub-transaction to obtain a first state of the keyword, records the first state of the keyword in the first cross-chain management contract, and sends a second execution result of the first sub-transaction to the relay.

[0409] The second node includes a second cross-chain management contract. After receiving the second instruction, the second node queries, based on the second instruction, whether there is a record of the keyword of the cross-chain transaction in the second cross-chain management contract. If there is a record of the keyword, the second node sends a first execution result of the second sub-transaction to the relay, where the first execution result of the second sub-transaction indicates that the second sub-transaction fails. If there is no record of the keyword, the second node executes the second sub-transaction to obtain a second state of the keyword, records the second state of the keyword in the second cross-chain management contract, and sends a second execution result of the second sub-transaction to the relay.

[0410] In an exemplary embodiment, the method further includes: the relay sending a third instruction to the first node and sending the third instruction to the second node; where if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, the third instruction is used to indicate that the cross-chain transaction is successful; and if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

[0411] It should be understood that if the third instruction indicates that the cross-chain transaction is successful, the first node, after receiving the third instruction, will persist the first state of the keyword and delete the first state of the keyword recorded in the first cross-chain management contract; and if the third instruction indicates that the cross-chain transaction fails, the first node, after receiving the third instruction, will restore the state of the keyword to the state before executing the first sub-transaction and delete the first state of the keyword recorded in the first cross-chain management contract.

[0412] It should be understood that if the third instruction indicates that the cross-chain transaction is successful, the second node, after receiving the third instruction, will persist the second state of the keyword and delete the second state of the keyword recorded in the second cross-chain management contract; and if the third instruction indicates that the cross-chain transaction fails, the second node, after receiving the third instruction, will restore the state of the keyword to the state before executing the second sub-transaction and delete the second state of the keyword recorded in the second cross-chain management contract.

[0413] Please refer to Figure 16 , Figure 16 is a schematic diagram of the overall steps of another cross-chain transaction method provided by the embodiments of the present application. The specific steps are as follows:

[0414] (1) The client sends a cross-chain transaction request to the relay.

[0415] (2) The relay manages the cross-chain transaction state in its trusted execution environment and schedules the execution of the cross-chain transaction; the relay calls the SendTx() interface of the first blockchain to send the first instruction to the first blockchain, and the relay calls the SendTx() interface of the second blockchain to send the second instruction to the second blockchain. Wherein, SendTx() is an interface provided by the blockchain SDK to initiate a transaction, represented here as SendTx(), and this interface is a general interface that is provided by most blockchain systems; the relay calls the SendTx() interface of the blockchain SDK to send a transaction to the blockchain.

[0416] (3) The first blockchain sends Tx() to the first user business contract. Wherein, Tx() refers to the execution of a transaction by the blockchain system, i.e., calling the smart contract to execute the transaction, specifically, calling the first user business contract to execute the first sub-transaction.

[0417] (4) The first user business contract queries the first cross-chain management contract for whether there is a keyword record of the cross-chain transaction, wherein the first cross-chain management contract can record the state log of the keyword. Specifically, if there is a keyword record of the cross-chain transaction in the first cross-chain management contract, it indicates that the keyword is still in the last cross-chain process, and the first sub-transaction of the current cross-chain fails; if there is no keyword in the cross-chain management contract, the first sub-transaction of the current cross-chain is executed to obtain the state of the keyword, and the first cross-chain management contract is called to record the state of the keyword, indicating that the keyword is currently in the cross-chain process.

[0418] (5) The first user business contract returns Tx() to the first blockchain, i.e., returns the execution result of the first sub-transaction to the first blockchain.

[0419] (6) The first blockchain returns SendTx() to the relay, i.e., returns the execution result of the first sub-transaction to the relay.

[0420] (7) The second blockchain sends Tx() to the second user business contract, specifically, calling the second user business contract to execute the second sub-transaction.

[0421] (8) The second user business contract queries the second cross-chain management contract to determine whether the keyword record of the cross-chain transaction exists. The second cross-chain management contract can record the state log of the keyword. Specifically, if the keyword record of the cross-chain transaction exists in the second cross-chain management contract, it indicates that the keyword is still in the last cross-chain process, and the second sub-transaction of the current cross-chain fails. If the keyword does not exist in the cross-chain management contract, the second sub-transaction of the current cross-chain is executed to obtain the state of the keyword, and the second cross-chain management contract is called to record the state of the keyword, indicating that the keyword is currently in the cross-chain process.

[0422] (9) The second user business contract returns Tx() to the second blockchain, that is, returns the execution result of the second sub-transaction to the second blockchain.

[0423] (10) The second blockchain returns SendTx() to the relay, that is, returns the execution result of the second sub-transaction to the relay.

[0424] (11) After receiving the execution result of the first sub-transaction and the execution result of the second sub-transaction, the relay manages the cross-chain transaction state in its trusted execution environment, and sends a cross-chain result confirmation instruction to the first blockchain and the second blockchain, that is, calls the SendTx() interface of the first blockchain to send a third instruction to the first blockchain, and calls the SendTx() interface of the second blockchain to send a third instruction to the second blockchain.

[0425] (12) The first blockchain sends Tx() to the first user business contract, that is, executes the third instruction. Specifically, after receiving the cross-chain result confirmation instruction, the first blockchain parses the cross-chain result, and if the cross-chain transaction fails, the state of the keyword of the cross-chain transaction is restored to the state before the execution of the first sub-transaction using the state log of the keyword recorded in the first cross-chain management contract. If the cross-chain transaction is successful, the updated state of the keyword of the cross-chain transaction is persisted. Finally, the record of the state of the keyword of the cross-chain transaction in the first cross-chain management contract is deleted.

[0426] (13) The first user business contract reverts or commits (that is, persists) the state of the keyword, and deletes the record of the state of the keyword recorded in the first cross-chain management contract.

[0427] (14) The first user business contract returns Tx() to the first blockchain, that is, returns the execution result of the third instruction to the first blockchain.

[0428] (15) The first blockchain returns SendTx() to the relay, that is, returns the execution result of the third instruction to the relay.

[0429] (16) The second blockchain sends Tx() to the second user business contract, that is, executes the third instruction. Specifically, after receiving the cross-chain result confirmation instruction, the second blockchain parses the cross-chain result in the cross-chain result confirmation instruction. If the cross-chain transaction is a failure, the second blockchain uses the state log of the keyword recorded in the second cross-chain management contract to restore the state of the keyword of the cross-chain transaction to the state before the execution of the second sub-transaction. If the cross-chain transaction is successful, the second blockchain updates the state of the keyword of the cross-chain transaction and then deletes the record of the state of the keyword of the cross-chain transaction in the second cross-chain management contract.

[0430] (17) The second user business contract restores or submits (that is, persists) the state of the keyword and deletes the record of the state of the keyword in the second cross-chain management contract.

[0431] (18) The second user business contract returns Tx() to the second blockchain, that is, returns the execution result of the third instruction to the second blockchain.

[0432] (19) The second blockchain returns SendTx() to the relay, that is, returns the execution result of the third instruction to the relay.

[0433] (20) The relay returns the execution result of the cross-chain transaction to the client.

[0434] As can be seen, in the embodiment, for the cross-chain transaction between the homogeneous blockchains, the relay has a trusted execution environment, and the cross-chain transaction result is determined in the trusted execution environment of the relay, so that the cross-chain transaction result is trusted, that is, the cross-chain process is trusted.

[0435] Please refer to Figure 17 , Figure 17 is a flowchart of another cross-chain transaction method provided by the embodiment of the present application. The method can be applied to the cross-blockchain system for executing transactions described in Figure 5 , Figure 11 , Figure 14 , and specifically applied to the first node and / or the second node in the cross-blockchain system for executing transactions described in Figure 5 , Figure 11 , Figure 14 , the method comprises the following steps.

[0436] Step 1701, the node A receives an instruction for indicating the execution of the sub-transaction A from the relay A or the node C, wherein the sub-transaction A is a sub-transaction executed by the blockchain A when the blockchain A performs the cross-chain transaction with the blockchain B; the relay A is a relay connected with the node A; and the node C is a consensus node on the blockchain C, and the blockchain C is a relay chain of the blockchain A and the blockchain B.

[0437] The node A maintains the blockchain A, and the node A comprises the cross-chain management contract A.

[0438] Step 1702, the node A queries whether there is a record of the keyword of the cross-chain transaction in the cross-chain management contract A.

[0439] The record of the keyword includes the keyword and the state of the keyword. For example, the keyword of the cross-chain transaction is a digital asset, and the record of the keyword includes the digital asset and the state of the digital asset. At this time, the state of the digital asset is the number of digital assets.

[0440] Step 1703, if there is a record of the keyword, the node A sends the first execution result of the sub-transaction A to the relay A or the node C, wherein the first execution result of the sub-transaction A indicates that the sub-transaction A fails to execute.

[0441] Step 1704, if there is no record of the keyword, the node A executes the sub-transaction A to obtain the state A of the keyword, records the state A of the keyword in the cross-chain management contract A, and sends the second execution result of the sub-transaction A to the relay A or the node C.

[0442] For example, assuming that the sub-transaction A is a decrease of 10 digital assets in the blockchain A, the original asset of the blockchain A is 100 digital assets, and after executing the sub-transaction A to reduce 10 digital assets, the state A of the keyword is obtained, which is 90 digital assets.

[0443] The node A includes the first node and the second node, the relay A includes the first relay and the second relay, the node C includes the relay node, the sub-transaction A includes the first sub-transaction and the second sub-transaction, the blockchain A includes the first blockchain, the blockchain B includes the second blockchain, the cross-chain management contract A includes the first cross-chain management contract and the second cross-chain management contract, and the state A of the keyword includes the first state and the second state of the keyword.

[0444] When the node A is the first node, the relay A is the first relay, the node C includes the relay node, the sub-transaction A is the first sub-transaction, the blockchain A is the first blockchain, the cross-chain management contract A is the first cross-chain management contract, and the state A of the keyword is the first state of the keyword.

[0445] When the node A is the second node, the relay A is the second relay, the node C includes the relay node, the sub-transaction A is the second sub-transaction, the blockchain A is the second blockchain, the cross-chain management contract A is the second cross-chain management contract, and the state A of the keyword is the second state of the keyword.

[0446] As can be seen, in the present embodiment, before performing the cross-chain transaction, it is first inquired in the cross-chain management contract A whether there is a record of the keyword of the cross-chain transaction, when there is a record of the keyword in the cross-chain management contract A, the cross-chain transaction is aborted or directly fails, so that the cross-chain transaction will not interfere with the previous cross-chain transaction; when there is no record of the keyword in the cross-chain management contract A, the sub-transaction A is executed to obtain the state A of the keyword, and the state A of the keyword is recorded in the cross-chain management contract A, and then other cross-chain transactions or ordinary transactions on the node A are aborted or directly fail, so that other cross-chain transactions or ordinary transactions will not interfere with the present cross-chain transaction, thereby realizing cross-chain transaction isolation.

[0447] In an exemplary embodiment, the method further comprises: the node A receiving a third instruction from the relay A or the node C; if the third instruction indicates that the cross-chain transaction is successful, the node A persisting the state A of the keyword and deleting the state A of the keyword recorded in the cross-chain management contract A; if the third instruction indicates that the cross-chain transaction fails, the node A restoring the state of the keyword corresponding to the blockchain A to the state before the sub-transaction A is executed and deleting the state A of the keyword recorded in the cross-chain management contract A.

[0448] Specifically, if the third instruction indicates that the cross-chain transaction fails, the state of the keyword corresponding to the blockchain A can be restored to the state before the sub-transaction A is executed according to the state A of the keyword recorded in the cross-chain management contract A.

[0449] For example, the original asset of the blockchain A is 100 digital assets, the sub-transaction A is that the digital assets of the blockchain A are reduced by 10, the keyword of the cross-chain transaction is the digital assets, after receiving the instruction of reducing 10 digital assets, the node A queries whether there is a record of the digital assets in the cross-chain management contract A, that is, whether there is the digital assets or the state of the digital assets; if there is a record of the digital assets, the node A sends the first execution result of reducing 10 digital assets to the relay A or the node C, wherein the first execution result of reducing 10 digital assets indicates that the execution of reducing 10 digital assets fails; if there is no record of the digital assets, the node A executes the reduction of 10 digital assets, obtains the state A of the digital assets, that is, 90 digital assets, records the state of the digital assets, that is, 90 digital assets, in the cross-chain management contract A, and at this time, the asset of the blockchain A is 90 digital assets, but this is a temporary state; after receiving the third instruction, if the third instruction indicates that the cross-chain transaction succeeds, the state of the digital assets is persisted, the asset of the blockchain A is persisted as 90 digital assets, and the record of the state of the digital assets, that is, 90 digital assets, in the cross-chain management contract A is deleted; if the third instruction indicates that the cross-chain transaction fails, the node A restores the asset of the blockchain to 100 digital assets, that is, the state A of the digital assets, that is, 90 digital assets, recorded in the cross-chain management contract A and the sub-transaction A, that is, reducing 10 digital assets, are restored to 100 digital assets.

[0450] It can be seen that in the present example, the cross-chain transaction succeeds, the node A persists the state of the keyword; the cross-chain transaction fails, the node A restores the state of the keyword to the state before the cross-chain transaction, thereby realizing the persistence and consistency of the cross-chain transaction; and whether the cross-chain transaction succeeds or fails, the node A deletes the record of the keyword on the cross-chain management contract A, so that the subsequent other cross-chain transactions or ordinary transactions will not be disturbed by the cross-chain transaction, thereby realizing the isolation of the cross-chain transaction.

[0451] The above describes the method of the embodiments of the present application in detail, and the device of the embodiments of the present application is provided below.

[0452] Please refer to Figure 18 , Figure 18 is a structure diagram of a cross-chain transaction device 1800 provided by the embodiments of the present application, applied to a first relay with a trusted execution environment, the first relay corresponds to a first blockchain, the cross-chain transaction device 1800 can include a sending unit 1801, a receiving unit 1802 and a determination unit 1803, and the detailed description of each unit is as follows:

[0453] The sending unit 1801 is configured to send, to a first node, a first instruction indicating execution of a first sub-transaction, and send, to a second relay, a request of a cross-chain transaction, where the first node maintains a first blockchain, the second relay corresponds to a second blockchain, and the cross-chain transaction includes the first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain;

[0454] The receiving unit 1802 is configured to receive an execution result of the first sub-transaction from the first node, and receive an execution result of the second sub-transaction from the second relay;

[0455] The determining unit 1803 is configured to determine, in a trusted execution environment of the first relay, an execution result of the cross-chain transaction based on the execution result of the first sub-transaction and the execution result of the second sub-transaction.

[0456] In an example implementation, the sending unit 1801 is further configured to send, to the first node, a third instruction based on the execution result of the cross-chain transaction, where the third instruction is used to indicate that the cross-chain transaction is successful if the execution result of the cross-chain transaction indicates that the cross-chain transaction is successful, and the third instruction is used to indicate that the cross-chain transaction fails if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails.

[0457] In an example implementation, the sending unit 1801 is configured to, in the trusted execution environment of the first relay, sign the request of the cross-chain transaction by using a private key of the first relay to obtain first signature data, and send the first signature data to the second relay.

[0458] In an example implementation, the first relay stores a first root certificate, and the execution result of the first sub-transaction is carried in second signature data, and the receiving unit 1802 is further configured to receive an identity certificate of the first node from the first node, verify, in the trusted execution environment of the first relay, the identity certificate of the first node by using the first root certificate, and extract a public key of the first node from the identity certificate of the first node after verification, and verify the second signature data by using the public key of the first node to determine whether the execution result of the first sub-transaction indicated by the second signature data is trusted.

[0459] In an example implementation, the determining unit 1803 is further configured to determine, in the trusted execution environment of the first relay, whether the first sub-transaction is executed correctly based on the execution result of the first sub-transaction.

[0460] In an example embodiment, the first relay holds a third root certificate, the execution result of the second sub-transaction is carried in fourth signature data, and the receiving unit 1802 is further configured to receive an identity certificate of the second relay from the second relay, and in the trusted execution environment of the first relay, verify the identity certificate of the second relay using the third root certificate, extract the public key of the second relay from the identity certificate of the second relay after verification, and verify the fourth signature data using the public key of the second relay to determine whether the execution result of the second sub-transaction indicated by the fourth signature data is trusted.

[0461] It should be noted that the implementation of each unit can also correspond to the description of the method embodiment shown in Figure 8 of course, the cross-chain transaction apparatus 1800 provided by the embodiment of the present application includes but is not limited to the above-mentioned unit modules, for example: the cross-chain transaction apparatus 1800 can also include a storage unit 1804, which can be used to store the program code and data of the cross-chain transaction apparatus 1800.

[0462] In the cross-chain transaction apparatus 1800 described in Figure 18 , the first node maintains the first blockchain, the second relay corresponds to the second blockchain, and the cross-chain transaction includes the first sub-transaction executed on the first blockchain and the second sub-transaction executed on the second blockchain; receive the execution result of the first sub-transaction from the first node, and receive the execution result of the second sub-transaction from the second relay; after receiving the execution result of the first sub-transaction and the execution result of the second sub-transaction, in the trusted execution environment of the first relay, determine the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction. It should be understood that since the first relay has a trusted execution environment, the first relay determines the execution result of the cross-chain transaction in the trusted execution environment, so that whether the determined execution result of the cross-chain transaction is trusted, thereby making the cross-chain transaction process trusted.

[0463] Please refer to Figure 19 , Figure 19 is a structural schematic diagram of a cross-chain transaction apparatus 1900 provided by an embodiment of the present application, applied to a node A, the node A maintains a blockchain A, the node A includes a cross-chain management contract A, and the cross-chain transaction apparatus 1900 can include a receiving unit 1901, a querying unit 1902 and a sending unit 1903, wherein the detailed description of each unit is as follows:

[0464] The receiving unit 1901 is configured to receive an instruction for indicating execution of a sub-transaction A from a repeater A or a node C, where the sub-transaction A is a sub-transaction executed by a blockchain A when the blockchain A performs a cross-chain transaction with a blockchain B, the repeater A is a repeater connected to the node A, and the node C is a consensus node on a blockchain C, and the blockchain C is a relay chain of the blockchain A and the blockchain B.

[0465] The querying unit 1902 is configured to query, in a cross-chain management contract A, whether there is a record of a keyword of the cross-chain transaction.

[0466] The sending unit 1903 is configured to send, if there is the record of the keyword, a first execution result of the sub-transaction A to the repeater A or the node C, where the first execution result of the sub-transaction A indicates that the sub-transaction A fails to execute; and the sending unit is further configured to, if there is no record of the keyword, execute the sub-transaction A to obtain a state A of the keyword, record the state A of the keyword in the cross-chain management contract A, and send a second execution result of the sub-transaction A to the repeater A or the node C.

[0467] In an exemplary embodiment, the receiving unit 1901 is further configured to receive a third instruction from the repeater A or the node C; if the third instruction indicates that the cross-chain transaction succeeds, persist the state A of the keyword and delete the record of the state A of the keyword in the cross-chain management contract A; and if the third instruction indicates that the cross-chain transaction fails, restore the state of the keyword to a state before the sub-transaction A is executed and delete the record of the state A of the keyword in the cross-chain management contract A.

[0468] It should be noted that the implementation of each unit can also correspond to the description of the corresponding method embodiment shown in Figure 17 Of course, the cross-chain transaction apparatus 1900 provided by the embodiment of the present application includes but is not limited to the above-mentioned unit modules, for example, the cross-chain transaction apparatus 1900 can further include a storage unit 1904, which can be configured to store program codes and data of the cross-chain transaction apparatus 1900.

[0469] In the cross-chain transaction apparatus 1900 described in Figure 19 In the cross-chain transaction apparatus 1900 described in , before performing the cross-chain transaction, it is queried whether there is a record of a keyword of the cross-chain transaction in a cross-chain management contract A, when there is the record of the keyword in the cross-chain management contract A, the cross-chain transaction is aborted or directly fails to execute, so that the cross-chain transaction does not interfere with the previous cross-chain transaction; when there is no record of the keyword in the cross-chain management contract A, the sub-transaction A is executed to obtain a state A of the keyword, and the state A of the keyword is recorded in the cross-chain management contract A, and then other cross-chain transactions or ordinary transactions on the node A are aborted or directly fail to execute, so that the other cross-chain transactions or ordinary transactions do not interfere with the cross-chain transaction, thereby realizing cross-chain transaction isolation.

[0470] Please refer to Figure 20 , Figure 20 is a structural schematic diagram of a first relay 2010 with a trusted execution environment provided by an embodiment of the present application, the first relay 2010 comprising a processor 2011, a memory 2012 and a communication interface 2013, the processor 2011, the memory 2012 and the communication interface 2013 being connected to each other through a bus 2014.

[0471] The memory 2012 comprises, but is not limited to, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read only memory (EPROM) or a compact disc read-only memory (CD-ROM), and is used for relevant computer programs and data. The communication interface 2013 is used for receiving and sending data.

[0472] The processor 2011 can be one or more central processing units (CPUs), and in the case of the processor 2011 being a CPU, the CPU can be a single-core CPU or a multi-core CPU.

[0473] The processor 2011 in the first relay 2010 is used to read the computer program code stored in the memory 2012, and perform the following operations: sending a first instruction indicating execution of a first sub-transaction to a first node, and sending a request for a cross-chain transaction to a second relay, wherein the first node maintains a first blockchain, the second relay corresponds to a second blockchain, and the cross-chain transaction comprises the first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain; receiving an execution result of the first sub-transaction from the first node, and receiving an execution result of the second sub-transaction from the second relay; and determining an execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction in a trusted execution environment of the first relay.

[0474] It should be noted that the implementation of each operation can also correspond to the description of the corresponding method embodiment shown in Figure 8 .

[0475] In Figure 20In the first relay 2010 described, a first instruction indicating execution of a first sub-transaction is sent to a first node, and a request for a cross-chain transaction is sent to a second relay, the first node maintaining a first blockchain, the second relay corresponding to a second blockchain, the cross-chain transaction including the first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain; an execution result of the first sub-transaction is received from the first node, and an execution result of the second sub-transaction is received from the second relay; after the execution result of the first sub-transaction and the execution result of the second sub-transaction are received, the execution result of the cross-chain transaction is determined in a trusted execution environment of the first relay according to the execution result of the first sub-transaction and the execution result of the second sub-transaction. It should be understood that, since the first relay has the trusted execution environment, the first relay determines the execution result of the cross-chain transaction in the trusted execution environment, so that whether the determined execution result of the cross-chain transaction is trusted, thereby making the cross-chain transaction process trusted.

[0476] Please refer to Figure 21 , Figure 21 is a structural schematic diagram of a node A provided by an embodiment of the present application, the node A maintaining a blockchain A, the node A including a cross-chain management contract A, the node A including a processor 2111, a memory 2112, and a communication interface 2113, the processor 2111, the memory 2112, and the communication interface 2113 being connected to each other through a bus 2114.

[0477] The memory 2112 includes, but is not limited to, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read only memory (EPROM), or a compact disc read-only memory (CD-ROM), and is used for relevant computer programs and data. The communication interface 2113 is used for receiving and sending data.

[0478] The processor 2111 can be one or more central processing units (CPUs), in the case of the processor 2111 being a CPU, the CPU can be a single-core CPU or a multi-core CPU.

[0479] The processor 2111 in the first relay 2110 is configured to read the computer program code stored in the memory 2112, and perform the following operations: receiving an instruction from the relay A or the node C, the instruction being used to instruct to execute a sub-transaction A, the sub-transaction A being a sub-transaction executed by a blockchain A when the blockchain A performs a cross-chain transaction with a blockchain B, the relay A being a relay connected to the node A, and the node C being a consensus node on a blockchain C, the blockchain C being a relay chain of the blockchain A and the blockchain B; querying, in a cross-chain management contract A, whether there is a record of a keyword of the cross-chain transaction; if there is the record of the keyword, sending a first execution result of the sub-transaction A to the relay A or the node C, the first execution result of the sub-transaction A indicating that the sub-transaction A fails to execute; and if there is no record of the keyword, executing the sub-transaction A to obtain a state A of the keyword, recording the state A of the keyword in the cross-chain management contract A, and sending a second execution result of the sub-transaction A to the relay A or the node C.

[0480] It should be noted that the implementation of each operation can also correspond to the description of the method embodiment shown in Figure 17 .

[0481] In the node A described in Figure 21 , before performing a cross-chain transaction, it is queried in a cross-chain management contract A whether there is a record of a keyword of the cross-chain transaction, and when there is the record of the keyword in the cross-chain management contract A, the cross-chain transaction is aborted or directly fails to execute, so that the cross-chain transaction does not interfere with the previous cross-chain transaction; when there is no record of the keyword in the cross-chain management contract A, the sub-transaction A is executed to obtain a state A of the keyword, and the state A of the keyword is recorded in the cross-chain management contract A, and then other cross-chain transactions or ordinary transactions on the node A are aborted or directly fail to execute, so that the other cross-chain transactions or ordinary transactions do not interfere with the cross-chain transaction, thereby realizing cross-chain transaction isolation.

[0482] The embodiment of the present application also provides a chip, the chip comprising at least one processor, a memory and an interface circuit, the memory, the transceiver and the at least one processor being interconnected through lines, and the at least one memory storing a computer program; when the computer program is executed by the processor, Figure 8 , Figure 12 , Figure 15 and Figure 17 the method flow shown in the above description is realized.

[0483] The embodiment of the present application also provides a computer readable storage medium, the computer readable storage medium storing a computer program, and when the computer program is executed on a computer, Figure 8 , Figure 12 , Figure 15 and Figure 17The method flow shown is implemented.

[0484] The embodiment of the present application also provides a computer program product, Figure 8 , Figure 12 , Figure 15 and Figure 17 The method flow shown is implemented.

[0485] To sum up, in the technical scheme provided by the present application, the trusted execution environment of the relay stores the root certificate and the public and private keys of the relay organization, the identity of other relays can be verified, and the identity of the relay is trusted. The trusted execution environment of the relay stores the cross-chain transaction state, and the rich execution environment can only obtain the cross-chain transaction state ciphertext, and the execution of the cross-chain transaction is trusted. The trusted execution environment of the relay is used to process the cross-chain process, the next cross-chain operation instruction is determined and issued by the trusted execution environment according to the transaction state, the cross-chain instruction is trusted, the blockchain is prevented from being maliciously operated, the cross-chain process is safe and trusted. The trusted execution environment of the relay pre-stores the transaction verification strategy, the execution result of each cross-chain sub-transaction can be verified, it is ensured that the blockchain indeed calls the correct contract, uses the correct parameter and performs the correct operation according to the cross-chain instruction and cross-chain data issued by the relay, and the blockchain is prevented from being malicious or data tampered. By deploying the cross-chain management contract, the cross-chain management contract records the state of the keyword of the cross-chain transaction, and the subsequent transaction determines whether the keyword is locked and whether the keyword is in the cross-chain process according to the state of the keyword in the cross-chain management contract. When the cross-chain transaction ends, the keyword is deleted from the cross-chain management contract, and it is determined whether the state of the keyword of the cross-chain transaction is restored to the state before the cross-chain according to the success or failure of the cross-chain transaction, and the efficient isolation and atomicity of the cross-chain transaction are ensured. The scheme does not need to modify the embedded kernel code of the blockchain system, after deploying the cross-chain management contract, only the user business contract needs to call the related interface of the cross-chain management contract, the original other processes in the blockchain system are not affected, and the heterogeneous blockchain system can be simply and quickly connected to the cross-chain platform.

[0486] It should be appreciated that the processor referenced in the embodiments of the present application can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0487] It should also be understood that the memory referenced in the embodiments of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memory. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM) or a flash memory. The volatile memory can be a random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchlink dynamic random access memory (SLDRAM) and direct memory bus random access memory (Direct Rambus RAM, DR RAM).

[0488] It should be noted that when the processor is a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, the memory (storage module) is integrated in the processor.

[0489] It should be noted that the memory described herein is intended to include, but not limited to, these and any other suitable types of memory.

[0490] It should also be understood that the first, second, third, fourth, and various numbered embodiments described herein are merely for the convenience of description and do not limit the scope of the present application.

[0491] It should be understood that the term "and / or" used herein is merely a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " herein generally represents an "or" relationship between the associated objects before and after it.

[0492] It should be understood that in various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of the processes should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0493] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0494] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be described here.

[0495] In several embodiments provided by the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the above-mentioned units is only a logical function division, and there can be another division manner in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed mutual objects can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0496] The units described above as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e. they can be located in one place, or distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0497] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0498] The above functions, if realized in the form of software functional units and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application can be embodied in the form of software product, and the computer software product is stored in a storage medium, including a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods shown in the embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0499] The steps in the method of the embodiments of the present application can be adjusted in sequence, combined, and reduced according to actual needs.

[0500] The modules in the device of the embodiments of the present application can be combined, divided, and reduced according to actual needs.

[0501] The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A cross-blockchain system for performing transactions, characterized in that, The system comprises a first relay, a second relay, a first node and a second node, wherein the first node maintains a first blockchain, the second node maintains a second blockchain, and a cross-chain transaction executed by the cross-chain system comprises a first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain; The first relay is configured to send a first instruction indicating execution of the first sub-transaction to the first node, and send a request for the cross-chain transaction to the second relay; The second relay is configured to send a second instruction indicating execution of the second sub-transaction to the second node according to the received request for the cross-chain transaction; The second relay is further configured to send an execution result of the second sub-transaction from the second node to the first relay; The first relay is further configured to determine an execution result of the cross-chain transaction according to an execution result of the first sub-transaction from the first node and an execution result of the second sub-transaction from the second relay in a trusted execution environment of the first relay; The first node is configured to query whether a record of a keyword of the cross-chain transaction exists in a first cross-chain management contract based on the first instruction; If the record of the keyword exists, the first node is configured to send a first execution result of the first sub-transaction to the first relay, wherein the first execution result of the first sub-transaction indicates that the first sub-transaction fails to execute; If the record of the keyword does not exist, the first node is configured to execute the first sub-transaction to obtain a first state of the keyword, record the first state of the keyword in the first cross-chain management contract, and send a second execution result of the first sub-transaction to the first relay.

2. The system of claim 1, wherein, The first node is further configured to: sign the execution result of the first sub-transaction with a private key of the first node to obtain second signature data; and send the second signature data to the first relay.

3. The system of claim 2, wherein, The first relay stores a first root certificate, and the first relay is further configured to: receive the second signature data and an identity certificate of the first node from the first node; verify the identity certificate of the first node with the first root certificate in a trusted execution environment of the first relay, and extract a public key of the first node from the identity certificate of the first node after verification, and verify the second signature data with the public key of the first node to determine whether the execution result of the first sub-transaction is authentic.

4. The system according to any of claims 1-3, characterized in that, The first relay is further configured to: send a third instruction to the first node; If the execution result of the cross-chain transaction indicates that the cross-chain transaction succeeds, the third instruction is used to indicate that the cross-chain transaction succeeds; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

5. The system of claim 4, wherein, The first node is further configured to: If the third instruction indicates that the cross-chain transaction succeeds, the first node is configured to persist the first state of the keyword, and delete the first state of the keyword recorded in the first cross-chain management contract. If the third instruction indicates that the cross-chain transaction fails, the state of the keyword is restored to the state before the first sub-transaction is executed, and the first state of the keyword recorded in the first cross-chain management contract is deleted.

6. The system of claim 1, wherein, The second node is configured to, based on the second instruction, query whether there is a record of the keyword of the cross-chain transaction in a second cross-chain management contract; if the record of the keyword exists, send the first execution result of the second sub-transaction to the second relay, wherein the first execution result of the second sub-transaction indicates that the second sub-transaction fails to execute; if the record of the keyword does not exist, execute the second sub-transaction to obtain a second state of the keyword, record the second state of the keyword in the second cross-chain management contract, and send the second execution result of the second sub-transaction to the second relay.

7. The system of claim 1, wherein, The second relay is further configured to: receive a third instruction from the first relay; send the third instruction to the second node; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction succeeds, the third instruction is used to indicate that the cross-chain transaction succeeds; and if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

8. The system of claim 6, wherein, The second relay is further configured to: receive a third instruction from the first relay; send the third instruction to the second node; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction succeeds, the third instruction is used to indicate that the cross-chain transaction succeeds; and if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

9. The system of claim 8, wherein, The second node is further configured to: if the third instruction indicates that the cross-chain transaction succeeds, persist the second state of the keyword, and delete the second state of the keyword recorded in the second cross-chain management contract; if the third instruction indicates that the cross-chain transaction fails, restore the state of the keyword to the state before the second sub-transaction is executed, and delete the second state of the keyword recorded in the second cross-chain management contract.

10. A cross-chain transaction method, characterized by, The method applied to a first relay with a trusted execution environment, the first relay corresponding to a first blockchain, the method comprising: sending a first instruction for indicating execution of a first sub-transaction to a first node, and sending a request of a cross-chain transaction to a second relay, wherein the first node maintains the first blockchain, the second relay corresponds to a second blockchain, and the cross-chain transaction comprises the first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain; if the record of the keyword exists, sending the first execution result of the second sub-transaction to the second relay, wherein the first execution result of the second sub-transaction indicates that the second sub-transaction fails to execute; if the record of the keyword does not exist, executing the second sub-transaction to obtain a second state of the keyword, recording the second state of the keyword in the second cross-chain management contract, and sending the second execution result of the second sub-transaction to the second relay. receive an execution result of the first sub-transaction from the first node, and receive an execution result of the second sub-transaction from the second relay; the execution result of the first sub-transaction comprises that the first node queries, based on the first instruction, a first cross-chain management contract whether there is a record of a keyword of the cross-chain transaction; if there is the record of the keyword, the first execution result of the first sub-transaction sent by the first relay is received; and if there is not the record of the keyword, the first sub-transaction is executed to obtain a first state of the keyword, the first state of the keyword is recorded in the first cross-chain management contract, and the second execution result of the first sub-transaction sent by the first relay is received; wherein the first execution result of the first sub-transaction indicates that the first sub-transaction fails to execute; determine, in a trusted execution environment of the first relay, the execution result of the cross-chain transaction according to the execution result of the first sub-transaction and the execution result of the second sub-transaction.

11. The method of claim 10, wherein, The method further comprises: sending a third instruction to the first node based on the execution result of the cross-chain transaction; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction succeeds, the third instruction is used to indicate that the cross-chain transaction succeeds; and if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

12. The method according to claim 10 or 11, characterized in that, The sending of the request of the cross-chain transaction to the second relay comprises: signing, in the trusted execution environment of the first relay, the request of the cross-chain transaction by using a private key of the first relay to obtain first signature data; sending the first signature data to the second relay.

13. The method of claim 10 or 11, wherein, The first relay stores a first root certificate, the execution result of the first sub-transaction is carried in second signature data, and the method further comprises: receiving an identity certificate of the first node from the first node; verifying, in the trusted execution environment of the first relay, the identity certificate of the first node by using the first root certificate, and extracting a public key of the first node from the identity certificate of the first node after the verification is passed, and verifying the second signature data by using the public key of the first node to determine whether the execution result of the first sub-transaction indicated by the second signature data is trusted.

14. The method of claim 10 or 11, wherein, After receiving the execution result of the first sub-transaction from the first node, the method further comprises: determining, in the trusted execution environment of the first relay, whether the first sub-transaction is correctly executed based on the execution result of the first sub-transaction.

15. The method of claim 10 or 11, wherein, The first relay stores a third root certificate, the execution result of the second sub-transaction is carried in fourth signature data, and the method further comprises: receiving an identity certificate of the second relay from the second relay; In the trusted execution environment of the first relay, the identity certificate of the second relay is verified by using the third root certificate, the public key of the second relay is extracted from the identity certificate of the second relay after verification, and the fourth signature data is verified by using the public key of the second relay to determine whether the execution result of the second sub-transaction indicated by the fourth signature data is trusted.

16. A cross-chain transaction method, characterized by, The method applied to a node A, the node A maintaining a blockchain A, the node A including a cross-chain management contract A, the method comprising: receiving an instruction from a relay A or a node C for indicating execution of a sub-transaction A, wherein the sub-transaction A is a sub-transaction executed by the blockchain A when the blockchain A performs cross-chain transaction with a blockchain B, the relay A is a relay connected with the node A, and the node C is a consensus node on a blockchain C, the blockchain C being a relay chain of the blockchain A and the blockchain B; querying the cross-chain management contract A for whether there is a record of a keyword of cross-chain transaction; if the record of the keyword exists, sending a first execution result of the sub-transaction A to the relay A or the node C, wherein the first execution result of the sub-transaction A indicates that the sub-transaction A fails to execute; if the record of the keyword does not exist, executing the sub-transaction A to obtain a state A of the keyword, recording the state A of the keyword in the cross-chain management contract A, and sending a second execution result of the sub-transaction A to the relay A or the node C.

17. The method of claim 16, wherein, The method further comprises: receiving a third instruction from the relay A or the node C; if the third instruction indicates that the cross-chain transaction succeeds, persisting the state A of the keyword and deleting the state A of the keyword recorded in the cross-chain management contract A; if the third instruction indicates that the cross-chain transaction fails, restoring the state of the keyword to a state before the sub-transaction A is executed, and deleting the state A of the keyword recorded in the cross-chain management contract A.

18. A cross-chain transaction apparatus, characterized by comprising: The method applied to a first relay with a trusted execution environment, the first relay corresponding to a first blockchain, the device comprising: a sending unit configured to send a first instruction for indicating execution of a first sub-transaction to a first node and send a request for cross-chain transaction to a second relay, wherein the first node maintains the first blockchain, the second relay corresponds to a second blockchain, and the cross-chain transaction includes the first sub-transaction executed on the first blockchain and a second sub-transaction executed on the second blockchain; receive an execution result of the first sub-transaction from the first node, and receive an execution result of the second sub-transaction from the second relay; the execution result of the first sub-transaction comprises that the first node queries, based on the first instruction, a first cross-chain management contract whether there is a record of a keyword of a cross-chain transaction; if there is the record of the keyword, the first execution result of the first sub-transaction sent by the first relay is received; and if there is not the record of the keyword, the first sub-transaction is executed to obtain a first state of the keyword, the first state of the keyword is recorded in the first cross-chain management contract, and the second execution result of the first sub-transaction sent by the first relay is received; wherein the first execution result of the first sub-transaction indicates that the first sub-transaction fails to execute; determine, in a trusted execution environment of the first relay, the execution result of the cross-chain transaction based on the execution result of the first sub-transaction and the execution result of the second sub-transaction.

19. The apparatus of claim 18, wherein, The sending unit is further configured to: send a third instruction to the first node based on the execution result of the cross-chain transaction; wherein if the execution result of the cross-chain transaction indicates that the cross-chain transaction succeeds, the third instruction is used to indicate that the cross-chain transaction succeeds; if the execution result of the cross-chain transaction indicates that the cross-chain transaction fails, the third instruction is used to indicate that the cross-chain transaction fails.

20. The apparatus of claim 18 or 19, wherein, The sending unit is configured to: sign the request of the cross-chain transaction by using a private key of the first relay to obtain first signature data in the trusted execution environment of the first relay; send the first signature data to the second relay.

21. The apparatus of claim 18 or 19, wherein, The first relay stores a first root certificate, the execution result of the first sub-transaction is carried in second signature data, and the receiving unit is further configured to: receive an identity certificate of the first node from the first node; verify the identity certificate of the first node by using the first root certificate in the trusted execution environment of the first relay, and extract a public key of the first node from the identity certificate of the first node after the verification is passed, and verify the second signature data by using the public key of the first node to determine whether the execution result of the first sub-transaction indicated by the second signature data is trusted.

22. The apparatus of claim 18 or 19, wherein, The determining unit is further configured to: determine, in the trusted execution environment of the first relay, whether the first sub-transaction is correctly executed based on the execution result of the first sub-transaction.

23. The apparatus of claim 18 or 19, wherein, The first relay stores a third root certificate, the execution result of the second sub-transaction is carried in fourth signature data, and the receiving unit is further configured to: receive an identity certificate of the second relay from the second relay; In the trusted execution environment of the first relay, the identity certificate of the second relay is verified by using the third root certificate, the public key of the second relay is extracted from the identity certificate of the second relay after verification, and the fourth signature data is verified by using the public key of the second relay to determine whether the execution result of the second sub-transaction indicated by the fourth signature data is trustworthy.

24. A cross-chain transaction apparatus, comprising: The application is applied to a node A, the node A maintains a blockchain A, the node A includes a cross-chain management contract A, and the device includes: A receiving unit is configured to receive an instruction for indicating execution of a sub-transaction A from a relay A or a node C, where the sub-transaction A is a sub-transaction executed by the blockchain A when the blockchain A performs cross-chain transaction with a blockchain B, the relay A is a relay connected to the node A, and the node C is a consensus node on a blockchain C, where the blockchain C is a relay chain of the blockchain A and the blockchain B. A querying unit is configured to query whether a record of a keyword of cross-chain transaction exists in the cross-chain management contract A. A sending unit is configured to send a first execution result of the sub-transaction A to the relay A or the node C if the record of the keyword exists, where the first execution result of the sub-transaction A indicates that the sub-transaction A fails to execute. The sending unit is further configured to execute the sub-transaction A to obtain a state A of the keyword, record the state A of the keyword in the cross-chain management contract A, and send a second execution result of the sub-transaction A to the relay A or the node C if the record of the keyword does not exist.

25. The apparatus of claim 24, wherein, The receiving unit is further configured to: receive a third instruction from the relay A or the node C; persist the state A of the keyword and delete the state A of the keyword recorded in the cross-chain management contract A if the third instruction indicates that the cross-chain transaction succeeds; restore the state of the keyword to a state before the sub-transaction A is executed and delete the state A of the keyword recorded in the cross-chain management contract A if the third instruction indicates that the cross-chain transaction fails.

26. A first relay with a trusted execution environment, the first relay comprising: A computer program product comprising a processor, a memory, a communication interface, and one or more programs stored in the memory and configured to be executed by the processor, the programs comprising instructions for performing the steps of the method of any one of claims 10-15.

27. An electronic device, comprising: A computer program product comprising a processor, a memory, a communication interface, and one or more programs stored in the memory and configured to be executed by the processor, the programs comprising instructions for performing the steps of the method of claim 16 or 17.

28. A chip, characterized by A computer program product comprising: a processor configured to call and run a computer program from a memory, so that a device installed with the chip performs the method of any one of claims 10-15 or 16 or 17.

29. A computer-readable storage medium, characterized in that, A computer program product comprising a processor, a memory, a communication interface, and one or more programs stored in the memory and configured to be executed by the processor, the programs comprising instructions for performing the steps of the method of any one of claims 10-15 or 16 or 17.

30. A computer program product, characterised in that, The computer program product comprises a computer program which causes a computer to perform the method of any one of claims 10-15 or 16 or 17. The computer program product comprises a computer program which causes a computer to perform the method of any one of claims 10-15 or 16 or 17.

Citation Information

Patent Citations

  • Cross-chain data credible management method and device and electronic equipment

    CN110035045A

  • Relay-based block chain interaction system and method

    CN110650189A