Alliance chain efficient atomicity cross-chain interaction method and system based on distributed digital identity

Abstract

The invention belongs to the technical field of block chains, and particularly relates to an alliance chain efficient atomicity cross-chain interaction method and system based on distributed digital identities. The method comprises the following steps: deploying a cross-chain contract and a cross-chain gateway for alliance chains, and establishing a cross-chain channel between the alliance chains based on the cross-chain contract and the cross-chain gateway; and carrying out cross-chain asset transfer, cross-chain information transmission and cross-chain smart contract calling based on the established cross-chain channel. According to the alliance chain cross-chain interaction method based on the decentralized identity identification, interaction tasks such as cross-chain asset transfer and message passing can be safely and efficiently processed, and cross-chain intelligent contract asynchronous calling with atomicity guarantee can be executed. The historical consensus nodes are tracked through the DID technology, the dependence on a third party is reduced in the cross-chain operation, the decentralization level of the system is further improved, the safety and reliability of the system are remarkably enhanced, and meanwhile the cross-chain interaction efficiency is improved.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to a method and system for efficient atomic cross-chain interaction of consortium blockchains based on distributed digital identity. Background Technology

[0002] Blockchain technology is a distributed database technology that uses encryption to ensure the security and integrity of data. A blockchain consists of a series of data blocks, each containing a set of transaction records and linked to the previous block via a hash value, forming an immutable chain. This structure makes data, once recorded on the blockchain, impossible to easily modify or delete. Blockchain is based on a distributed network, meaning it does not rely on any centralized institution or individual for maintenance. Nodes in the network are responsible for maintaining blocks and agreeing on the addition of new blocks through a consensus mechanism.

[0003] A consortium blockchain is not a completely open blockchain; instead, it is jointly managed and maintained by multiple pre-selected organizations or entities. These organizations jointly determine the governance rules, participating nodes, and access permissions on the chain. Consortium blockchains retain the core characteristics of blockchains, such as decentralization, immutability, and transparency, but compared to public blockchains, they offer improvements in privacy protection and transaction speed because the number of participating nodes is limited and controlled. Consortium blockchains are typically used in specific industry or business scenarios, such as supply chain management, financial services, and healthcare, where participating parties need to share data but do not wish to make it completely public. In a consortium blockchain, each participant can effectively collaborate and exchange information while ensuring data security and privacy.

[0004] Cross-chain technology, also known as inter-chain interoperability, refers to the technology that enables the exchange of data and assets between different blockchains. It solves the problem of blockchain silos, allowing assets and data on different blockchains to be securely and efficiently transferred and interoperated across chains. With the development of blockchain technology, numerous different blockchain networks have emerged, each with its own rules, protocols, and characteristics. Cross-chain technology aims to break down the barriers between these networks, achieving interoperability between different blockchains, thereby creating a more interconnected and flexible blockchain ecosystem.

[0005] The basic mechanisms for achieving cross-chain information transmission and cross-chain asset transfer typically include the following steps:

[0006] 1. Event Trigger: A specific event occurs on chain A, such as the locking of assets, the execution of a smart contract, or the recording of a transaction on the chain.

[0007] 2. Information Proof: Generate a proof that confirms a specific event has occurred on chain A. This proof can be a cryptographic signature, a Merkle proof, etc.

[0008] 3. Cross-chain communication: Transmitting events and related proofs from chain A to chain B. This can be achieved through relay nodes, cross-chain bridges, or other communication protocols.

[0009] 4. Verification and Execution: Nodes on Chain B verify the validity of the event proof received from Chain A. Once verification is successful, Chain B can trigger corresponding operations, such as asset creation or unlocking, or acknowledging the correctness of the message.

[0010] Decentralized Identifier (DID) is an identity authentication mechanism based on blockchain and decentralized technology, designed to provide a more secure, privacy-preserving, and user-controlled method of identity verification. DID returns control of identity information to the user, reducing the risks of centralized storage and improving data security and privacy. By using encryption technology, the DID system ensures that user identity information is protected during transmission and storage. Identity data is no longer centrally stored in a single database or institution, but distributed across a blockchain network, reducing the risk of data tampering or leakage.

[0011] The demand for blockchain cross-chain technology includes:

[0012] 1. Security: Security is the primary consideration in the design of cross-chain technology. Cross-chain transactions involve the transfer of assets and data between different blockchain networks, therefore, the security and immutability of the transaction process must be ensured. Considering the periodic reorganization of consensus nodes in consortium blockchains, the traceability of historical consensus nodes should be guaranteed. The design also needs to consider preventing security threats such as double-spending, fraud, and hacking attacks.

[0013] 2. High Throughput: With the increasing application of blockchain, the demand for cross-chain operations and queries is also constantly growing. High efficiency can improve the system's processing capacity, support more concurrent transactions, and thus enhance the throughput of the entire cross-chain system.

[0014] 3. Interoperability: The core purpose of cross-chain technology is to achieve interoperability between different blockchain networks. The design must ensure compatibility with different blockchain protocols, data formats, and smart contracts, enabling assets and information to be transferred smoothly between different blockchains.

[0015] 4. Scalability: With the increasing number of blockchain applications, cross-chain technology needs to be able to support a large number of transactions and data transfers. The design needs to consider how to optimize the network structure and transaction processing mechanisms to improve the overall system's processing capacity and efficiency.

[0016] 5. Decentralization: Cross-chain technology should maintain the decentralized nature of blockchain and avoid relying on any centralized third-party institutions.

[0017] 6. Consistency: In the face of various abnormal situations, the consistency of cross-chain transactions should be ensured to guarantee the synchronization of data and state between different blockchain networks, thereby ensuring the stability and reliability of the entire cross-chain system.

[0018] 7. Atomicity: Cross-chain transaction mechanisms should guarantee the atomicity of transactions, meaning that either all cross-chain operations on multiple chains succeed, or none of them succeed.

[0019] The paper "sigBridge: A Cross-chain Bridge for Permissioned Blockchains and its application to decentralized access control" proposes a method for cross-chain asset transfer using a cross-chain bridge. This method relies on a relay network to forward cross-chain transactions and proof information. The target chain needs to continuously synchronize the source chain's block headers and maintain a list of source chain block headers. During cross-chain interaction, the source chain needs to provide the target chain with proof of the transaction and the cross-chain transaction itself. The target chain performs cross-chain authentication based on the proof provided by the source chain and its local list of source chain block headers, ensuring the authenticity and correctness of the transaction. While this method can securely perform cross-chain authentication, its reliance on a relay network for message forwarding and the target chain's continuous maintenance of source chain block headers incur additional storage and communication costs. This reliance on a relay chain or centralized bridge node exposes the method to single-point-of-failure risks, reduces the security of the entire cross-chain operation, and creates performance bottlenecks in multi-chain interaction scenarios.

[0020] The paper "A cross-chain identity authentication scheme based on DID" proposes a trusted cross-chain asset transfer method based on DID and Verifiable Credentials (VC). Existing cross-chain asset exchange methods (such as hash time locks, notarization schemes, and sidechains) suffer from a lack of proper regulation and inefficiency. This method uses DID to establish a unified cross-chain digital identity system and leverages VC to achieve unified trusted verification of cross-chain assets. The method uses a relay chain to store DID documents and forward cross-chain transactions and proofs. However, storing DID documents on the relay chain introduces centralization risks. Furthermore, the relay chain is located on the critical path of all cross-chain transactions, resulting in significant processing pressure on the relay chain and impacting the overall system performance.

[0021] Patent CN117614640A (Blockchain Cross-Chain System and Method Based on Distributed Identity) proposes a blockchain cross-chain system and method based on distributed identity. This patent employs a distributed authentication mechanism to authenticate user identities. Each node participating in cross-chain communication verifies the identity of the user initiating the cross-chain call, improving the security of cross-chain communication, achieving compatibility with different blockchain systems, and ensuring the atomicity of cross-chain transactions. However, this scheme uses a unified distributed authentication network, requiring all users on the blockchain to register their identities on the same network. During the authentication process, verification requests need to be made to the authentication network. This approach still carries the risk of centralization, increasing the system's vulnerability.

