Oracle-based blockchain interconnection method and device for cross-chain asset swap scenarios

Abstract

The present invention provides a blockchain interconnection method and device based on an oracle for cross-chain asset swap scenarios. The method includes: the oracle master node monitors cross-chain request events triggered by the source blockchain, performs a threshold signature on the cross-chain request to obtain a preparation request, and sends it to the oracle supervisor / ordinary node; each oracle supervisor / ordinary node performs a threshold signature on the preparation request to obtain a request message to be aggregated, and sends the request message to be aggregated to the remaining oracle supervisor / ordinary nodes; each oracle supervisor / ordinary node verifies the content of the cross-chain request, and when the total number of threshold signatures reaches a set number, the threshold signatures are aggregated; the oracle ordinary node generates an aggregated message, the oracle supervisor node verifies the compliance of the cross-chain request content and generates an aggregated message; the first node to obtain the aggregated signature sends the aggregated message to the destination blockchain, verifies the node consensus, and executes the cross-chain transaction based on the result. This solution can achieve controllable and reliable cross-chain transactions.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to an oracle-based blockchain interconnection method, device, and storage medium for cross-chain asset replacement scenarios. Background Art

[0002] According to CoinMarketCap, as of July 24, 2020, there were 5,784 blockchain-based cryptocurrencies worldwide, with a total market capitalization exceeding $285 billion. Furthermore, with the development of blockchain technology, blockchains are no longer limited to public chains, primarily based on cryptocurrencies, where all nodes can join and exit. They can also encompass consortium and private chains, where only authorized nodes can join and exit. The flourishing development of diverse blockchains has expanded blockchain applications beyond cryptocurrencies to encompass finance, energy, logistics, and other fields.

[0003] However, the booming development of blockchain technology has resulted in the disparity of the underlying architectures of most blockchains, making it impossible for different architectures to interconnect on-chain data, ultimately leading to blockchains becoming data silos. Taking consortium blockchains as an example, mainstream international enterprise-level consortium blockchain solutions include Hyperledger Fabric from the Hyperledger Foundation and JPMorgan Chase's Quorum platform. Mainstream domestic consortium blockchain solutions include WeBank's FISCOBCOS and FunChain's Hyperchain. These blockchain solutions employ distinct solutions and technical approaches. Deploying different blockchains for different application scenarios will prevent interoperability between them, limiting the ability of blockchains to collaborate across multiple scenarios.

[0004] To address the interoperability issues faced by heterogeneous blockchains, cross-chain technology has become a research hotspot. Among the applications of cross-chain technology across public or consortium blockchains, the most common and challenging is cross-chain asset swaps. Both the source and destination blockchains must ensure the authenticity, atomicity, and eventual consistency of cross-chain asset swap transactions. Authenticity refers to the actual occurrence of cross-chain transactions on the source blockchain; atomicity refers to the simultaneous success or failure of cross-chain transactions on both the source and destination blockchains; and eventual consistency refers to the finality of the results of cross-chain transaction execution.

[0005] Current mainstream cross-chain technologies include centralized / multi-signature notary mechanisms, sidechains / relay chains, and hash locking. Furthermore, numerous cross-chain interoperability solutions have emerged based on these mainstream technologies. Polkadot and Cosmos are the main international cross-chain solutions. Polkadot uses a relay chain to connect multiple parachains, utilizing a multi-role governance model consisting of committers, validators, and fishermen to forward cross-chain transactions between parachains and enforce relay chain consensus. Cosmos uses a consensus engine to connect multiple hubs, enabling secure routing and forwarding of cross-chain transactions between them. Domestic cross-chain solutions in China include WeCross and Bixhub. WeCross implements cross-chain transaction addressing and routing through cross-chain partitioning, cross-chain routing, and cross-chain adaptation, and incorporates a standard Merkle proof mechanism to implement a trusted interaction process. Bixhub designs a universal inter-chain transfer protocol (IBTP) and cooperates with the architecture model of gateway and relay chain to realize cross-chain interaction of heterogeneous blockchains. The gateway solves the problems of cross-chain transaction acquisition and submission, and the relay chain combined with IBTP solves the verification and routing problems of cross-chain transactions.

[0006] Chinese patent application number 202010175290.9, titled "Cross-Blockchain Data Interoperability Method, Apparatus, Device, and Storage Medium," utilizes relay nodes in both the source and destination blockchains to monitor cross-chain transactions and utilizes the relay nodes' encryption and decryption capabilities to ensure secure and reliable transmission of cross-chain transactions. However, this solution requires high randomness for relay nodes. Otherwise, malicious attackers can simply attack the relay nodes to tamper with or disrupt cross-chain transactions, harming the interests of the source blockchain. Furthermore, this solution fails to regulate cross-chain transactions.

[0007] Chinese patent application number 201911302120.6, entitled "Cross-chain Exchange Method, System, and Medium Based on Trusted Oracles," improves overall network reliability, reduces the complexity of verifying the authenticity and validity of results, and improves the efficiency of processing most normal process requests. However, this solution is based on a cross-chain exchange method using a trusted oracle, or TEE, and performs cross-chain exchange operations by monitoring on-chain blockchain events through the TEE. During cross-chain exchanges, since the TEE (Trusted Execution Environment) is a trusted oracle, there is essentially no need to consider the issue of oracle tampering with data. However, this method has high hardware requirements, and when vulnerabilities in the TEE itself occur, they are difficult to repair in a short period of time, resulting in significant losses.

[0008] The Chinese patent application number 202010048747.X, entitled "Cross-chain Method and Apparatus for Homogeneous Consortium Chains Based on Fabric Architecture," incorporates cryptographic digital signature technology to ensure data authenticity and consistency between two homogeneous Fabric consortium chains during the cross-chain process. However, this solution primarily proposes a cross-chain consortium chain method based on the Hyperledger Fabric architecture. This method involves cross-chaining between homogeneous chains. Due to the shared underlying architecture of the blockchains, the technical difficulty of cross-chaining is greatly reduced. Furthermore, Hyperledger Fabric's architecture includes channels, allowing data interoperability between different channels through built-in methods, similar to the principle of cross-chaining between homogeneous chains. Therefore, this method is not practical.

[0009] Therefore, current cross-chain solutions at home and abroad are still in the exploratory stage. Most cross-chain interconnection solutions are mainly based on cross-chain asset replacement and decentralized storage, which cannot be regulated. They have high hardware requirements and lack of practicality, and cannot yet be well used by users. Summary of the Invention

[0010] The present invention provides a blockchain interconnection method, device, and storage medium based on an oracle for cross-chain asset replacement scenarios, so as to realize controllable and reliable cross-chain asset transactions.

[0011] In order to achieve the above object, the present invention adopts the following scheme:

[0012] According to one aspect of an embodiment of the present invention, a blockchain interconnection method based on an oracle for a cross-chain asset swap scenario is provided, comprising:

[0013] The oracle master node listens to the cross-chain request events triggered by the source blockchain and receives the corresponding cross-chain request messages;

[0014] The oracle master node performs a threshold signature on the cross-chain request message to obtain a prepare request message, and sends the prepare request message to multiple oracle supervisory nodes and multiple oracle ordinary nodes;

[0015] Each oracle supervisory node performs a threshold signature on the received prepare request message to obtain a first request message to be aggregated, and sends the first request message to be aggregated to the remaining oracle supervisory nodes; each oracle ordinary node performs a threshold signature on the received prepare request message to obtain a second request message to be aggregated, and sends the second request message to be aggregated to the remaining oracle ordinary nodes;