[0022] Patent CN117596250A (A Cross-Chain Interaction Method Based on Multiple Blockchain Networks) relates to a cross-chain interaction method based on multiple blockchain networks. This patent designs a P2P network topology for several blockchain networks to obtain a cross-chain interaction system. These blockchain networks, after design, become member blockchains in the cross-chain interaction system. A regulatory body is established within the cross-chain interaction system to oversee cross-chain interactions between member blockchains. This patent enables cross-chain interactions between member blockchains without the need for a relay blockchain for coordination, reducing the cost of maintaining the blockchain environment. Simultaneously, the regulatory body effectively supervises information exchange between member blockchains, improving the compliance of cross-chain interactions. However, this solution relies on communication nodes to listen to cross-chain transactions and generate verification information, still exhibiting a dependence on third-party nodes.

[0023] Patent CN113179168B (A Cross-Chain Interaction Method for Blockchains) designs a cross-chain interaction method for blockchains. This method includes a sending chain initiating a cross-chain transaction, calling the `send` strategy in a smart contract to generate a locked asset transaction TX1 on the sending chain; a notary group signs the locked asset transaction TX1, and when the signature ratio of the transacting parties reaches the expected level and the transaction expiration time has not exceeded, the notary calls the `receive` strategy in the smart contract to generate a cross-chain transaction TX2 corresponding to TX1 and sends it to the receiving chain. This invention utilizes a notary group mechanism combined with smart contracts to achieve cross-chain interaction, enabling cross-chain transactions between different blockchains. The coordination of notaries is more efficient and not limited by time. However, this method also relies on third-party notaries to complete the cross-chain operation, introducing dependence on third-party notaries, which is detrimental to the decentralization of the system.

[0024] Patent CN112579700B (A Cross-Chain Transaction Processing Method and Apparatus) relates to a cross-chain transaction processing method and apparatus. The method is applicable to cross-chain transactions involving N+1 participants on M+1 blockchains, where N and M are both positive integers, and N is greater than or equal to M. Specifically, if a first participant determines that the transaction triggering conditions for the cross-chain transfer transaction to be executed on the M+1 blockchains are all preset transaction triggering conditions, then for each of the M+1 blockchains, a target smart contract on that blockchain is invoked according to the first transaction triggering parameter of the first transaction triggering transaction. After the target smart contract is successfully invoked, the transaction triggering transaction corresponding to the preset transaction triggering conditions on that blockchain is executed.

[0025] Currently, cross-chain solutions utilizing relay nodes or relay chains are two mainstream approaches to cross-chain technology implementation. However, each has its own drawbacks, including security risks, trust issues, performance bottlenecks, technical complexity, and centralization risks. Centralized nodes can become targets of attacks; once these nodes are compromised, the security of the entire cross-chain system will be threatened. While using relay chains can prevent the compromise of individual nodes to some extent, it still carries a certain degree of centralization risk. Users need to trust the operators of relay nodes and relay chains, which contradicts the decentralized spirit of blockchain. Relay nodes and relay chains are located on the critical path of cross-chain transactions, which may become performance bottlenecks, affecting the processing speed and efficiency of cross-chain transactions. Building and maintaining relay chains requires high technical complexity, placing high demands on the development and operation teams.

[0026] Furthermore, changes in consensus nodes in consortium blockchains pose challenges to the verification of historical block headers. Periodic reorganization of consensus nodes is a common practice in consortium blockchains, designed to enhance network security and decentralization. Regularly replacing consensus nodes prevents potential malicious actors from gaining long-term control of nodes, thereby reducing the risk of network attacks. If consensus nodes change frequently, it may be necessary to track the specific consensus node state at the time each block is verified. Changes in consensus nodes need to be recorded on the blockchain and referenced when verifying historical blocks to ensure network transparency and traceability.

[0027] Traditional methods require maintaining a list of block headers from the source chain on the target chain to verify the authenticity and reliability of cross-chain transactions. However, this introduces additional storage and communication costs. As the number of blockchains in the system increases with business scale, the process of maintaining the block header list can lead to severe performance bottlenecks.

[0028] Current cross-chain smart contract invocation schemes cannot guarantee the global atomicity of cross-chain transactions. This means that all smart contracts invoked within the same cross-chain transaction must either execute successfully or fail completely. This is crucial for ensuring the correctness and security of cross-chain transaction execution. Furthermore, in the face of various anomalies, cross-chain smart contract invocation schemes should ensure the consistency of cross-chain transactions and guarantee the synchronization of data and state between different blockchain networks. Summary of the Invention

[0029] To address the aforementioned problems, this invention provides a highly efficient and atomic cross-chain interaction method for consortium blockchains based on distributed digital identity. This solution's cross-chain technology can continuously improve system performance and scalability while maintaining decentralization, and can guarantee the consistency and atomicity of cross-chain transactions, ensuring the security and reliability of cross-chain execution results.

[0030] The technical solution adopted in this invention is as follows:

[0031] A method for efficient atomic cross-chain interaction in a consortium blockchain based on distributed digital identity includes the following steps:

[0032] Deploy cross-chain contracts and cross-chain gateways for consortium blockchains, and establish cross-chain channels between consortium blockchains based on cross-chain contracts and cross-chain gateways;

[0033] Cross-chain asset transfer, cross-chain information transmission, and cross-chain smart contract invocation are carried out based on the established cross-chain channels.

[0034] Furthermore, the cross-chain channel is established using the following steps:

[0035] Deploy cross-chain contracts on each consortium blockchain, which contain rules for handling cross-chain messages;

[0036] Deploy a cross-chain gateway for each consortium blockchain, and use the cross-chain gateway to listen for events on the blockchain and determine whether a cross-chain operation needs to be initiated.

[0037] Register the gateway address of the other chain on the cross-chain gateway so that the gateways can discover and communicate with each other;

[0038] Register the corresponding cross-chain events on the cross-chain gateway and assign a unique channel identifier to the cross-chain channel;

[0039] The cross-chain gateway synchronizes the identity information of consensus nodes on each chain, including the consensus node's DID and public key. When a chain receives a block header and transaction from another chain, it verifies the block based on the recorded identity information of the consensus node.

[0040] Furthermore, the cross-chain asset transfer includes two phases: a locking phase and a confirmation phase.

[0041] The locking phase includes: Chain 1 receives a cross-chain transaction to transfer a certain number of tokens 1 from user A in Chain 1 to a certain number of tokens 2 from user B in Chain 2; the smart contract splits this into two sub-transactions, one for locking assets on Chain 1 and the other for distributing assets on Chain 2; Chain 1 executes the locking step, locking a certain number of tokens 1 in A's assets; after the cross-chain gateway detects the execution of the cross-chain sub-transaction, it sends the cross-chain sub-transaction and asset locking proof to Chain 2;

[0042] The determination phase includes: Chain 2 verifies the block header information from Chain 1; Chain 2 uses the block header and Merkle proof to verify whether the locked asset transaction is on Chain 1. If the verification is successful, the trigger contract on the target chain is triggered according to the cross-chain transaction to complete the asset distribution; the cross-chain gateway of Chain 2 generates an on-chain proof and sends it to the cross-chain gateway of Chain 1.

[0043] Furthermore, the cross-chain asset transfer employs an atomicity guarantee strategy, which includes:

[0044] If the locking phase on Chain 1 fails, the cross-chain gateway of Chain 1 cannot send the locking proof to the cross-chain gateway of Chain 2, and both parties eventually return to the state before the cross-chain transaction occurred.

[0045] If the execution of the sub-transaction on Chain 2 fails, the cross-chain gateway of Chain 2 sends a proof of execution failure to the cross-chain gateway of Chain 1, causing Chain 1 to trigger a rollback and return the assets locked by user A to user A.

[0046] If a complete network partition occurs between Chain 1 and Chain 2 while Chain 1 is waiting for the on-chain result from Chain 2, then Chain 1 will neither roll back the incomplete cross-chain transactions nor continue executing the determination phase. After the network recovers, Chain 1 will actively query the execution result on Chain 2 again. Once Chain 1 receives the on-chain proof from Chain 2, it will continue executing the determination phase.

[0047] The cross-chain gateway on Chain 1 maintains a list of cross-chain transactions, recording all cross-chain transactions that have not received proof of successful or failed execution from Chain 2. When Chain 1 receives proof of successful or failed execution of a transaction from Chain 2, it removes the transaction from the cross-chain transaction list. For cross-chain transactions with long waiting times, the cross-chain gateway on Chain 1 actively queries Chain 2 for the execution status of the transaction.

[0048] Furthermore, the cross-chain information transmission includes:

[0049] The information is packaged into the transaction, and then the transaction is uploaded to the source chain.

[0050] Users invoke smart contracts on the source chain to initiate a cross-chain transaction, which is used to transmit cross-chain information and forward the transaction and related information to the target chain through the cross-chain channel. The forwarded information includes: cross-chain transaction, source chain transaction packaged information, block header information, consensus node DID information, and Merkle proof.

[0051] The target chain parses the DID of the consensus node, verifies the identity of the consensus node, and uses the valid consensus node signature to verify the block header information. The target chain uses the block header information and Merkle proof to verify whether the source chain transaction of the packaged information is on the source chain. If the verification is successful, the smart contract on the target chain is triggered according to the cross-chain transaction to parse the information in the transaction and complete the cross-chain information transmission.

[0052] Furthermore, the cross-chain smart contract call utilizes a cross-blockchain network architecture and employs a two-phase commit strategy to implement asynchronous smart contract calls. The two-phase commit strategy includes a locking phase and a commit phase, which locks the states that the cross-chain transaction needs to access to achieve global atomicity and global serializability of the cross-chain transaction. Moreover, through asynchronous cross-chain smart contracts and the two-phase commit strategy, multi-layered cross-chain recursive calls are realized.

[0053] The cross-blockchain network architecture includes a cross-chain interaction layer, a consensus layer, a smart contract execution layer, a resource management layer, a cross-chain transaction management layer, a database interaction layer, and a database persistent storage layer.

[0054] The two-phase commit strategy includes: 1) In the locking phase, a user initiates a cross-chain transaction to the starting chain, thereby triggering the execution of the cross-chain transaction. This cross-chain transaction has a unique crossId to identify it. The starting chain sets the timeout Tmax of the cross-chain transaction, executes the corresponding smart contract, locks the accessed variables, and temporarily stores the previous variable state. The starting chain initiates the required cross-chain smart contract call according to the logic in the contract; 2) After receiving messages from all target chains that the cross-chain transaction has been successfully executed during the commit phase, the starting chain sends a commit message to all target chains, and each target chain commits the previously locked variables; if any target chain fails to execute, the starting chain sends a rollback message to all target chains, and the target chains roll back all variables locked in the cross-chain transaction and modify the variables to the previously temporarily stored variable state.

[0055] Furthermore, a cross-chain gateway monitoring scheme is adopted to prevent malicious behavior by the cross-chain gateway during the sending of cross-chain messages; the cross-chain gateway monitoring scheme includes:

[0056] Any consensus node in the chain is allowed to voluntarily serve as an inspector to supervise cross-chain gateways. Inspectors can receive rewards after reporting violations by cross-chain gateways and record violations using the DID corresponding to the cross-chain gateway. Malicious cross-chain gateways are punished and held accountable based on the inspectors' reports, and new cross-chain gateways are replaced.

[0057] The cross-chain challenge mechanism enables reviewers to promptly detect whether cross-chain gateways are correctly executing the sending of cross-chain messages; the cross-chain challenge mechanism includes:

[0058] 1) When a cross-chain gateway sends a cross-chain transaction, the receiving gateway promptly responds with a signed response message to prove that the recipient has successfully received the cross-chain transaction. The cross-chain gateway maintains a list of unresponded transactions, which contains cross-chain transactions that the gateway sent to other chains but did not receive a response to. If the cross-chain gateway on chain 1 does not receive responses to multiple cross-chain messages for an extended period, it initiates a client on chain 2 to directly send a challenge transaction and a series of cross-chain transactions to chain 2. After the cross-chain gateway on chain 2 detects the challenge transaction, it promptly adds a response transaction to its own chain. If the cross-chain gateway on chain 2 does not respond to the challenge transaction in a timely manner, it proves that the cross-chain gateway is malfunctioning or acting maliciously.

[0059] 2) Chain 2 periodically generates summaries and reaches consensus on recently executed cross-chain transactions and challenge transactions. Then, the cross-chain gateway of Chain 2 uses this summary as the content of a heartbeat message and sends a heartbeat message to the cross-chain gateway of Chain 1. After receiving the heartbeat message, the cross-chain gateway of Chain 1 synchronizes it with the examiner. The examiner on Chain 1 determines whether the cross-chain transaction has been executed on Chain 2 based on the heartbeat message. By collecting the response messages and challenge transactions of the cross-chain gateway, the examiner determines whether the cross-chain gateway honestly sends cross-chain transactions that have not been executed. If there are cross-chain transactions that have not been executed by Chain 2 for a long time, and neither the response messages nor the challenge transactions can prove that the cross-chain gateway has honestly sent the cross-chain message, it means that there is a high probability that the cross-chain gateway of this chain has not forwarded the cross-chain transaction, and the examiner proposes to replace the cross-chain gateway of this chain.

[0060] A highly efficient atomic cross-chain interaction system for consortium blockchains based on distributed digital identity, comprising:

[0061] The cross-chain channel establishment module is used to deploy cross-chain contracts and cross-chain gateways for consortium blockchains, and to establish cross-chain channels between consortium blockchains based on cross-chain contracts and cross-chain gateways;

[0062] The cross-chain asset transfer module is used to transfer cross-chain assets based on the established cross-chain channel;

[0063] The cross-chain information transmission module is used to transmit cross-chain information based on the established cross-chain channel;

[0064] The cross-chain smart contract invocation module is used to invoke cross-chain smart contracts based on the established cross-chain channel;

[0065] The cross-chain gateway monitoring module is used to monitor cross-chain gateways to prevent them from acting maliciously during the sending of cross-chain messages.

[0066] The beneficial effects of this invention are as follows:

[0067] This solution's cross-chain technology facilitates collaboration between different blockchain networks, enabling developers to build applications across chains and integrate the strengths and features of various blockchains. This collaboration and integration inspires new innovation possibilities and drives the development of blockchain technology and applications.

[0068] This solution proposes CM3C (Chain MakerCross-Chain Channel), a highly efficient and secure multi-chain network cross-chain interaction scheme without relays. To overcome the drawbacks of relay-based cross-chain solutions, this scheme employs a third-party, relay-free cross-chain channel, making the cross-chain process more decentralized, secure, and efficient. This direct interaction method reduces reliance on relay chains or centralized bridge nodes, thereby lowering the risk of single points of failure and improving the overall security of the cross-chain operation. Furthermore, by establishing communication protocols directly between chains, faster asset transfers and data sharing can be achieved, significantly improving the processing speed of cross-chain transactions and mitigating privacy risks. Utilizing DID (Distributed Identity Registry) to record historical consensus nodes in the blockchain provides an efficient method for tracing historical consensus nodes, facilitating efficient verification of cross-chain information.

[0069] This solution implements an asynchronous cross-chain smart contract call scheme with atomicity and consistency guarantees. A two-phase commit strategy ensures the atomicity of cross-chain smart contract calls distributed across multiple chains. Asynchronous cross-chain smart contract calls significantly improve the composability of blockchain smart contracts, allowing contracts to initiate cross-chain calls to functions on other chains. This solution also includes a regulatory strategy for cross-chain gateways, effectively preventing malicious behavior and enhancing the security of the cross-chain system. Attached Figure Description

[0070] Figure 1 This is a diagram of the cross-chain registration channel.

[0071] Figure 2 This is a diagram of cross-chain asset transfer.

[0072] Figure 3 This is a diagram illustrating the failure of locking chain 1.

[0073] Figure 4 This is a diagram illustrating the failure of chain 2 execution.

[0074] Figure 5This is a diagram illustrating the atomicity guarantee during network partitioning.

[0075] Figure 6 This is a diagram illustrating the maintenance of the cross-chain transaction list.

[0076] Figure 7 It is a graph showing the packaging and uploading of information.

[0077] Figure 8 It is a graph of cross-chain information transfer.