[0016] Each oracle supervisory node verifies the cross-chain request content in each received first request message to be aggregated based on the received preparation request message, and when the total number of the threshold signature in the preparation request message received by the corresponding oracle supervisory node and the threshold signature in the collected and verified first request message to be aggregated reaches a first set number, the threshold signature in the preparation request message received by the corresponding oracle supervisory node and the threshold signature in the verified first request message to be aggregated are aggregated to obtain a first aggregated signature; each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated based on the received preparation request message, and when the total number of the threshold signature in the preparation request message received by the corresponding oracle ordinary node and the threshold signature in the collected and verified second request message to be aggregated reaches a second set number, the threshold signature in the preparation request message received by the corresponding oracle ordinary node and the threshold signature in the verified second request message to be aggregated are aggregated to obtain a second aggregated signature;

[0017] The oracle supervisory node verifies the compliance of the cross-chain request content in the preparation request message or the first request message to be aggregated, and generates a first aggregated message based on the compliance verification result, the cross-chain request message and the first aggregated signature; the first oracle supervisory node to obtain the first aggregated signature sends the first aggregated message to the destination blockchain; a second aggregated message is generated based on the cross-chain request message and the second aggregated signature, and the first oracle ordinary node to obtain the second aggregated signature sends the second aggregated message to the destination blockchain;

[0018] Verify the validity of the first aggregated signature in the first aggregated message, the cross-chain request message in the first aggregated message, the second aggregated signature in the second aggregated message, and the cross-chain request message in the second aggregated message, and execute the cross-chain transaction based on the verification results.

[0019] According to another aspect of an embodiment of the present invention, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method described in any of the above embodiments when executing the program.

[0020] According to another aspect of the embodiments of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0021] The oracle-based cross-chain asset transaction method, computer device, and storage medium of the embodiments of the present invention construct a decentralized oracle network through multiple oracle nodes. Compared with trusted oracle networks, this method does not require more sophisticated hardware and improves the credibility of cross-chain transactions. The provision of oracle supervisory nodes enables the supervision of cross-chain transactions. Therefore, the present invention enables controllable and reliable cross-chain asset transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0023] Figure 1 This is a flowchart of a cross-chain asset transaction method based on an oracle according to an embodiment of the present invention;

[0024] Figures 2 to 4 This is a flowchart of a cross-chain asset transaction method based on an oracle according to a specific embodiment of the present invention;

[0025] Figure 5 The figure is a flowchart of an improved PBFT algorithm based on threshold signatures in one embodiment of the present invention. DETAILED DESCRIPTION

[0026] To make the purpose, technical solutions and advantages of the embodiments of the present invention more clear, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings. Here, the exemplary embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0027] It should be noted in advance that the descriptions of the following embodiments or examples or the features mentioned therein can be combined with the features of other embodiments or examples in the same or similar manner, or replace the features of other embodiments or examples to form possible implementations. In addition, the term "include / comprise" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence of one or more other features, elements, steps, or components.

[0028] Because blockchains require multiple nodes to jointly store network data, they can only execute predetermined results within their operating environment and cannot actively interact with the outside world. The medium for blockchain-user interaction is smart contracts. Due to the nature of blockchain, smart contracts can only automatically execute predetermined results according to pre-defined rules. To address this issue, this paper introduces oracles to break down the barriers between blockchains and the outside world. Cross-chain oracles enable cross-blockchain transactions. Oracles are categorized as cross-chain oracles, computation oracles, and data oracles. Computation oracles offload computational tasks from the blockchain to off-chain nodes, which then compute and return the results to the blockchain, thereby alleviating the computational load on the blockchain. Data oracles introduce real-world data to the blockchain, enabling real-time interaction between the blockchain and the outside world.

[0029] This invention focuses on the asset replacement scenario in the cross-chain process, which requires ensuring the following three characteristics: transaction authenticity, transaction atomicity, and transaction consistency.

[0030] Transaction authenticity: This ensures that cross-chain transactions actually exist on the source blockchain, meaning that cross-chain transaction requests must be agreed upon by the source blockchain nodes. By monitoring oracle contract transaction events on both the source and destination blockchains, this method ensures that cross-chain requests initiated by the source blockchain and cross-chain received requests executed by the destination blockchain are authentic.

[0031] Transaction atomicity: This ensures that transactions on the source and destination blockchains occur or fail simultaneously. Specifically, when a source blockchain initiates a cross-chain transaction request, if the destination blockchain successfully executes the cross-chain transaction, the source blockchain's assets are permanently locked; if the destination blockchain fails, the source blockchain's assets are returned. This invention utilizes a two-stage consensus mechanism to ensure that cross-chain transactions are fed back to the source blockchain after execution on the destination blockchain, ensuring that assets are returned if a transaction fails on the destination blockchain. Furthermore, this embodiment ensures transaction atomicity by setting a timer for cross-chain transaction execution, ensuring that assets are returned if the source blockchain fails to receive a cross-chain callback request for an extended period.

[0032] Transaction consistency: This ensures that the oracle network reaches consensus on cross-chain transactions. This means that if the assets on the source blockchain increase or decrease by a certain amount, the assets on the destination blockchain will decrease or increase by the same amount. This embodiment, based on PBFT and a threshold signature algorithm, requires a dual consensus from both the oracle supervisory nodes and the oracle regular nodes in the oracle network before cross-chain transactions can be executed, ensuring the consistency and legitimacy of cross-chain transactions.

[0033] Based on the analysis of the above three characteristics, this embodiment innovatively introduces oracles to address cross-chain interoperability in asset swap scenarios. It also ensures the reliability of cross-chain transactions through an optimized consensus algorithm based on PBFT and threshold signatures. Furthermore, by building a multi-role governance model within the oracle network, cross-chain transactions are manageable and controllable.

[0034] Figure 1 This is a flowchart of a blockchain interconnection method based on an oracle, or a cross-chain asset transaction method, according to an embodiment of the present invention. Figure 1 As shown, the oracle-based cross-chain asset transaction method of this embodiment may include the following steps S110 to S190.

[0035] It should be noted that various embodiments of the present invention may involve oracle master nodes, oracle supervisory nodes, and oracle common nodes. There may be multiple oracle supervisory nodes and oracle common nodes. Oracle supervisory nodes can be used by regulatory authorities to manage and control messages. Unlike oracle supervisory nodes, common oracle nodes may not have management and control functions. Furthermore, oracle master nodes can be rotated with common oracle nodes. For example, if an oracle master node encounters a problem and cannot function properly or reaches its set term, a node from among the common oracle nodes can be selected to replace the original oracle master node, and the original oracle master node can become an oracle common node.

[0036] The specific implementation of steps S110 to S190 will be described in detail below.

[0037] Step S110: The oracle master node monitors the cross-chain request event triggered by the source blockchain and receives the corresponding cross-chain request message.

[0038] Furthermore, the method of the embodiments of the present invention can be connected to an existing source asset contract via a source oracle contract, or by writing the required connection information into the existing source asset contract. In short, on the source blockchain side, the oracle contract and the original source asset contract or the improved source asset contract can be connected to the oracle based on the embodiments of the present invention.

[0039] Exemplarily, before step S110, that is, before the oracle master node monitors the cross-chain request event triggered by the source blockchain and receives the corresponding cross-chain request message, Figure 1 The method shown may also include the steps of: S1100, calling the source oracle contract through the source asset contract to send a cross-chain request message to the source blockchain network based on the initial cross-chain request initiated by the account of the source blockchain to the source asset contract, thereby causing the source blockchain network to trigger a cross-chain request event; S1110, using the source oracle contract to receive the cross-chain transaction identifier returned by the source blockchain network based on the cross-chain request message, and forwarding it to the account of the source blockchain via the source asset contract.

[0040] In step S1100, when the source blockchain account initiates an initial cross-chain request to the source asset contract, the corresponding assets in the source blockchain account may be locked simultaneously. The initial cross-chain request may include cross-chain request content, cross-chain request summary, cross-chain operation, timestamp, source blockchain identifier, and destination blockchain identifier.

[0041] In step S1110, the source oracle contract acts as an interface, forwarding the cross-chain transaction identifier (cross-chain transaction ID) returned by the source blockchain network to the account end of the source blockchain via the source asset contract.