[0078] Figure 9 This is a schematic diagram of a blockchain network architecture design.

[0079] Figure 10 This is a schematic diagram of the two-phase commit strategy architecture design.

[0080] Figure 11 This is a flowchart of the locking phase.

[0081] Figure 12 This is a flowchart of the submission phase.

[0082] Figure 13 This is a diagram illustrating multi-level recursive calls.

[0083] Figure 14 This is a diagram illustrating the loss of cross-chain messages.

[0084] Figure 15 This is a diagram of a censor.

[0085] Figure 16 This is a diagram of the cross-chain challenge mechanism.

[0086] Figure 17 This is a diagram showing the target chain sending heartbeat messages.

[0087] Figure 18 This is a diagram of the target chain's cross-chain gateway for review. Detailed Implementation

[0088] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0089] Cross-chain technology enables different blockchain networks to interact and exchange information. It solves the blockchain silo problem, allowing assets and data on different blockchains to be transferred securely and efficiently across chains. DID provides blockchain users with a secure, reliable, and decentralized identity authentication method. This solution targets consortium blockchains, using DID to assist in the cross-chain verification process, improving both security and efficiency. This solution does not rely on relay chains or relay nodes to verify cross-chain information, increasing the system's decentralization and enhancing its security and robustness.

[0090] 1. Consensus Node Identity Maintenance

[0091] This solution is designed for consortium blockchain scenarios. The system comprises multiple consortium blockchains, which may employ different architectures and consensus mechanisms. Through cross-chain technology, these consortium blockchains can interconnect, enabling cross-chain interaction of data and assets. Each consortium blockchain stores a corresponding DID document. Users can register their DIDs on their respective blockchains and have control over their own DIDs. Simultaneously, each blockchain provides DID resolution services to support cross-chain interaction needs.

[0092] In consortium blockchains, reconfiguration is typically performed periodically to adapt to network changes and ensure system security. At the end of each consensus cycle, a new consensus node is elected. The newly elected consensus node's DID and the current consensus cycle number are recorded via a smart contract, thus proving that the node is a legitimate consensus node for that cycle.

[0093] When consensus nodes on a chain are reorganized, their identity information needs to be synchronized with chains that have cross-chain interactions in a timely manner.

[0094] 2. Cross-chain channel solution

[0095] In this design, achieving cross-chain interaction capabilities first requires establishing a cross-chain channel between the two chains. A cross-chain channel is a logical connection that allows the two chains to securely exchange information and assets.

[0096] Figure 1 The diagram illustrates the registration process for cross-chain channels. To establish a cross-chain channel, a cross-chain contract must first be deployed on each business chain. This contract needs to include rules on how to handle cross-chain messages. Each chain requires at least one cross-chain gateway, which can listen for events on the chain and determine whether a cross-chain operation needs to be initiated. Next, the gateway address of the other chain is registered on each cross-chain gateway so that gateways can discover and communicate with each other. Then, the corresponding cross-chain events are registered on the cross-chain gateway, and a unique channel identifier is assigned to the cross-chain channel. Finally, the identity information of the consensus nodes on each chain is synchronized through the cross-chain gateway, including the consensus node's DID, public key, etc. When a chain receives a block header and transaction from another chain, it can verify the block based on the recorded identity information of the consensus nodes.

[0097] The source chain's cross-chain gateway synchronizes information on the source chain. Upon detecting a registered cross-chain event, it sends the corresponding cross-chain message to the target chain's cross-chain gateway via a cross-chain channel. The target chain's cross-chain gateway, upon receiving the message, synchronizes it with the target chain. In this scheme, only the administrator of each chain is responsible for registering cross-chain channels. When consensus nodes on one chain reorganize, the cross-chain gateway needs to promptly synchronize the new consensus node's identity information to the other chain via the cross-chain channel.

[0098] Transactions processed in a consortium blockchain include not only cross-chain transactions but also a large number of intra-chain transactions. Therefore, most blocks do not contain cross-chain transactions, and the block headers of these blocks are not useful for verifying cross-chain transactions. In consortium blockchain cross-chain operations, only the block header of the block containing the cross-chain transaction needs to be verified to complete the verification.

[0099] Unlike previous SPV verification methods that required continuous synchronization of block headers between different consortium blockchains, this solution only requires the cross-chain gateway to send the cross-chain transaction and related cross-chain proof when a cross-chain transaction needs to be sent. This proof is used for verification on the target consortium blockchain to prove that a cross-chain event such as asset locking has indeed occurred on the source consortium blockchain, thereby triggering the smart contract on the target chain to complete the asset distribution or the corresponding cross-chain operation.

[0100] The proof sent by the cross-chain gateway should include the following:

[0101] 1) Cross-chain transaction information on the source chain: This includes detailed information about the cross-chain transaction, such as the amount of assets, the target address, and the address of the calling contract.

[0102] 2) Block header information: The block header information of the exchange is used to verify the authenticity of the transaction on the target chain.

[0103] 3) Consensus node DID information: DID is used to identify the consensus node of the sending chain that signed the block header.

[0104] 4) Merkle proof: Used to prove that a transaction actually exists in a specified block, guaranteeing the immutability of the transaction.

[0105] 3. Cross-chain asset transfer solution

[0106] In this scheme, all cross-chain message transmission is completed through the cross-chain channel between the two chains. Each blockchain only needs to focus on how to process the cross-chain message after receiving it.

[0107] 3.1) Two phases of the cross-chain asset transfer scheme

[0108] The scheme consists of two main phases: a locking phase and a confirmation phase. In the locking phase, the relevant asset locking operations are completed on the source chain. In the confirmation phase, if the cross-chain transaction fails on the target chain, the source chain receives a failure receipt and rolls back the locked assets to prevent asset loss for either party. If the source chain receives and verifies a valid confirmation from the target chain, it can complete the remaining cross-chain operations. The entire process is as follows: Figure 2 As shown.

[0109] Step 1: During the locking phase, Chain 1 receives a cross-chain transaction requesting the transfer of a certain amount of token 1 from user A on Chain 1 to a certain amount of token 2 from user B on Chain 2. The smart contract splits this into two sub-transactions, one for locking assets on Chain 1 and the other for distributing assets on Chain 2. Chain 1 executes the locking step, locking a certain amount of token 1 in A's assets. After the cross-chain gateway detects the execution of the cross-chain sub-transaction, it sends the cross-chain sub-transaction and asset lock proof to Chain 2. The cross-chain sub-transaction sent by the cross-chain gateway contains details of this cross-chain operation, such as the amount of assets, the target account address, and the calling contract address.

[0110] Step 2: In the confirmation phase, Chain 2 first needs to verify the block header information from Chain 1. To do this, Chain 2 needs to parse the consensus node's DID and verify the block header using a valid consensus node signature. Chain 2 uses the block header and Merkleproof to verify whether the locked asset transaction was recorded on Chain 1. If the verification passes, the trigger contract on the target chain is triggered according to the cross-chain transaction, completing the asset distribution. Chain 2's cross-chain gateway generates an on-chain proof and sends it to Chain 1's cross-chain gateway.

[0111] 3.2) Atomicity Guarantee Strategy

[0112] If the locking phase on Chain 1 fails, the cross-chain gateway on Chain 1 cannot send the locking proof to the cross-chain gateway on Chain 2. Ultimately, both parties return to the state before the cross-chain transaction occurred, such as... Figure 3 As shown.

[0113] If the execution of the sub-transaction on Chain 2 fails, the cross-chain gateway on Chain 2 sends a failure certificate to the cross-chain gateway on Chain 1, which will trigger a rollback on Chain 1 to return the assets locked by user A to user A. Figure 4 As shown.

[0114] If a complete network partition (complete network disconnection) occurs between Chain 1 and Chain 2 while Chain 1 is waiting for the on-chain result from Chain 2, the atomicity of cross-chain transactions should still be guaranteed. Figure 5 As shown. At this point, Chain 1 will neither roll back incomplete cross-chain transactions nor continue executing the determination phase. Chain 1 will wait for the network to recover and then actively query the execution result on Chain 2 again. Only after Chain 1 receives the on-chain proof from Chain 2 will it continue executing the determination phase. Figure 5As shown, each transaction has a unique nonce (number only used once) value as an identifier, and the nonce value increments with each transaction to ensure the uniqueness of the transaction.

[0115] The cross-chain gateway on Chain 1 maintains a list of cross-chain transactions, recording all transactions for which no proof of successful or failed execution from Chain 2 has been received. The cross-chain gateway receiving the transaction issues a response message as proof of receipt. For example... Figure 6 As shown, CTxs represents cross-chain transactions, Receipt CTxs represents the response message issued by the cross-chain gateway after receiving the cross-chain transaction, ACK CTxs represents the execution result of cross-chain transaction CTx1 returned in the form of a transaction, and Receipt ACK CTxs represents the response message issued by the cross-chain gateway for the returned result. When Chain 1 receives a successful or failed proof of a transaction being uploaded to the chain from Chain 2, it can remove that transaction from the cross-chain transaction list. For cross-chain transactions with long waiting times, the cross-chain gateway on Chain 1 will actively query the execution status of these transactions from Chain 2.

[0116] 4. Cross-chain information transmission scheme

[0117] Cross-chain messaging refers to the process of securely transmitting and verifying information between different blockchains. Information can be data in any form, including but not limited to transaction details, smart contract state changes, or any other on-chain events. Similar to cross-chain asset transfers, the transmission of cross-chain messages between chains is also accomplished through cross-chain channels.

[0118] Step 1: Information can be packaged into a transaction, and then the transaction is uploaded to the blockchain from the source chain. To ensure the security of information during transmission, encryption technology is usually used to encrypt the information before packaging it into the transaction and uploading it to the blockchain. This process is as follows: Figure 7 As shown, where tx m This refers to transactions that carry information.

[0119] Step 2: The user invokes a smart contract on the source chain to initiate a cross-chain transaction to transmit cross-chain information. This transaction and related information are then forwarded to the target chain through a pre-established cross-chain channel. Similar to the previous section, the forwarded information typically includes: the cross-chain transaction, the source chain transaction containing the packaged information, the block header information, the consensus node's DID information, and the Merkle proof.

[0120] The purpose of forwarding the above information is to verify it on the target chain, to prove that a transaction event of packaging information was indeed recorded on the source chain, thereby triggering the smart contract on the target chain to complete the information transmission or the corresponding cross-chain operation.

[0121] Step 3: The target chain also needs to verify the block header information from the source chain. First, the target chain parses the consensus node's DID to verify its identity and uses the valid consensus node signature to verify the block header. The target chain then uses the block header and Merkle proof to verify whether the source chain transaction packaged in the information is on the source chain. If the verification passes, the target chain's smart contract is triggered based on the cross-chain transaction to parse the information in the transaction and complete the cross-chain information transfer. The entire process is as follows: Figure 8 As shown.

[0122] 5. Cross-chain smart contract calling scheme

[0123] A single blockchain cannot meet the business needs of all industries; therefore, multiple blockchains may need to be deployed for different industries. In such scenarios, some business operations may require simultaneous invocation of multiple smart contracts deployed on multiple blockchains to complete. This solution designs an atomic cross-chain smart contract invocation mode and employs a two-phase commit strategy to implement asynchronous smart contract invocations, including a locking phase and a commit phase. This strategy achieves global atomicity and global serializability of cross-chain transactions by locking the states that need to be accessed by the cross-chain transaction.

[0124] 5.1) Cross-blockchain network architecture

[0125] The cross-blockchain network architecture proposed in this solution is as follows: Figure 9 As shown, it includes a cross-chain interaction layer, a consensus layer, a smart contract execution layer, a resource management layer, a cross-chain transaction management layer, a database interaction layer, and a database persistent storage layer.

[0126] The cross-chain interaction layer is responsible for transmitting cross-chain information between different chains. This solution utilizes cross-chain channels to construct the cross-chain interaction layer for cross-chain message transmission. The consensus layer is responsible for running consensus algorithms such as PBFT and HotStuff on the chain, enabling multiple nodes to reach a consensus on new blocks on the local chain. The smart contract execution layer is responsible for executing smart contracts on the virtual machine.

[0127] The cross-chain transaction management layer is responsible for recording and managing all cross-chain transactions involving this chain, implemented by the cross-chain transaction management contract running in the smart contract execution layer. User-written smart contracts must register with the cross-chain transaction management contract to initiate and be invoked by cross-chain transactions. If a user-written smart contract needs to initiate a cross-chain event, it must go through the cross-chain transaction management contract to add the cross-chain event transaction to the block. The cross-chain transaction management contract is also responsible for coordinating the entire two-phase commit process of cross-chain transactions, determining whether to commit a temporary state or roll back a temporary state.

[0128] The resource management layer is responsible for managing state resource locks during the two-phase commit of cross-chain transactions, and this is implemented by a resource management contract running at the smart contract layer. To improve execution efficiency, the granularity of locking should be more precise. The resource management contract records the locking and unlocking status of each state resource. Before a cross-chain transaction executes the logic in the smart contract and accesses the state, it must acquire the locks on these states to access or modify these variables.

[0129] The database interaction layer is responsible for submitting data to the database, while the database in the persistent storage layer can persistently store ledger data such as blocks, transactions, states, and historical read / write sets on the blockchain, and provide query functions for the above data to the outside world.

[0130] 5.2) Asynchronous cross-chain smart contract invocation strategy

[0131] When a blockchain executes a smart contract and needs to initiate a call to a smart contract on another chain, the block will contain a corresponding cross-chain event, which records the relevant cross-chain information. A cross-chain gateway can scan all cross-chain events in the blocks agreed upon by its own chain and, based on the cross-chain information in each event, forward the cross-chain information to the target chain through previously established cross-chain channels, thereby realizing the cross-chain communication process.

[0132] This scheme uses asynchronous calls. When one chain issues an event to call a function of another chain's smart contract during the execution of its own smart contract, it does not wait for the function call result but continues to execute the remaining smart contract. The call request is initiated in one block, while the result may be returned through a callback function in a subsequent block. Compared with synchronous contract call strategies, there is no need to immediately wait for the execution result of cross-chain smart contract function calls, thus improving the efficiency of contract execution.

[0133] 5.3) Two-phase commit strategy

[0134] To ensure the atomicity and consistency of asynchronous cross-chain smart contract calls, this solution incorporates a two-phase commit strategy, locking the variables and states accessed by the contract, and releasing the locks during the commit phase or rolling back the state during the rollback phase.

[0135] Figure 10 The document illustrates a two-phase commit strategy architecture. A user initiates a cross-chain transaction to the starting chain, triggering the execution of the cross-chain transaction. This transaction is uniquely identified by a `crossId`. The starting chain sets the timeout `Tmax` for the cross-chain transaction, executes the corresponding smart contract, locks accessed variables, and temporarily stores their previous states. Based on the logic within the contract, the starting chain initiates the necessary cross-chain smart contract calls. Figure 10In the code, SC0.func0 to SC3.func3 represent the contract functions of smart contracts on various chains that need to be called to complete cross-chain business. SC0 ​​to SC3 represent the contract names on different chains, and func0 to func3 represent the specific function names to be called.

[0136] After receiving success messages from all target chains regarding the cross-chain transaction, the starting chain sends a commit message to all target chains. Each target chain commits the variables it locked beforehand. If any target chain fails, the starting chain sends an abort message to all target chains. The target chain then rolls back all variables locked in the cross-chain transaction, reverting them to their previously stored states.

[0137] The specific steps for inter-chain asynchronous smart contract calls using a two-phase commit strategy are as follows:

[0138] Step 1:

[0139] Figure 11 The diagram illustrates the locking process. A user initiates a cross-chain transaction to Chain 1, triggering the execution of the cross-chain transaction. Chain 1 needs to call a contract on another chain, so it calls the `raiseCrosscall` function in the cross-chain management contract, specifying the address of the other chain, the contract account address, function parameters, etc. The `raiseCrosscall` function sets a timeout `Tmax` and calls the `emitEvent` function to upload the corresponding cross-chain event to the chain. The cross-chain gateway on Chain 1 scans the data in the block, extracts the cross-chain event, and sends a cross-chain message (cross-event) to the cross-chain gateway on Chain 2.