[0042] In this embodiment, the source oracle contract can serve as an interface for the source asset contract to call, and the method of the embodiment of the present invention is used to implement cross-chain transactions without affecting the original source asset contract, which is easy to use.

[0043] Step S120: The oracle master node performs a threshold signature on the cross-chain request message to obtain a prepare request message, and sends the prepare request message to multiple oracle supervisory nodes and multiple oracle ordinary nodes.

[0044] In step S120, the oracle supervisory node can be used by the regulatory authorities to supervise transactions and can be considered to be more secure, so its number can be small, and the number of oracle ordinary nodes can be large. The oracle master node uses the threshold signature technology (BLS algorithm (Boneh-Lynn-Shacham algorithm)) to threshold-sign the cross-chain request message. This threshold signature can play a voting role in the subsequent message aggregation process. The cross-chain request message may include the cross-chain request content, cross-chain request summary, cross-chain operation, timestamp, source blockchain identifier, and destination blockchain identifier. The prepare request message may include the cross-chain request message, cross-chain request summary, oracle master node identifier, cross-chain request identifier, the oracle master node's threshold signature on the cross-chain request message, and the public key corresponding to the oracle master node's threshold signature on the cross-chain request message. The cross-chain request message in the prepare request message may be the aforementioned cross-chain request message; the cross-chain request digest in the prepare request message may be extracted from the cross-chain request message; the oracle master node identifier refers to the identifier of the current oracle master node (such as a view number); and the cross-chain request identifier (which may be a cross-chain request sequence number) may be generated by the oracle master node. The threshold signature may be obtained by first generating a private key and a public key, and then signing the private key using a threshold signature algorithm.

[0045] In a specific implementation, the preparation request message may be sent via broadcast. In this case, in the above step S120, sending the preparation request message to multiple oracle supervisory nodes and multiple oracle common nodes may specifically include the step of: S1211, broadcasting the preparation request message to multiple oracle supervisory nodes and multiple oracle common nodes.

[0046] In other embodiments, the preparation request message may be sent using other communication methods.

[0047] In a specific implementation, not only threshold signatures can be performed, but also ordinary signatures can be performed. Ordinary signatures can indicate the identity information of the node. In this case, in the above step S120, the oracle master node performs a threshold signature on the cross-chain request message to obtain a prepare request message, which may specifically include the following step: S1212, the oracle master node performs a threshold signature on the cross-chain request message and appends its own signature to obtain a prepare request message.

[0048] In this embodiment, the oracle supervisory node and the oracle ordinary node can be informed of the information of the oracle master node through signature.

[0049] Step S130: Each oracle supervisory node performs a threshold signature on the received preparation request message to obtain a first request message to be aggregated, and sends the first request message to be aggregated to the remaining oracle supervisory nodes.

[0050] Step S140: Each oracle common node performs a threshold signature on the received preparation request message to obtain a second request message to be aggregated, and sends the second request message to be aggregated to the remaining oracle common nodes.

[0051] In step S130 above, the first request message to be aggregated may include the cross-chain request content, the threshold signature of the corresponding oracle supervisory node on the cross-chain request message, and the public key corresponding to the threshold signature of the corresponding oracle supervisory node on the cross-chain request message. In step S140 above, the second request message to be aggregated may include the cross-chain request content, the threshold signature of the corresponding oracle ordinary node on the cross-chain request message, and the public key corresponding to the threshold signature of the corresponding oracle ordinary node on the cross-chain request message.

[0052] Each oracle supervisory node and each oracle common node can receive the prepare request message sent by the oracle master node. Each of all oracle supervisory nodes and all oracle common nodes can use a method similar to step S120 above to threshold-sign the prepare request message it receives to obtain a message to be aggregated. The message to be aggregated can be sent to other nodes of the same type. For example, each oracle supervisory node sends the first aggregate request message obtained by its threshold signature to the remaining oracle supervisory nodes, and each oracle common node sends the second request message to be aggregated obtained by its threshold signature to the remaining oracle common nodes.

[0053] In a specific implementation, the preparation request message can be sent via broadcast. In this case, in step S130, the first request message to be aggregated is sent to the remaining oracle supervisory nodes, which may specifically include the step of: S1311, broadcasting the first request message to be aggregated to the remaining oracle supervisory nodes. In other embodiments, in step S140, the second request message to be aggregated is sent to the remaining oracle ordinary nodes, which may specifically include the step of: S1411, broadcasting the second request message to be aggregated to the remaining oracle ordinary nodes.

[0054] In other embodiments, the oracle supervisory node / oracle ordinary node may use other communication methods to send a preparation request message to the remaining oracle supervisory nodes / the remaining oracle ordinary nodes.

[0055] During specific implementation, not only threshold signatures can be performed, but also ordinary signatures can be performed, and ordinary signatures can indicate the identity information of the node. In this case, in the above-mentioned step S130, each oracle supervisory node performs a threshold signature on the received preparation request message to obtain a first request message to be aggregated, which may specifically include the steps: S1312, each oracle supervisory node performs a threshold signature on the received preparation request message, and appends the signature of the corresponding oracle supervisory node to obtain the first request message to be aggregated. In other embodiments, in the above-mentioned step S130, each oracle ordinary node performs a threshold signature on the received preparation request message to obtain a second request message to be aggregated, which may specifically include the steps: S1412, each oracle ordinary node performs a threshold signature on the received preparation request message, and appends the signature of the corresponding oracle ordinary node to obtain a second request message to be aggregated.

[0056] In these embodiments, the signature can be used to allow the other oracle supervisory nodes / other oracle ordinary nodes to know the information of the oracle supervisory node / oracle ordinary node that sends the message.

[0057] Step S150: Each oracle supervisory node verifies the cross-chain request content in each received first request message to be aggregated based on the received preparation request message. When the total number of the threshold signatures in the preparation request message received by the corresponding oracle supervisory node and the threshold signatures in the collected verified first request message to be aggregated reaches a first set number, the threshold signatures in the preparation request message received by the corresponding oracle supervisory node and the threshold signatures in the verified first request message to be aggregated are aggregated to obtain a first aggregated signature.

[0058] Step S160: Each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated based on the received preparation request message, and when the total number of the threshold signatures in the preparation request message received by the corresponding oracle ordinary node and the threshold signatures in the collected verified second request message to be aggregated reaches a second set number, the threshold signatures in the preparation request message received by the corresponding oracle ordinary node and the threshold signatures in the verified second request message to be aggregated are aggregated to obtain a second aggregated signature.

[0059] In the above step S150, the oracle supervisory node can verify the cross-chain request content by comparing the preparation request message received from the oracle master node with the first request message to be aggregated received from other oracle supervisory nodes, such as comparing the message content or related content. If they are consistent, it can be considered that the first request message to be aggregated sent by the corresponding oracle supervisory node can participate in the aggregation. If not, it can be considered that it cannot participate in the aggregation. When the number of verified first request messages to be aggregated reaches a certain number, its threshold signature can be aggregated, or the threshold signature can be aggregated together with the preparation request message received by the oracle supervisory node from the oracle master node. The first set number can be determined by the threshold in the threshold signature algorithm.

[0060] In step S160, the oracle normal node collects the second request messages to be aggregated sent from other oracle normal nodes and can verify the received messages similarly to the oracle supervisory node. When the number of messages that pass the verification reaches a certain number, such as the number of second request messages to be aggregated or the total number of prepare messages and second request messages to be aggregated, the threshold signature can be aggregated. The main difference here is that the oracle supervisory node aggregates the messages collected from other oracle supervisory nodes, while the oracle normal node aggregates the messages collected from other oracle normal nodes.

[0061] In specific implementation, the message content can be verified by comparing the consistency of the digests.