[0140] After receiving and verifying the message, the cross-chain gateway on Chain 2 synchronizes it with its host blockchain 2. The `onCrosscall` function on Chain 2 parses the parameters in the cross-chain message and initiates a function call to `func2`. The `func2` function locks the state it needs to access, executes the contract logic, and returns the execution result. The `onCrosscall` function on Chain 2 calls the `emitEvent` function to upload the cross-chain event. The cross-chain gateway on Chain 2 captures the cross-chain event and sends a cross-chain message to the cross-chain gateway on Chain 1.

[0141] The gatherCrosscall function on chain 1 processes cross-chain messages from chain 2 and determines whether the timeout period Tmax has expired. If the timeout has not expired, a commit status is recorded on the chain for this cross-chain transaction, indicating that the cross-chain transaction has entered the committed state.

[0142] Step 2:

[0143] Figure 12The diagram illustrates the submission phase process. Chain 1 submits the cross-chain transaction event on-chain by calling the `emitEvent` function through the `confirmCrossTx` function. The cross-chain gateway on Chain 1 scans for cross-chain events in the block and sends the relevant cross-chain messages to the cross-chain gateway on Chain 2.

[0144] After receiving and verifying the message, the cross-chain gateway on Chain 2 synchronizes it with its respective blockchain. The `confirmCrossTx` function on Chain 2 parses the parameters in the cross-chain message, calls the `unLockResource` function in the resource management contract, commits the modified state, and releases the lock acquired for the transaction. Then, Chain 2 notifies Chain 1 of the commit completion by recording a cross-chain event on the chain.

[0145] After receiving the commit message from chain 2, chain 1 calls the unLockResource function to commit the modified state and release the associated lock.

[0146] 5.4) Cross-chain smart contract multi-layer recursive call strategy

[0147] Using the previously introduced asynchronous cross-chain smart contracts and two-phase commit strategy, this solution can achieve multi-level cross-chain recursive calls.

[0148] Next will be Figure 13 The process of multi-level recursive calls is described using a starting chain and two target chains as an example. Figure 13 In this code, `funcA` represents the on-chain contract function, `var1` represents the variable within the function, `a` represents a specific value, `crossHandler(funcB, args)` represents a cross-chain call to function `funcB` with the parameter `args`, and `crossHandler(funcC, args)` represents a cross-chain call to function `funcC` with the parameter `args`. When the starting chain begins executing the smart contract and sends a cross-chain message to the first-layer target chain via the cross-chain channel, the first-layer target chain receives the message and executes the corresponding smart contract. If the first-layer target chain needs to initiate a new cross-chain smart contract call while executing its own smart contract, it can send a cross-chain message to the second-layer target chain via the cross-chain channel, thus achieving multi-level recursive cross-chain smart contract calls.

[0149] After all second-layer target chains successfully execute the cross-chain execution contract call and return a success message to the corresponding first-layer target chain, the first-layer target chain will then send a smart contract call success message to the starting chain. Upon receiving the cross-chain call success message, the starting chain will decide to commit the cross-chain transaction. Subsequently, the starting chain sending a cross-chain commit message will trigger the first-layer target chain to commit. Upon receiving the commit message, the first-layer target chain will send a commit message to the second-layer target chains, thus ensuring that all chains commit the cross-chain transaction. This multi-layer recursive call mechanism for cross-chain smart contracts greatly enhances the composability and scalability of cross-chain smart contract calls, enabling better handling of more complex cross-chain scenarios.

[0150] 5.5) Atomicity and Consistency Guarantee Strategies

[0151] When read-write conflicts or failures occur between cross-chain transactions, inconsistencies in state may arise between different chains. Therefore, the following two scenarios are analyzed in detail:

[0152] 1. Read-write conflicts in transactions can lead to lost modifications, inconsistent reads, and dirty reads, resulting in inconsistent states across different chains.

[0153] 2. When cross-chain transactions are executed, cross-chain read / write data loss or cross-chain message loss may occur, and the transaction may fail to read, write, or commit data correctly, resulting in inconsistent states across different chains.

[0154] The two-phase commit strategy adopted in this solution can effectively resolve read-write conflicts between cross-chain transactions by locking and unlocking the state, and avoid dirty reads, phantom reads and other situations.

[0155] Figure 14 The document illustrates potential scenarios for cross-chain message loss. During the interaction between the originating chain and the target chain, messages such as initiating cross-chain contract calls, success or failure results, and commit or rollback messages may be lost.

[0156] When the starting chain sends a cross-chain contract call message (such as a message calling SC2.func2), the cross-chain message is lost, causing another chain to fail to execute the contract call and therefore unable to return a success message to the starting chain. If the starting chain does not receive success messages from all chains after the Tmax timeout, the user who initiated the cross-chain transaction or the cross-chain gateway can trigger the cross-chain timeout contract. The starting chain will then record the failure of this cross-chain transaction on its own chain and send a rollback message to all chains. When each chain receives the rollback message, it will release the locked variables and roll back to the state before the cross-chain transaction began, ensuring consistency between the states of all chains.

[0157] Successful or failed contract execution messages may also be lost. However, similar to the loss of contract call messages mentioned above, this will prevent the starting chain from collecting all successful execution messages from all chains before the cross-chain transaction times out. The user initiating the cross-chain transaction or the cross-chain gateway can trigger a cross-chain timeout contract. The starting chain will record this cross-chain transaction failure on its own chain and send a rollback message to all chains. At this time, the starting chain also sends rollback messages to other chains, ultimately ensuring that the states of all chains remain consistent.

[0158] The final step in a two-phase commit is for the starting chain to send a commit or rollback message to the other chains, but this message may be lost. At this point, each chain has locked its state and executed the contract to obtain a temporary state, but has not yet received the commit or rollback message. Therefore, the chain will continue to keep its state locked until it receives the commit or rollback message after the network recovers.

[0159] As described in previous cross-chain solutions, cross-chain gateways can maintain a list of incomplete cross-chain transactions. For incomplete transactions that have not received a response for a long time, the cross-chain gateway can proactively query these transactions from the originating chain, which can then retransmit the commit message or rollback message to other chains.

[0160] 6. Cross-chain gateway regulatory scheme

[0161] During cross-chain transactions, cross-chain gateways are responsible for monitoring cross-chain transactions on the business chain and sending various cross-chain messages or transactions through the cross-chain channel. Since cross-chain gateways cannot forge the signatures of on-chain consensus nodes, they cannot tamper with cross-chain transactions signed by consensus nodes. However, cross-chain gateways can launch censorship attacks, refusing to send certain cross-chain transactions through the cross-chain channel. To prevent cross-chain gateways from engaging in malicious activities during the transmission of cross-chain messages, they should be subject to oversight.

[0162] This scheme allows any consensus node in the chain to voluntarily act as a censor for the chain to supervise cross-chain gateways, such as... Figure 15 As shown, inspectors can receive rewards after reporting violations by cross-chain gateways and record violations using the DID corresponding to the cross-chain gateway. The business chain punishes and holds accountable malicious cross-chain gateways based on the inspectors' reports and replaces them with new ones. As a consensus node, the inspector locally stores information such as the chain's blocks, state tree, and receipt tree, but does not know whether the cross-chain gateway is honestly forwarding cross-chain transactions. To address this issue and enable inspectors to promptly detect whether cross-chain gateways are correctly executing the sending of cross-chain messages, this scheme proposes a cross-chain challenge mechanism.

[0163] In this scheme, when a cross-chain gateway sends a cross-chain transaction, the receiving gateway needs to promptly respond with a signed response message. The cross-chain gateway needs to maintain a list of unresponded transactions, which contains cross-chain transactions that the gateway sent to other chains but did not receive a response from. For example... Figure 16 As shown, after the cross-chain gateway on Chain 1 has not received responses to multiple cross-chain messages for an extended period, it initiates a client on Chain 2 to directly send a challenge transaction and a series of cross-chain transactions to Chain 2. Upon detecting the challenge transaction, the cross-chain gateway on Chain 2 needs to promptly write a response transaction on its own chain. If the cross-chain gateway on Chain 2 fails to respond to the challenge transaction in a timely manner, it indicates that the gateway is malfunctioning or acting maliciously. Since Chain 2 has already received a series of cross-chain transactions, it can execute the cross-chain sub-transactions normally.

[0164] Chain 2 periodically generates summaries of recently executed cross-chain transactions and challenge transactions, and reaches consensus on these summaries. The Chain 2 cross-chain gateway then uses these summaries as the content of a heartbeat message and sends it to the Chain 1 cross-chain gateway. Upon receiving the heartbeat message, the Chain 1 cross-chain gateway needs to synchronize it with the reviewer. The reviewer on Chain 1 can determine which cross-chain transactions have been executed on Chain 2 and which have not. By collecting the response messages and challenge transactions from the cross-chain gateways, the reviewer determines whether the cross-chain gateways have honestly sent cross-chain transactions that have not been executed. If cross-chain transactions have not been executed on Chain 2 for an extended period, and neither the response messages nor the challenge transactions can prove that the cross-chain gateway has honestly sent the cross-chain message, it indicates that the Chain 2 cross-chain gateway is highly likely not forwarding the cross-chain transaction, and the reviewer can propose replacing the Chain 2 cross-chain gateway.

[0165] Figure 17 The example demonstrates that censors on Chain 2 can monitor challenge transactions and whether the cross-chain gateway on the local chain responds to them in a timely manner. If Chain 2 receives challenge transactions too frequently, and the cross-chain gateway fails to forward these transactions to Chain 2, the censor on Chain 2 may consider replacing the local cross-chain gateway.

[0166] Figure 18 The example demonstrates that censors on Chain 2 can monitor challenge transactions and whether the cross-chain gateway on the local chain responds to them in a timely manner. If Chain 2 receives challenge transactions too frequently, and the cross-chain gateway fails to forward these transactions to Chain 2, the censor on Chain 2 can propose replacing the local cross-chain gateway.

[0167] In summary, this solution proposes an efficient cross-chain interaction method for consortium blockchains based on decentralized identity. This method can securely and efficiently complete cross-chain asset transfers, cross-chain message passing, and other cross-chain interaction operations, while also enabling secure and flexible cross-chain smart contract calls. By utilizing DID to trace historical consensus nodes and eliminating third-party dependencies during cross-chain processes, this method improves the system's decentralization, enhances its security and reliability, and increases cross-chain interaction efficiency.

[0168] Furthermore, this solution utilizes atomicity guarantees to enhance the security of cross-chain asset transfers and cross-chain smart contract calls. It also includes a regulatory framework for cross-chain gateways to prevent malicious actions during cross-chain transaction forwarding, further improving the reliability of the cross-chain process.

[0169] The technical innovations of this invention include:

[0170] 1. This solution establishes a cross-chain channel, avoiding the relay process involving relay chains and nodes. This reduces reliance on third parties, improves system security, and mitigates the risks of privacy breaches and single points of failure.

[0171] 2. This solution is designed for cross-chain interaction scenarios in consortium blockchains and utilizes the DID identity authentication system to trace historical consensus nodes, providing effective support for verifying cross-chain information when there are changes in consensus nodes.

[0172] 3. When verifying cross-chain transactions through a cross-chain channel, this solution does not require continuous synchronization of block headers from other chains. The cross-chain gateway simply forwards the cross-chain transaction and related proofs. The consensus node's identity is verified via DID, and the proof is verified using the consensus node's signature. This reduces bandwidth and storage requirements, enhancing the flexibility and security of the consortium blockchain. This makes this solution more suitable for complex application scenarios with a large blockchain scale.

[0173] 4. This solution proposes cross-chain asset transfer and cross-chain message passing schemes, and puts forward an atomicity guarantee strategy for the cross-chain asset transfer scheme, thereby improving the reliability of cross-chain asset transfer.

[0174] 5. This solution proposes a novel cross-blockchain network architecture, which includes a cross-chain interaction layer, a consensus layer, a smart contract execution layer, a resource management layer, a cross-chain transaction management layer, a database interaction layer, and a database persistent storage layer. This architecture can fully support the cross-chain operation process.

[0175] 6. This solution proposes an asynchronous cross-chain smart contract calling strategy based on two-phase commit, which improves the efficiency and flexibility of cross-chain smart contract calls.

[0176] 7. This solution incorporates strategies to address anomalies such as read-write conflicts and message loss in cross-chain smart contract calls, ensuring atomicity and reliability in complex cross-chain smart contract call scenarios.

[0177] 8. This solution designs a regulatory strategy for cross-chain gateways. It proposes a scheme where reviewers monitor the behavior of cross-chain gateways through challenge response mechanisms and heartbeat mechanisms, and replace cross-chain gateways exhibiting malicious behavior, effectively ensuring the stable operation of the cross-chain architecture.

[0178] Six solutions were investigated in the background section:

[0179] 1.sigBridge: A Cross-chain Bridge for Permissioned Blockchains and its application to decentralized access control.

[0180] 2.A cross-chain identity authentication scheme based on DID.

[0181] 3. CN117614640A A blockchain cross-chain system and method based on distributed identity.

[0182] 4. CN117596250A A cross-chain interaction method based on multiple blockchain networks.

[0183] 5. CN113179168B A cross-chain interaction method for blockchain.

[0184] 6. CN112579700B A cross-chain transaction processing method and apparatus.

[0185] All six solutions achieve cross-chain interaction. However, these solutions rely on relay chains or relay nodes to verify and forward cross-chain transactions, reducing the efficiency of cross-chain interaction and increasing the risk of privacy leaks and single points of failure. These solutions also lack robust atomicity guarantees and regulatory strategies for the cross-chain process, thus lacking guarantees for the atomicity and reliability of cross-chain transactions.

[0186] Another embodiment of the present invention provides a highly efficient atomic cross-chain interaction system for consortium blockchains based on distributed digital identity, comprising:

[0187] The cross-chain channel establishment module is used to deploy cross-chain contracts and cross-chain gateways for consortium blockchains, and to establish cross-chain channels between consortium blockchains based on cross-chain contracts and cross-chain gateways;

[0188] The cross-chain asset transfer module is used to transfer cross-chain assets based on the established cross-chain channel;

[0189] The cross-chain information transmission module is used to transmit cross-chain information based on the established cross-chain channel;

[0190] The cross-chain smart contract invocation module is used to invoke cross-chain smart contracts based on the established cross-chain channel;

[0191] The cross-chain gateway monitoring module is used to monitor cross-chain gateways to prevent them from acting maliciously during the sending of cross-chain messages.

[0192] For the specific implementation process of each module, please refer to the description of the method of the present invention above.

[0193] Another embodiment of the present invention provides a computer device (computer, server, smartphone, etc.) including a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program including instructions for performing the steps of the method of the present invention.

[0194] Another embodiment of the present invention provides a computer-readable storage medium (such as ROM / RAM, disk, optical disk) storing a computer program that, when executed by a computer, implements the various steps of the method of the present invention.

[0195] The specific embodiments of the present invention disclosed above are intended to help understand the content of the present invention and to implement it accordingly. Those skilled in the art will understand that various substitutions, changes, and modifications are possible without departing from the spirit and scope of the present invention. The present invention should not be limited to the content disclosed in the embodiments of this specification; the scope of protection of the present invention is defined by the claims.

Claims

1. A method for efficient atomic cross-chain interaction in a consortium blockchain based on distributed digital identity, characterized in that: Includes the following steps: Deploy cross-chain contracts and cross-chain gateways for consortium blockchains, and establish cross-chain channels between consortium blockchains based on cross-chain contracts and cross-chain gateways; Cross-chain asset transfer, cross-chain information transmission, and cross-chain smart contract invocation are carried out based on the established cross-chain channels.

2. The method according to claim 1, characterized in that, The cross-chain channel is established using the following steps: Deploy cross-chain contracts on each consortium blockchain, which contain rules for handling cross-chain messages; Deploy a cross-chain gateway for each consortium blockchain, and use the cross-chain gateway to listen for events on the blockchain and determine whether a cross-chain operation needs to be initiated. Register the gateway address of the other chain on the cross-chain gateway so that the gateways can discover and communicate with each other; Register the corresponding cross-chain events on the cross-chain gateway and assign a unique channel identifier to the cross-chain channel; The cross-chain gateway synchronizes the identity information of consensus nodes on each chain, including the consensus node's DID and public key. When a chain receives a block header and transaction from another chain, it verifies the block based on the recorded identity information of the consensus node.