[0062] Exemplarily, in the above-mentioned step S150, each oracle supervisory node verifies the cross-chain request content in each received first request message to be aggregated based on the received preparation request message, which may specifically include the step: S1511, each oracle supervisory node verifies the cross-chain request content in the first request message to be aggregated by determining whether the cross-chain request summary in the received preparation request message is consistent with the cross-chain request summary in the received first request message to be aggregated.

[0063] Exemplarily, in the above-mentioned step S160, each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated based on the received preparation request message, which may specifically include the step: S1611, each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated by judging whether the cross-chain request digest in the received preparation request message is consistent with the cross-chain request digest in the received second request message to be aggregated.

[0064] In these embodiments, verification is performed by comparing digests, which can make the verification process faster.

[0065] In specific implementations, when a message is attached with a common signature, the signature can be verified to verify the identity of the node from which the message originated. Existing methods can be used to sign and verify the signature.

[0066] Exemplarily, in the above-mentioned step S150, each oracle supervisory node verifies the cross-chain request content in each received first request message to be aggregated based on the received preparation request message, which may specifically include the step: S1512, each oracle supervisory node verifies the cross-chain request content in each received first request message to be aggregated based on the received preparation request message, and verifies the signature of the corresponding oracle supervisory node in each first request message to be aggregated. When the cross-chain request content in the first request message to be aggregated and the signature of the corresponding oracle supervisory node itself are both verified, the corresponding first request message to be aggregated is considered to have been verified.

[0067] For another example, in the above-mentioned step S160, each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated according to the received preparation request message, which may specifically include the step: S1612, each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated according to the received preparation request message, and verifies the signature of the corresponding oracle ordinary node in each second request message to be aggregated. When the cross-chain request content in the second request message to be aggregated and the signature of the corresponding oracle ordinary node are both verified, the corresponding second request message to be aggregated is considered to have been verified.

[0068] Step S170: The oracle supervisory node verifies the compliance of the cross-chain request content in the preparation request message or the first request message to be aggregated, and generates a first aggregated message based on the compliance verification result, the cross-chain request message and the first aggregated signature; the oracle supervisory node that first obtains the first aggregated signature sends the first aggregated message to the destination blockchain.

[0069] Step S180: Generate a second aggregated message based on the cross-chain request message and the second aggregated signature, and the first oracle ordinary node to obtain the second aggregated signature sends the second aggregated message to the destination blockchain.

[0070] In the above step S170, the oracle supervisory node can perform compliance verification on the content of the cross-chain request message in the received preparation request message or any of the first request messages to be aggregated. For example, it can determine whether the content of the cross-chain request message complies with the requirements of certain rules. The rules can be determined by the regulatory authorities. If it does not comply with the rules, it can be considered non-compliant. If it complies, it can be considered compliant. Therefore, these oracle supervisory nodes can be used by the regulatory authorities to control the content of asset transactions. If the compliance verification result is non-compliant, the first aggregated message obtained can be controlled accordingly so that the transaction cannot be completed, such as returning the assets of the source blockchain account; if the compliance verification result is compliant, the first aggregated message obtained can be used to complete the transaction according to the original transaction process. In addition, each oracle supervisory node collects messages and performs verification and aggregation. The first oracle supervisory node to complete these operations can send the corresponding aggregated message.

[0071] In the above step S180, the oracle machine's ordinary nodes do not need to perform compliance verification operations. The first node that completes message collection and verification and aggregation can send the corresponding aggregated message.

[0072] Step S190: Verify the validity of the first aggregated signature in the first aggregated message, the cross-chain request message in the first aggregated message, the second aggregated signature in the second aggregated message, and the cross-chain request message in the second aggregated message, and execute the cross-chain transaction based on the verification results.

[0073] In the above step S190, after obtaining the first aggregated message of an oracle supervisory node and the second aggregated message of an oracle ordinary node, the validity of the message content and the aggregated signature can be verified to verify the consensus of the oracle supervisory node and the oracle ordinary node. The existing consensus algorithm can be used for verification. If the verification fails, the transaction can be rejected. If the verification passes and the oracle consensus cross-chain request transaction is completed, the cross-chain transaction process such as the destination blockchain executing the cross-chain transaction, the oracle consensus cross-chain callback transaction, and the source blockchain callback request can be continued. The oracle consensus cross-chain request transaction process can be connected with the existing source blockchain initiating cross-chain transactions and the destination blockchain executing cross-chain transactions through an interface (such as the source / destination oracle contract). The oracle consensus cross-chain callback transaction process can be similar to the oracle consensus cross-chain request transaction process, or it can be implemented by randomly selecting a node. The authenticity of the transaction is ensured through the consensus of the nodes.

[0074] In specific implementation, the above step S190, i.e., verifying the validity of the first post-aggregation signature in the first post-aggregation message, the cross-chain request message in the first post-aggregation message, the second post-aggregation signature in the second post-aggregation message, and the cross-chain request message in the second post-aggregation message, and executing the cross-chain transaction according to the verification result, may specifically include: S191, using the destination oracle contract to respectively verify the validity of the first post-aggregation signature in the first post-aggregation message and the second post-aggregation signature in the second post-aggregation message, and verifying the validity of the cross-chain request message in the first post-aggregation message and the cross-chain request message in the second post-aggregation message by judging the consistency of the cross-chain request content in the cross-chain request message in the first post-aggregation message and the cross-chain request message in the second post-aggregation message; S192, if the verification result is valid, The destination oracle contract is used to call the destination asset contract to send a regulated cross-chain request message to the destination blockchain network according to the first aggregated message, so that when the compliance verification result in the regulated cross-chain request message is compliant, the destination blockchain network increases the assets of the account of the destination blockchain according to the regulated cross-chain request message, receives the asset increase operation result, triggers a cross-chain receive event and sends a cross-chain receive message according to the asset increase operation result and the regulated cross-chain request message, or, when the compliance verification result in the regulated cross-chain request message is non-compliant, causes the destination blockchain network to trigger a cross-chain receive event and send a cross-chain receive message according to the regulated cross-chain request message; and executes a cross-chain callback transaction based on the cross-chain receive event and the cross-chain receive message.

[0075] In step S192, the cross-chain received message may include cross-chain received content, a cross-chain received summary, a cross-chain operation, a timestamp, a source blockchain identifier, and a destination blockchain identifier. The cross-chain received content may include information regarding whether to permanently lock the corresponding assets in the source blockchain account, thereby determining whether to allow the asset transaction to be completed. Cross-chain callback transactions may include processes such as oracle consensus cross-chain callback transactions and source blockchain cross-chain callback requests. If the compliance verification result is compliant, the asset change operation in the destination blockchain account may be allowed. The cross-chain received message may include information such as not to proceed with the transaction, resulting in a refund to the source blockchain account. If the compliance verification result is non-compliant, the asset change operation may not be performed. The cross-chain received message may also include information regarding permanently locking the corresponding assets in the source blockchain account. Locking the corresponding assets in the source blockchain account and adding the corresponding assets to the destination blockchain account ensures the consistency of assets in transactions across different blockchains.

[0076] Furthermore, in the above step S192, executing a cross-chain callback transaction based on the cross-chain received event and the cross-chain received message may specifically include the following steps:

[0077] S1921, the oracle master node monitors the cross-chain reception event triggered by the destination blockchain and receives the corresponding cross-chain reception message;

[0078] S1922: The oracle master node performs a threshold signature on the cross-chain received message to obtain a ready-to-receive message, and sends the ready-to-receive message to multiple oracle supervisory nodes and multiple oracle ordinary nodes.

[0079] S1923, each oracle supervisory node performs a threshold signature on the received ready-to-receive message to obtain a first to-be-aggregated received message, and sends the first to-be-aggregated received message to the remaining oracle supervisory nodes;

[0080] S1924, each oracle common node performs a threshold signature on the received ready-to-receive message to obtain a second to-be-aggregated received message, and sends the second to-be-aggregated received message to the remaining oracle common nodes;

[0081] S1925, each oracle supervisory node verifies the cross-chain reception content in each received first to-be-aggregated reception message according to the received ready-to-receive message, and when the total number of the threshold signatures in the ready-to-receive message received by the corresponding oracle supervisory node and the threshold signatures in the collected verified first to-be-aggregated reception messages reaches a first set number, the threshold signatures in the ready-to-receive message received by the corresponding oracle supervisory node and the threshold signatures in the verified first to-be-aggregated reception messages are aggregated to obtain a third aggregated signature;

[0082] S1926, each oracle ordinary node verifies the cross-chain reception content in each received second reception message to be aggregated according to the received ready-to-receive message, and when the total number of the threshold signature in the ready-to-receive message received by the corresponding oracle ordinary node and the threshold signature in the collected verified second reception message to be aggregated reaches a second set number, the threshold signature in the ready-to-receive message received by the corresponding oracle ordinary node and the threshold signature in the verified second reception message to be aggregated are aggregated to obtain a fourth aggregated signature;

[0083] S1927: Generate a third aggregated message based on the cross-chain received message and the third aggregated signature. The oracle supervisory node that first obtains the third aggregated signature sends the third aggregated message to the source blockchain.

[0084] S1928: Generate a fourth aggregated message based on the cross-chain received message and the fourth aggregated signature. The first oracle ordinary node to obtain the fourth aggregated signature sends the fourth aggregated message to the source blockchain.

[0085] S1929, verify the validity of the third post-aggregation signature in the third post-aggregation message, the cross-chain received message in the third post-aggregation message, the fourth post-aggregation signature in the fourth post-aggregation message, and the cross-chain received message in the fourth post-aggregation message, so that the source blockchain executes the cross-chain callback transaction according to the verification result.

[0086] The specific implementation of steps S1922 to S1924 can be similar to steps S120 to S140, for example, messages can be sent via broadcast, and a signature can be attached. The cross-chain received content in the cross-chain received message and the to-be-aggregated received message is different from the cross-chain request content in the cross-chain request message and the to-be-aggregated request message, so that the former can perform a callback request operation on the source blockchain side, and the latter can perform a cross-chain request execution operation on the destination blockchain side.

[0087] Steps S1925 and S1926 can be similar to steps S150 and S160, respectively. For example, when the collected messages are signed by the source node, the signature can be verified. For another example, the consistency of the content can be determined by verifying whether the cross-chain received message digests of the prepared-to-receive message received from the oracle master node and the to-be-aggregated received messages received from other nodes of the same type are consistent. In addition, the threshold signature algorithm can be used to verify the threshold signature. The first set number and the second set number can be selected as needed. Threshold signature aggregation can be performed using a similar method.

[0088] The difference between step S1927 and step S170 is that compliance verification may not be performed in step S1927, as verification has already been performed in step S170. Of course, in other embodiments, compliance verification may also be performed in step S1927 using a method similar to step S170. Furthermore, step S1928 may be similar to step S180. The primary difference lies in the different message content depending on the transaction stage.

[0089] In the above step S1929, similar to the above step S190, the source oracle contract or the corresponding code written in the source asset contract can be used to connect the source blockchain with the oracle. The operation process of the source oracle contract or the improved source asset contract is similar. The main difference is that the corresponding operations are different according to the difference in the content of the message at different stages. For example, in step S1929, if the content of the cross-link received message contains relevant information such as non-compliance or failure to add assets to the destination blockchain account, a refund operation (which can be unlocked) can be performed on the source blockchain account. If the content of the cross-link received message shows that the transaction can be carried out, the assets of the source blockchain account can be permanently locked, thereby completing the transaction and ensuring the atomicity of the transaction.

[0090] In the above step S1922, preparing to receive a message may include a cross-link received message, a cross-link received summary, an oracle master node identifier, a cross-link received identifier, a threshold signature of the oracle master node for the cross-link received message, and a public key corresponding to the threshold signature of the oracle master node for the cross-link received message.

[0091] In the above step S1927, the first received message to be aggregated may include the cross-chain received content, the threshold signature of the corresponding oracle supervision node on the cross-chain received message, and the public key corresponding to the threshold signature of the corresponding oracle supervision node on the cross-chain received message.

[0092] In the above step S1928, the second received message to be aggregated may include the cross-chain received content, the threshold signature of the corresponding oracle ordinary node on the cross-chain received message, and the public key corresponding to the threshold signature of the corresponding oracle ordinary node on the cross-chain received message.

[0093] In other embodiments, a node may be selected through competition to execute an oracle consensus cross-chain callback transaction.

[0094] More specifically, the above-mentioned step S1928, i.e., verifying the validity of the third post-aggregation signature in the third post-aggregation message, the cross-chain received message in the third post-aggregation message, the fourth post-aggregation signature in the fourth post-aggregation message, and the cross-chain received message in the fourth post-aggregation message, so that the source blockchain executes the cross-chain callback transaction according to the verification result, may specifically include the steps of: S19281, using the source oracle contract to respectively verify the validity of the third post-aggregation signature in the third post-aggregation message and the fourth post-aggregation signature in the fourth post-aggregation message, and verifying the validity of the cross-chain received message in the third post-aggregation message and the cross-chain received message in the fourth post-aggregation message by judging the consistency of the cross-chain received content in the cross-chain received message in the third post-aggregation message and the cross-chain received message in the fourth post-aggregation message; S19282, when the verification result is valid, the source oracle contract is used to call the source asset contract to send a callback cross-chain request message to the source blockchain network according to the third aggregated message or the fourth aggregated message, so that when the compliance verification result in the callback cross-chain request message is compliant and the asset increase operation result in the callback cross-chain request message is successful, the source blockchain network permanently locks the assets of the source blockchain account corresponding to this cross-chain transaction according to the callback cross-chain request message, or, when the compliance verification result in the callback cross-chain request message is non-compliant or the asset increase operation result in the callback cross-chain request message is failed, the source blockchain network returns the locked assets of the source blockchain account corresponding to this cross-chain transaction.

[0095] In other embodiments, Figure 1 The method may further include the step of selecting a new oracle master node from among the plurality of common oracle nodes to replace the current oracle master node if an abnormality occurs in the oracle master node or the term of the oracle master node expires. This can enhance the security of the oracle master node.

[0096] In addition, an embodiment of the present invention further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method described in any of the above embodiments when executing the program.

[0097] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the method described in any of the above embodiments when executed by a processor.

[0098] The above method is described below in conjunction with a specific embodiment. However, it should be noted that this specific embodiment is only for better illustrating the present application and does not constitute an improper limitation to the present application.

[0099] Figures 2 to 4 This is a flowchart of a cross-chain asset transaction method based on an oracle according to a specific embodiment of the present invention. Figures 2 to 4 The cross-chain oracle interoperability method for cross-chain asset swap scenarios is shown in Figures 2 to 4 The method of this embodiment may include three parts: a source blockchain, an oracle, and a destination blockchain. The source blockchain includes a source asset contract, a source oracle contract, and a source blockchain network; the oracle part includes a source oracle node aggregation, an oracle listening node (oracle master node), an oracle execution node (including an oracle supervisory node and an oracle ordinary node), and a destination oracle node aggregation; the destination blockchain includes a destination blockchain network, a destination oracle contract, and a destination asset contract. In the cross-chain asset swap scenario targeted by the method of this embodiment, users need to have an account in both the source blockchain and the destination blockchain to send and receive assets.

[0100] The oracle-based cross-chain interconnection method of this embodiment can be divided into five stages, which will be described below.

[0101] The first stage is the cross-chain transaction stage initiated by the source blockchain: the user uses the account of the source blockchain to initiate a cross-chain request to the source asset contract and lock the corresponding assets. The source asset contract then calls the source oracle contract to initiate a cross-chain request. The above two cross-chain requests (cross-chain requests, including information about the stages experienced) will be sent to the blockchain network for consensus and return a cross-chain transaction ID (identifier), triggering a cross-chain request event.