3. The method according to claim 1, characterized in that, The cross-chain asset transfer includes two phases: a locking phase and a confirmation phase. The locking phase includes: Chain 1 receives a cross-chain transaction to transfer a certain number of tokens 1 from user A in Chain 1 to a certain number of tokens 2 from user B in Chain 2; the smart contract splits it into two sub-transactions, which are used to lock assets on Chain 1 and issue assets on Chain 2 respectively; Chain 1 executes the locking step to lock a certain number of tokens 1 in A's assets. After the cross-chain gateway detects the execution of a cross-chain sub-transaction, it sends the cross-chain sub-transaction and asset lock proof to Chain 2. The determination phase includes: Chain 2 verifies the block header information from Chain 1; Chain 2 uses the block header and Merkleproof to verify whether the locked asset transaction is on Chain 1. If the verification is successful, the trigger contract on the target chain is triggered according to the cross-chain transaction to complete the asset distribution; the cross-chain gateway of Chain 2 generates an on-chain proof and sends it to the cross-chain gateway of Chain 1.

4. The method according to claim 3, characterized in that, The cross-chain asset transfer employs an atomicity guarantee strategy, which includes: If the locking phase on Chain 1 fails, the cross-chain gateway of Chain 1 cannot send the locking proof to the cross-chain gateway of Chain 2, and both parties eventually return to the state before the cross-chain transaction occurred. If the execution of the sub-transaction on Chain 2 fails, the cross-chain gateway of Chain 2 sends a proof of execution failure to the cross-chain gateway of Chain 1, causing Chain 1 to trigger a rollback and return the assets locked by user A to user A. If a complete network partition occurs between Chain 1 and Chain 2 while Chain 1 is waiting for the on-chain result from Chain 2, then Chain 1 will neither roll back the incomplete cross-chain transactions nor continue executing the determination phase. After the network recovers, Chain 1 will actively query the execution result on Chain 2 again. Once Chain 1 receives the on-chain proof from Chain 2, it will continue executing the determination phase. The cross-chain gateway on Chain 1 maintains a list of cross-chain transactions, recording all cross-chain transactions that have not received proof of successful or failed execution from Chain 2. When Chain 1 receives proof of successful or failed execution of a transaction from Chain 2, it removes the transaction from the cross-chain transaction list. For cross-chain transactions with long waiting times, the cross-chain gateway on Chain 1 actively queries Chain 2 for the execution status of the transaction.

5. The method according to claim 1, characterized in that, The cross-chain information transmission includes: The information is packaged into the transaction, and then the transaction is uploaded to the source chain. Users invoke smart contracts on the source chain to initiate a cross-chain transaction, which is used to transmit cross-chain information and forward the transaction and related information to the target chain through the cross-chain channel. The forwarded information includes: cross-chain transaction, source chain transaction packaged information, block header information, consensus node DID information, and Merkle proof. The target chain parses the DID of the consensus node, verifies the identity of the consensus node, and uses the valid consensus node signature to verify the block header information. The target chain uses the block header information and Merkle proof to verify whether the source chain transaction of the packaged information is on the source chain. If the verification is successful, the smart contract on the target chain is triggered according to the cross-chain transaction to parse the information in the transaction and complete the cross-chain information transmission.

6. The method according to claim 1, characterized in that, The cross-chain smart contract call utilizes a cross-blockchain network architecture and a two-phase commit strategy to implement asynchronous smart contract calls. The two-phase commit strategy includes a locking phase and a commit phase. By locking the states that the cross-chain transaction needs to access, the global atomicity and global serializability of the cross-chain transaction are achieved. Furthermore, through asynchronous cross-chain smart contracts and the two-phase commit strategy, multi-layered cross-chain recursive calls are realized. The cross-blockchain network architecture includes a cross-chain interaction layer, a consensus layer, a smart contract execution layer, a resource management layer, a cross-chain transaction management layer, a database interaction layer, and a database persistent storage layer. The two-phase commit strategy includes: 1) In the locking phase, a user initiates a cross-chain transaction to the starting chain, thereby triggering the execution of the cross-chain transaction. This cross-chain transaction has a unique crossId to identify it. The starting chain sets the timeout Tmax of the cross-chain transaction, executes the corresponding smart contract, locks the accessed variables, and temporarily stores the previous variable state. The starting chain initiates the required cross-chain smart contract call according to the logic in the contract; 2) After receiving messages from all target chains that the cross-chain transaction has been successfully executed during the commit phase, the starting chain sends a commit message to all target chains, and each target chain commits the previously locked variables; if any target chain fails to execute, the starting chain sends a rollback message to all target chains, and the target chains roll back all variables locked in the cross-chain transaction and modify the variables to the previously temporarily stored variable state.

7. The method according to claim 1, characterized in that, A cross-chain gateway monitoring scheme is adopted to prevent malicious behavior by cross-chain gateways during the transmission of cross-chain messages; the cross-chain gateway monitoring scheme includes: Any consensus node in the chain is allowed to voluntarily serve as an inspector to supervise cross-chain gateways. Inspectors can receive rewards after reporting violations by cross-chain gateways and record violations using the DID corresponding to the cross-chain gateway. Malicious cross-chain gateways are punished and held accountable based on the inspectors' reports, and new cross-chain gateways are replaced. The cross-chain challenge mechanism enables reviewers to promptly detect whether cross-chain gateways are correctly executing the sending of cross-chain messages; the cross-chain challenge mechanism includes: 1) When a cross-chain gateway sends a cross-chain transaction, the receiving gateway promptly responds with a signed response message to prove that the recipient has successfully received the cross-chain transaction. The cross-chain gateway maintains a list of unresponded transactions, which contains cross-chain transactions that the gateway sent to other chains but did not receive a response to. If the cross-chain gateway on chain 1 does not receive responses to multiple cross-chain messages for an extended period, it initiates a client on chain 2 to directly send a challenge transaction and a series of cross-chain transactions to chain 2. After the cross-chain gateway on chain 2 detects the challenge transaction, it promptly adds a response transaction to its own chain. If the cross-chain gateway on chain 2 does not respond to the challenge transaction in a timely manner, it proves that the cross-chain gateway is malfunctioning or acting maliciously. 2) Chain 2 periodically generates summaries and reaches consensus on recently executed cross-chain transactions and challenge transactions. Then, the cross-chain gateway of Chain 2 uses this summary as the content of a heartbeat message and sends a heartbeat message to the cross-chain gateway of Chain 1. After receiving the heartbeat message, the cross-chain gateway of Chain 1 synchronizes it with the examiner. The examiner on Chain 1 determines whether the cross-chain transaction has been executed on Chain 2 based on the heartbeat message. By collecting the response messages and challenge transactions of the cross-chain gateway, the examiner determines whether the cross-chain gateway honestly sends cross-chain transactions that have not been executed. If there are cross-chain transactions that have not been executed by Chain 2 for a long time, and neither the response messages nor the challenge transactions can prove that the cross-chain gateway has honestly sent the cross-chain message, it means that there is a high probability that the cross-chain gateway of this chain has not forwarded the cross-chain transaction, and the examiner proposes to replace the cross-chain gateway of this chain.

8. A highly efficient atomic cross-chain interaction system for consortium blockchains based on distributed digital identity, characterized in that: include: The cross-chain channel establishment module is used to deploy cross-chain contracts and cross-chain gateways for consortium blockchains, and to establish cross-chain channels between consortium blockchains based on cross-chain contracts and cross-chain gateways; The cross-chain asset transfer module is used to transfer cross-chain assets based on the established cross-chain channel; The cross-chain information transmission module is used to transmit cross-chain information based on the established cross-chain channel; The cross-chain smart contract invocation module is used to invoke cross-chain smart contracts based on the established cross-chain channel; The cross-chain gateway monitoring module is used to monitor cross-chain gateways to prevent them from acting maliciously during the sending of cross-chain messages.

9. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program including instructions for performing the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a computer, implements the method according to any one of claims 1 to 7.

Images