[0102] The second stage is the oracle consensus cross-chain request transaction: after the oracle listening node (oracle master node) listens to the cross-chain request event (that is, obtains the cross-chain request), the oracle listening node signs the cross-chain request event and broadcasts the cross-chain request event (cross-chain request) to the oracle execution node (oracle supervision node / oracle ordinary node). The oracle execution node verifies the signature of the cross-chain request event (the signature added by the oracle listening node), and then appends its own signature to the cross-chain request event and broadcasts it to other oracle execution nodes (the remaining oracle supervision nodes / oracle ordinary nodes, the node type is the same as itself).

[0103] The third stage is the destination blockchain executing the cross-chain transaction: the destination oracle node collects the signatures of multiple oracle execution nodes, aggregates and verifies the validity of the signatures (using established rules for verification), and then calls the destination oracle contract to write the transaction based on the verification results; after the destination oracle verifies the validity of the cross-chain request event, it calls the destination asset contract to initiate a cross-chain request, and finally writes the cross-chain transaction to the destination blockchain network. The assets of the destination blockchain account will increase or decrease accordingly, and a cross-chain receipt event will be triggered.

[0104] The fourth stage is the oracle consensus cross-chain callback transaction: the oracle monitoring node monitors the cross-chain reception event (success or failure) of the target blockchain, signs the cross-chain reception event of the chain, and broadcasts it to the oracle execution node; the oracle execution node performs the same operations as the second stage.

[0105] The fifth stage is the execution of the callback request on the source blockchain: the source oracle node collects signatures from multiple oracle execution nodes, aggregates and verifies the validity of the signatures, and then calls the source oracle contract based on the verification results. The source oracle contract then calls the source asset contract to callback the cross-chain request. If the cross-chain request of the source asset contract is successfully executed on the destination blockchain, the corresponding assets of the source blockchain account are permanently locked; otherwise, the corresponding assets are returned to the source blockchain account. If the source blockchain waits for a long time without receiving the callback request, the corresponding assets locked on the source blockchain are unfrozen.

[0106] The cross-chain interconnection process can be completed through the above five stages.

[0107] Since the oracle connects the source blockchain and the destination blockchain, if the oracle uses a single node or a centralized network, it is easy for malicious attackers to shift their targets from the blockchain with high attack costs to the oracle that is easy to attack. Therefore, this embodiment adopts a decentralized oracle network and uses an improved PBFT consensus algorithm (Practical Byzantine Fault Tolerance) based on threshold signatures to ensure that cross-chain transactions require consensus in the oracle network before they can be written to the destination blockchain.

[0108] To ensure manageable and controllable cross-chain transactions, oracle execution nodes are divided into two categories: ordinary oracle execution nodes and oracle supervisory nodes. This ensures that cross-chain transactions require the approval of supervisory nodes before reaching consensus. Since supervisory nodes are operated and maintained by regulatory authorities, this embodiment assumes that supervisory nodes have strong anti-attack capabilities and high security, so only a small number of supervisory nodes are required for maintenance.

[0109] This process corresponds to the consensus algorithm, which involves selecting a master node from the oracle's common nodes. Consensus requires both oracle supervisory node consensus and oracle common node consensus. Oracle nodes include: oracle master nodes (oracle listener nodes) and oracle execution nodes. Oracle execution nodes include: oracle supervisory nodes (multiple) and oracle common nodes (multiple). Figure 5 This is a flowchart of the improved PBFT algorithm based on threshold signature in one embodiment of the present invention, see Figure 5 ,The entire consensus process can be divided into four stages.

[0110] The first stage is the request stage: by monitoring the source blockchain, the oracle master node monitors the cross-chain request event triggered by the source blockchain and receives the cross-chain request message; the cross-chain request message can be expressed as<msg,digest,operation,timestamp,source,dest> , where msg and digest are the cross-chain request content and digest respectively, operation is the specific operation, timestamp is the timestamp, source is the source blockchain identifier, and dest is the destination blockchain identifier.

[0111] The second stage is the preparation stage. After the oracle master node monitors the cross-chain request event of the source blockchain and obtains the cross-chain request message, it performs a threshold signature on the cross-chain request message to obtain the preparation request message and sends the preparation request message to the<request,request.crequest.digest,viewID,seqID,blssig,nodePk> Broadcast to other nodes in the oracle network (oracle supervisory nodes and oracle ordinary nodes), where request and request.crequest.digest are the cross-chain request and its digest, viewID is the view number (the identifier of the oracle master node), seqID is the cross-chain message sequence number, blssig is the threshold signature of the oracle master node for the cross-chain request message, and nodePk is the public key corresponding to the threshold signature of the oracle master node for the cross-chain request message.

[0112] The third phase is the aggregation phase, which consists of two parts: the aggregation of oracle supervisor nodes and the aggregation of ordinary oracle nodes. The aggregation process for both parts is similar, and both types of nodes are collectively referred to as oracle nodes below. The oracle node first verifies the signature of the prepare request message and verifies that the digest of the prepare request message is equal to the digest of the prepare request message received from the oracle master node. It then saves the threshold signature, message content, and oracle node public key of the received prepare message. When the oracle node collects aggregated messages from a certain number of oracle nodes, it verifies and aggregates these messages and message signatures.

[0113] The principle of oracle node aggregation can be described as follows. Aggregation can adopt the threshold signature method. For example, it is known that m signatures can be synthesized into a unique legal signature. Consensus can be reached by obtaining the signature support of a certain number of nodes in the oracle network. Assuming that there are m oracle supervision nodes and n oracle ordinary nodes in the oracle network, the threshold number of signatures required for the oracle supervision node is m1, and the threshold number of signatures required for the oracle ordinary node is n1. Before aggregation, the oracle node first generates the corresponding point g2 on the multiplication curve G2 based on a random large number. Point g2 corresponds to the public key pk and private key sk of the oracle node. Secondly, the private key sk is used to sign the message to generate the point g1 corresponding to the multiplication curve G1. Point g1 is the signature and satisfies the following equation:

[0114] e(P,H(m))=e(G,S) (1)

[0115] Where e() represents the elliptic curve algorithm, P = pk*G, G represents the curve, S = pk*H(m), H(m) is the hash value of the message on the curve, and m is the message to be signed. When the oracle node broadcasts a message, each node needs to sign the message of other nodes, so that its member key is (MK i Represents the key of member i, pk primary represents the private key of the oracle master node, P represents the public key generated based on the private key, i represents the node number, H(P,i) represents the hash of the message of node i, pk j Represents the private key of the oracle supervisory node j, pk l Represents the private key of the oracle ordinary node l). When the number of signatures that meet the threshold (set number) is collected, all signatures are aggregated into a unique signature S threhold ,in, S primary Represents the oracle master node signature, S i Indicates the signature of the oracle supervisory node i, S j Represents the signature of the oracle ordinary node j, aggregating all public keys into a unique public key P threhold ,in, P primary Represents the master node public key, P i represents the public key of node i, P j represents the public key of node j and satisfies the following equation:

[0116] e(G,MK i )=e(P,H(P,i)) (2)

[0117] The fourth stage is the execution stage. The first oracle supervisory node and oracle ordinary node that pass the verification will verify the consensus and address the destination blockchain according to the identifier of the destination blockchain and execute cross-chain transactions.

[0118] After the aggregation is completed, the following equation can be used to verify whether the consensus of the oracle supervisory node and the oracle ordinary node is obtained.

[0119]

[0120] Among them, e(G,S threhold ) represents the result generated by the elliptic curve algorithm based on the threshold signature, H(P,m) represents the hash of the message of node m, e(P threhold ,H(P,m)) represents the result generated by the elliptic curve algorithm based on the hash and public key, primary represents the primary node, H(P,primary) represents the hash generated by the primary node message, e(P primary ,H(P,primary)) represents the result generated by the elliptic curve algorithm based on the primary node public key and message hash, P i represents the public key of node i, H(P,i) represents the hash value of the message of node i, e(P i ,H(P,i)) represents the result generated by the elliptic curve algorithm based on the public key of node i and the message hash, P j represents the public key of node j, H(P,j) represents the hash value of the message of node j, e(P j ,H(P,j)) represents the result generated by the elliptic curve algorithm based on the public key of node j and the message hash, Indicates continuous multiplication from n to n1, Indicates continuous multiplication from m to m1.

[0121] After reaching consensus with the oracle supervisory node and the oracle common node, the destination blockchain will execute the cross-chain transaction to ensure that the cross-chain transaction is successful and controllable.

[0122] The above four stages can complete the consensus of the oracle network.

[0123] In this embodiment, oracles are introduced into the research of cross-chain interconnection and intercommunication, and an oracle-based blockchain controllable interconnection method for cross-chain asset replacement scenarios is proposed. While ensuring the authenticity, atomicity, and eventual consistency of cross-chain asset replacement transactions, cross-chain transactions are supervised to ensure the trustworthiness and controllability of cross-chain transactions. This embodiment introduces cross-chain oracles as intermediaries between blockchains and proposes an oracle cross-chain interconnection method for cross-chain asset replacement scenarios. By building a decentralized oracle network, monitoring contract events of the source / destination blockchains, executing cross-chain transactions on the destination blockchain through an improved PBFT-based oracle network consensus algorithm, and judging whether the corresponding assets of the source blockchain are permanently locked based on the results returned by the destination blockchain, the atomicity of cross-chain transactions is guaranteed. This embodiment solves the cross-blockchain asset replacement scenario by constructing a cross-chain interconnection architecture based on an oracle, uses the time monitoring mechanism of the blockchain network to ensure the authenticity of cross-chain transactions, designs a two-stage consensus to ensure that cross-chain transactions succeed or fail simultaneously on the source blockchain and the destination blockchain, uses a consensus algorithm based on PBFT and threshold signatures to ensure that cross-chain transactions are not tampered with when circulating in the intermediate network, and designs an oracle network multi-role governance model to ensure that cross-chain transactions are regulated.

[0124] In summary, the oracle-based cross-chain asset transaction method, computer device, and storage medium of the embodiments of the present invention construct a decentralized oracle network through multiple oracle nodes. Compared with a trusted oracle network, this method does not require more sophisticated hardware and improves the credibility of cross-chain transactions. The establishment of oracle supervision nodes enables the supervision of cross-chain transactions.

[0125] In the description of this specification, the description with reference to the terms "one embodiment", "a specific embodiment", "some embodiments", "for example", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in an appropriate manner in any one or more embodiments or examples. The order of steps involved in each embodiment is used to schematically illustrate the implementation of the present invention, and the order of steps therein is not limited and can be appropriately adjusted as needed.

[0126] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0127] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0128] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0130] The specific embodiments described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A blockchain interconnection method based on an oracle for cross-chain asset swap scenarios, characterized by: include: The oracle master node listens to the cross-chain request events triggered by the source blockchain and receives the corresponding cross-chain request messages; The oracle master node performs a threshold signature on the cross-chain request message and appends its own signature to obtain a prepare request message, and sends the prepare request message to multiple oracle supervisory nodes and multiple oracle ordinary nodes; Each oracle supervisory node performs a threshold signature on the received prepare request message, appends its own signature, obtains a first request message to be aggregated, and sends the first request message to be aggregated to the remaining oracle supervisory nodes; each oracle ordinary node performs a threshold signature on the received prepare request message, appends its own signature, obtains a second request message to be aggregated, and sends the second request message to be aggregated to the remaining oracle ordinary nodes; Each oracle supervisory node verifies the cross-chain request content in each first request message to be aggregated according to the received preparation request message by comparing the preparation request message received from the oracle master node with the first request messages to be aggregated received from other oracle supervisory nodes. When the total number of the threshold signature in the preparation request message received by the corresponding oracle supervisory node and the threshold signature in the collected verified first request message to be aggregated reaches a first set number, the threshold signature in the preparation request message received by the corresponding oracle supervisory node and the threshold signature in the verified first request message to be aggregated are aggregated to obtain a first aggregated signature; Each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated according to the received preparation request message by comparing the preparation request message received from the oracle master node with the second request messages to be aggregated received from other oracle ordinary nodes, and when the total number of the threshold signature in the preparation request message received by the corresponding oracle ordinary node and the threshold signature in the collected verified second request message to be aggregated reaches a second set number, the threshold signature in the preparation request message received by the corresponding oracle ordinary node and the threshold signature in the verified second request message to be aggregated are aggregated to obtain a second aggregated signature; The oracle supervisory node verifies the compliance of the cross-chain request content in the prepare request message or the first request message to be aggregated, and generates a first aggregated message based on the compliance verification result, the cross-chain request message, and the first aggregated signature; The first oracle supervisory node to obtain the first aggregated signature sends a first aggregated message to the destination blockchain; a second aggregated message is generated based on the cross-chain request message and the second aggregated signature, and the first oracle ordinary node to obtain the second aggregated signature sends the second aggregated message to the destination blockchain; wherein, if the compliance verification result is non-compliant, the first aggregated message makes it impossible to complete the transaction; if the compliance verification result is compliant, the first aggregated message makes it possible to complete the transaction according to the original transaction process; Verify the validity of the first aggregated signature in the first aggregated message, the cross-chain request message in the first aggregated message, the second aggregated signature in the second aggregated message, and the cross-chain request message in the second aggregated message, and execute the cross-chain transaction based on the verification result. When the verification result is valid, the destination oracle contract is used to call the destination asset contract to send a regulated cross-chain request message to the destination blockchain network based on the first aggregated message.

2. The method according to claim 1, wherein Before the oracle master node monitors the cross-chain request event triggered by the source blockchain and receives the corresponding cross-chain request message, the method further includes: The source asset contract calls the source oracle contract to send a cross-chain request message to the source blockchain network based on the initial cross-chain request initiated by the source blockchain account to the source asset contract, thereby triggering a cross-chain request event on the source blockchain network. The source oracle contract is used to receive the cross-chain transaction identifier returned by the source blockchain network based on the cross-chain request message, and forwarded to the account of the source blockchain via the source asset contract.

3. The method according to claim 1, wherein Sending the prepare request message to multiple oracle supervisory nodes and multiple oracle common nodes includes: Broadcasting the preparation request message to multiple oracle supervisory nodes and multiple oracle common nodes; Send the first request message to be aggregated to the remaining oracle supervisory nodes, including: Broadcast the first request message to be aggregated to the remaining oracle supervisory nodes; Send the second to-be-aggregated request message to the remaining oracle common nodes, including: Broadcast the second request message to be aggregated to the remaining oracle common nodes; Each oracle supervisory node verifies the cross-chain request content in each first to-be-aggregated request message based on the received prepare request message, including: Each oracle supervisory node verifies the cross-chain request content in each received first request message to be aggregated based on the received prepare request message, and verifies the signature of the corresponding oracle supervisory node in each first request message to be aggregated. If both the cross-chain request content in the first request message to be aggregated and the signature of the corresponding oracle supervisory node are verified, the corresponding first request message to be aggregated is considered to have passed verification; Each oracle common node verifies the cross-chain request content in each second to-be-aggregated request message received based on the received prepare request message, including: Each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated based on the received preparation request message, and verifies the signature of the corresponding oracle ordinary node in each second request message to be aggregated. If the cross-chain request content in the second request message to be aggregated and the signature of the corresponding oracle ordinary node are both verified, the corresponding second request message to be aggregated is considered to have passed the verification.

4. The method according to claim 1, wherein Each oracle supervisory node verifies the cross-chain request content in each first to-be-aggregated request message received based on the received preparation request message by comparing the preparation request message received from the oracle master node with each first to-be-aggregated request message received from other oracle supervisory nodes, including: Each oracle supervisory node verifies the cross-chain request content in the first request message to be aggregated by determining whether the cross-chain request digest in the received prepare request message is consistent with the cross-chain request digest in the received first request message to be aggregated; Each oracle common node verifies the cross-chain request content in each second request message to be aggregated based on the received preparation request message by comparing the preparation request message received from the oracle master node with each second request message to be aggregated received from other oracle common nodes, including: Each oracle ordinary node verifies the cross-chain request content in each received second request message to be aggregated by determining whether the cross-chain request digest in the received preparation request message is consistent with the cross-chain request digest in the received second request message to be aggregated.

5. The method according to claim 1, wherein Verify the validity of the first aggregated signature in the first aggregated message, the cross-chain request message in the first aggregated message, the second aggregated signature in the second aggregated message, and the cross-chain request message in the second aggregated message, and execute the cross-chain transaction based on the verification results, including: Use the destination oracle contract to verify the validity of the first aggregated signature in the first aggregated message and the second aggregated signature in the second aggregated message, and verify the validity of the cross-chain request message in the first aggregated message and the cross-chain request message in the second aggregated message by judging the consistency of the cross-chain request content in the cross-chain request message in the first aggregated message and the cross-chain request message in the second aggregated message; When the verification result is valid, the destination oracle contract is used to call the destination asset contract to send a regulated cross-chain request message to the destination blockchain network according to the first aggregated message, so that when the compliance verification result in the regulated cross-chain request message is compliant, the destination blockchain network increases the assets of the account of the destination blockchain according to the regulated cross-chain request message, receives the asset increase operation result, triggers a cross-chain receive event and sends a cross-chain receive message according to the asset increase operation result and the regulated cross-chain request message, or, when the compliance verification result in the regulated cross-chain request message is non-compliant, the destination blockchain network triggers a cross-chain receive event and sends a cross-chain receive message according to the regulated cross-chain request message; and executes a cross-chain callback transaction based on the cross-chain receive event and the cross-chain receive message.

6. The method according to claim 5, wherein Execute cross-chain callback transactions based on cross-chain received events and cross-chain received messages, including: The oracle master node monitors the cross-chain reception events triggered by the destination blockchain and receives the corresponding cross-chain reception messages; The oracle master node performs a threshold signature on the cross-chain received message to obtain a ready-to-receive message, and sends the ready-to-receive message to multiple oracle supervisory nodes and multiple oracle ordinary nodes; Each oracle supervisory node performs a threshold signature on the received ready-to-receive message to obtain a first to-be-aggregated receive message, and sends the first to-be-aggregated receive message to the remaining oracle supervisory nodes; each oracle ordinary node performs a threshold signature on the received ready-to-receive message to obtain a second to-be-aggregated receive message, and sends the second to-be-aggregated receive message to the remaining oracle ordinary nodes; Each oracle supervisory node verifies the cross-chain reception content in each received first to-be-aggregated reception message based on the received ready-to-receive message, and when the total number of the threshold signature in the ready-to-receive message received by the corresponding oracle supervisory node and the threshold signature in the collected and verified first to-be-aggregated reception message reaches a first set number, the threshold signature in the ready-to-receive message received by the corresponding oracle supervisory node and the threshold signature in the verified first to-be-aggregated reception message are aggregated to obtain a third aggregated signature; each oracle ordinary node verifies the cross-chain reception content in each received second to-be-aggregated reception message based on the received ready-to-receive message, and when the total number of the threshold signature in the ready-to-receive message received by the corresponding oracle ordinary node and the threshold signature in the collected and verified second to-be-aggregated reception message reaches a second set number, the threshold signature in the ready-to-receive message received by the corresponding oracle ordinary node and the threshold signature in the verified second to-be-aggregated reception message are aggregated to obtain a fourth aggregated signature; A third aggregated message is generated based on the cross-chain received message and the third aggregated signature, and the first oracle supervisory node to obtain the third aggregated signature sends the third aggregated message to the source blockchain; a fourth aggregated message is generated based on the cross-chain received message and the fourth aggregated signature, and the first oracle ordinary node to obtain the fourth aggregated signature sends the fourth aggregated message to the source blockchain; Verify the validity of the third post-aggregation signature in the third post-aggregation message, the cross-chain received message in the third post-aggregation message, the fourth post-aggregation signature in the fourth post-aggregation message, and the cross-chain received message in the fourth post-aggregation message, so that the source blockchain executes the cross-chain callback transaction according to the verification result.

7. The method according to claim 6, wherein Verifying the validity of the third post-aggregation signature in the third post-aggregation message, the cross-chain received message in the third post-aggregation message, the fourth post-aggregation signature in the fourth post-aggregation message, and the cross-chain received message in the fourth post-aggregation message, so that the source blockchain executes a cross-chain callback transaction based on the verification result, including: Using the source oracle contract to verify the validity of the third aggregated signature in the third aggregated message and the fourth aggregated signature in the fourth aggregated message, and verifying the validity of the cross-chain received message in the third aggregated message and the cross-chain received message in the fourth aggregated message by judging the consistency of the cross-chain received content in the cross-chain received message in the third aggregated message and the cross-chain received message in the fourth aggregated message; When the verification result is valid, the source oracle contract is used to call the source asset contract to send a callback cross-chain request message to the source blockchain network according to the third aggregated message or the fourth aggregated message, so that when the compliance verification result in the callback cross-chain request message is compliant and the asset increase operation result in the callback cross-chain request message is successful, the source blockchain network permanently locks the assets of the source blockchain account corresponding to this cross-chain transaction according to the callback cross-chain request message, or, when the compliance verification result in the callback cross-chain request message is non-compliant or the asset increase operation result in the callback cross-chain request message is failed, the source blockchain network returns the locked assets of the source blockchain account corresponding to this cross-chain transaction.

8. The method according to claim 6, wherein The cross-chain request message includes cross-chain request content, cross-chain request summary, cross-chain operation, timestamp, source blockchain identifier, and destination blockchain identifier; The prepare request message includes a cross-chain request message, a cross-chain request summary, an oracle master node identifier, a cross-chain request identifier, a threshold signature of the oracle master node for the cross-chain request message, and a public key corresponding to the threshold signature of the oracle master node for the cross-chain request message; The first request message to be aggregated includes the cross-chain request content, the threshold signature of the corresponding oracle supervisory node on the cross-chain request message, and the public key corresponding to the threshold signature of the corresponding oracle supervisory node on the cross-chain request message; The second request message to be aggregated includes the cross-chain request content, the threshold signature of the corresponding oracle ordinary node on the cross-chain request message, and the public key corresponding to the threshold signature of the corresponding oracle ordinary node on the cross-chain request message; Cross-chain received messages include cross-chain received content, cross-chain received summary, cross-chain operation, timestamp, source blockchain identifier, and destination blockchain identifier; Prepare to receive a message including a cross-chain receive message, a cross-chain receive digest, an oracle master node identifier, a cross-chain receive identifier, a threshold signature of the oracle master node on the cross-chain receive message, and the public key corresponding to the threshold signature of the oracle master node on the cross-chain receive message; The first received message to be aggregated includes the cross-chain received content, the threshold signature of the corresponding oracle supervisory node on the cross-chain received message, and the public key corresponding to the threshold signature of the corresponding oracle supervisory node on the cross-chain received message; The second received message to be aggregated includes the cross-chain received content, the threshold signature of the corresponding oracle ordinary node on the cross-chain received message, and the public key corresponding to the threshold signature of the corresponding oracle ordinary node on the cross-chain received message.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method according to any one of claims 1 to 8 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images