A trusted method and system for cross-chain data migration in a multi-consortium blockchain network

Abstract

This invention proposes a trusted cross-chain data migration method and system for multi-consortium blockchain networks, relating to the interconnection and cross-chain data migration in such networks. A data request chain requests cross-chain data from each adjacent application chain, verifies the trustworthiness of the two chains in the cross-chain data migration transaction, and receives cross-chain data sent by adjacent application chains. The data request chain constructs a new block for the received new data and broadcasts the new block to all adjacent blockchains, achieving multi-chain data synchronization. Based on a relay cross-chain mechanism, this invention introduces a cross-chain mutual trust contract to ensure the trustworthiness of application chains, introduces a message-oriented verification mechanism to ensure data trustworthiness, sets up a shared state tree node to track the data migration transaction status, and introduces a multi-version concurrency control mechanism to resolve cross-chain data migration transaction conflicts. This enables data migration and collaboration between different blockchains in a multi-chain scenario, improving the security and efficiency of cross-chain data migration, and reducing the cost and complexity of multi-chain systems.

Description

Technical Field

[0001] This invention belongs to the field of interconnection and cross-chain data migration in multi-consortium blockchain networks, and particularly relates to a reliable method and system for cross-chain data migration in multi-consortium blockchain networks. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] In the early stages and development of blockchain, various blockchain architectures and protocols have emerged, gradually forming a new landscape of multi-chain networks. These networks urgently require cross-chain interoperability technologies to connect different blockchains, breaking down isolated, heterogeneous blockchain silos and promoting the diversified development and large-scale application of blockchain technology. Cross-chain interoperability technologies for multi-chain blockchain networks mainly include two categories: bridging and relaying. Bridging refers to establishing a connection between two or more blockchains, enabling them to transfer data and value. Relaying refers to establishing a relay layer between multiple blockchains, allowing them to interact through a unified protocol. Cross-chain data migration refers to the process of transferring data between different blockchains, with the aim of achieving interoperability between them.

[0004] Cross-chain technology is a technical means to enable asset circulation and data transfer between different blockchains. It can achieve secure and reliable data exchange and value transfer between two or more blockchains, including cross-chain mechanisms such as notaries, hash locking, sidechains and relay chains, and distributed private key control. Enabling trusted data migration in multi-chain networks based on cross-chain technology will break down "chain silos," improve the interoperability and availability of multi-chain networks, and promote the integrated application of heterogeneous blockchain systems.

[0005] Current cross-chain data migration in multi-chain networks has several shortcomings: First, the standardization of existing cross-chain protocols is low. Different cross-chain solutions use different protocols, and the lack of unified standards and specifications increases the complexity and cost of cross-chain data migration, resulting in low interoperability and compatibility. Second, the security and efficiency of cross-chain verification are insufficient. Cross-chain verification refers to the trusted authentication of data on the data provider chain to ensure the consistency of data during cross-chain migration. Currently, cross-chain verification mainly relies on third-party institutions such as oracles, which may have trust risks, attack risks, or performance bottlenecks, affecting the security and efficiency of cross-chain data verification. Third, the transparency of cross-chain data migration transactions is insufficient. During the cross-chain data migration process, if the transaction status is not monitored in real time, the participating parties will not be able to understand the progress of the cross-chain data migration in a timely manner, leading to errors or malicious behavior going undetected. Therefore, existing cross-chain data migration solutions in multi-chain networks have security and performance issues. Summary of the Invention

[0006] To overcome the shortcomings of the existing technologies, this invention provides a cross-chain data trusted migration method and system for multi-consortium blockchain networks. Based on a relay cross-chain mechanism, it introduces a cross-chain mutual trust contract to ensure the trustworthiness of the application chain, introduces a message-oriented verification mechanism to ensure data trustworthiness, sets up a shared state tree node to track the data migration transaction status, and introduces a multi-version concurrency control mechanism to resolve cross-chain data migration transaction conflicts. This enables data migration and collaboration between different blockchains in a multi-chain scenario, improves the security and efficiency of cross-chain data migration, and reduces the cost of cross-chain data migration and the complexity of multi-chain systems.

[0007] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions:

[0008] The first aspect of this invention provides a method for trusted cross-chain data migration in a multi-consortium blockchain network.

[0009] A method for trusted cross-chain data migration in a multi-consortium blockchain network includes:

[0010] Based on the relay cross-chain mechanism, the data request chain requests cross-chain data from each adjacent application chain and uses the cross-chain mutual trust contract to verify the trustworthiness of the two chains in the cross-chain data migration transaction, and receives the cross-chain data sent by the adjacent application chain that has passed the verification.

[0011] The data request chain constructs a new block for the new data it receives and broadcasts the new block to all adjacent blockchains to achieve multi-chain data synchronization;

[0012] Specifically, a shared state tree node is set up on the relay chain of the relay cross-chain mechanism to track the status of the cross-chain data migration transaction, and a multi-version concurrency control mechanism is introduced to solve the concurrency control problem of cross-chain data migration transactions.

[0013] Furthermore, the relay-based cross-chain mechanism, where the data request chain requests cross-chain data from each adjacent application chain, involves traversing each adjacent application chain in the set of adjacent application chains, specifically:

[0014] In a multi-consortium blockchain network, all application chains register their chain information with the relay chain, which then assigns access keys and consensus nodes to each application chain.

[0015] The data request chain initiates a request based on a cross-chain data migration transaction and sends a request message verified through consensus to the data provider chain. The request message includes the latest cached data of the data request chain and the message authentication code of the data.

[0016] The data provider chain generates a response message and sends it to the data request chain;

[0017] The data request chain utilizes cross-chain mutual trust contracts to verify the trustworthiness of two chains in cross-chain data migration transactions by comparing trust vectors.

[0018] The data request link is received and the cross-chain data is verified.

[0019] Furthermore, the data request chain initiates a request based on a cross-chain data migration transaction and sends the consensus-verified request message to the data provider chain, specifically as follows:

[0020] The data request chain selects a neighboring blockchain from the set of adjacent application chains to serve as the data provider chain;

[0021] The interaction nodes in the data request chain generate request messages in a predefined format;

[0022] The request message is sent to the consensus node assigned by the relay chain via the registered communication link;

[0023] Upon receiving the request message, the consensus node broadcasts the request message to all consensus nodes on the relay chain using a peer-to-peer protocol;

[0024] Invoke the asynchronous consensus protocol to achieve consensus;

[0025] Once consensus is reached, the shared state tree node of the relay chain creates a cross-chain data migration transaction, and the consensus node of the data provider chain sends the request message to the interaction node of the data provider chain.

[0026] Furthermore, the specific steps of the asynchronous consensus protocol are as follows:

[0027] Each consensus node sets up a local buffer and a timer;

[0028] The consensus nodes of the data request chain receive the request messages from the interaction nodes and then broadcast them to all consensus nodes on the relay chain.

[0029] Each consensus node constructs a proposal based on the request information and broadcasts it to other consensus nodes, selecting the best proposal from a set of proposals as the consensus object for the current round;

[0030] Consensus nodes vote on the best proposal and broadcast the voting results to other consensus nodes;

[0031] Determine whether the voting results meet the preset consensus conditions. If they do, a consensus is reached, a cross-chain data migration transaction is created, and a confirmation message is sent to the data request chain.

[0032] Furthermore, the response message generated by the data providing chain includes all cross-chain data in the local cache and the message authentication code of that data. The shared state tree node executes the cross-chain data migration transaction, and the interaction node of the data providing chain sends the response message to the interaction node of the data request chain.

[0033] Furthermore, the comparison of trust vectors specifically includes:

[0034] Using the trust vector comparator of the cross-chain mutual trust contract, the trust vector of the interaction node of the data providing chain is compared with the trust vector of the interaction node of the data requesting chain. If the comparison result meets the preset trust standard of the data requesting chain, the response message from the interaction node is received; otherwise, the response message from the interaction node is rejected.

[0035] Furthermore, the data request link receives and verifies cross-chain data, specifically as follows:

[0036] When the interaction node of the data request chain receives the response message sent by the interaction node of the data provider chain, it recalculates the message authentication code of the cross-chain data in the response message and compares it with the message authentication code of the response message. If they match, incremental caching is performed; otherwise, caching is rejected.

[0037] Shared state tree nodes mark cross-chain data migration transactions as completed and update the shared state tree.

[0038] A second aspect of the present invention provides a cross-chain data trusted migration system for a multi-consortium blockchain network.

[0039] A cross-chain trusted data migration system for multi-consortium blockchain networks includes a data migration module and a data synchronization module.

[0040] The data migration module is configured to: based on the relay cross-chain mechanism, the data request chain requests cross-chain data from each adjacent application chain, and uses the cross-chain mutual trust contract to verify the trustworthiness of the two chains in the cross-chain data migration transaction, and receive the cross-chain data sent by the adjacent application chain that has passed the verification.

[0041] The data synchronization module is configured to: construct a new block for the new data received by the data request chain, and broadcast the new block to all adjacent blockchains to achieve multi-chain data synchronization;

[0042] Specifically, a shared state tree node is set up on the relay chain of the relay cross-chain mechanism to track the status of the cross-chain data migration transaction, and a multi-version concurrency control mechanism is introduced to resolve cross-chain data migration transaction conflicts.

[0043] A third aspect of the present invention provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the steps of a cross-chain data trusted migration method for a multi-consortium blockchain network as described in the first aspect of the present invention.

[0044] The fourth aspect of the present invention provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of a cross-chain data trusted migration method for a multi-consortium blockchain network as described in the first aspect of the present invention.

[0045] The above one or more technical solutions have the following beneficial effects:

[0046] This invention introduces cross-chain mutual trust contracts and asynchronous consensus protocols for multi-chain networks. Cross-chain mutual trust contracts guarantee the transfer of trust between blockchains, prevent malicious attacks, and ensure the integrity of multi-chain networks. Asynchronous consensus protocols can ensure that consensus on transactions can still be reached even when some nodes are unavailable, reducing the risk of single points of failure and improving the resilience of multi-chain networks. They can also reduce the overhead of message processing and verification, and improve the scalability of the system.

[0047] This invention supports cross-chain data migration between one consortium blockchain and multiple consortium blockchains, demonstrating broad applicability. Simultaneously, it reduces repetitive work, lowers development and maintenance costs, simplifies communication by providing a standard framework, and enhances the scalability of the cross-chain data migration system by reducing message processing and verification overhead.

[0048] This invention introduces a message-oriented verification mechanism, which allows only authorized parties to access or modify data. This improves system security, reduces data duplication, and helps enhance the credibility and transparency of cross-chain transactions. As a result, it enables more efficient and reliable data transmission between different nodes in the network, making it easier to develop and deploy blockchain-based applications.

[0049] This invention introduces multi-version concurrency control in cross-chain data migration within a multi-chain network. It improves data consistency by creating multiple versions of the same data and enhances performance by allowing multiple transactions to access the same data simultaneously, reducing transaction wait times. By utilizing transactions to access and update multiple versions of the same data, fault tolerance is improved, ensuring the migration process continues even if one or more nodes fail or become unavailable.

[0050] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0051] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0052] Figure 1 This is a flowchart of the method in the first embodiment.

[0053] Figure 2 This is a diagram illustrating the relationship between data migration and data synchronization in the first embodiment.

[0054] Figure 3 This is a flowchart illustrating the data migration process in the first embodiment.

[0055] Figure 4 This is a flowchart of the asynchronous consensus protocol for the first embodiment.

[0056] Figure 5 The following is a flowchart illustrating the data synchronization process in the first embodiment.

[0057] Figure 6 This is a flowchart illustrating the multi-version concurrency control in the first embodiment. Detailed Implementation

[0058] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0059] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0060] Glossary

[0061] Cross-chain mutual trust contract: A cross-chain mutual trust contract is a smart contract that includes a trust transfer function from one chain to another. It can calculate a multi-dimensional trust vector based on the similarity of trust factors on two chains and retain the trust information on both chains. The cross-chain mutual trust contract includes two functions: Trust Vector Generator (TVG) and Trust Vector Comparator (TVC).

[0062] Shared State Tree Nodes: Deployed on the relay chain, shared state tree nodes are used to store state information across different chains, enabling cross-chain operations such as cross-chain data migration and contract calls. Shared state tree nodes act as a bridge for state sharing and verification between different chains, improving cross-chain interoperability in multi-chain networks and ensuring the security and transparency of data migration transactions.

[0063] Neighbor blockchain: In a multi-chain network, a neighbor blockchain refers to other blockchains that are directly or indirectly connected to a certain blockchain. Neighbor blockchains can realize the exchange of data and value through cross-chain protocols, thereby improving the availability of the entire network.

[0064] To address the problems mentioned in the background section, and to securely and efficiently achieve cross-chain data migration between heterogeneous blockchain systems in a multi-chain network, this invention designs a system and method for cross-chain data migration in a multi-chain scenario based on an asynchronous consensus protocol, a multi-version concurrency control mechanism, a cross-chain mutual trust contract, and a message-oriented verification mechanism.

[0065] An asynchronous consensus protocol suitable for multi-chain networks was designed. It does not require all nodes to reach a consensus at the same time, but allows for a certain degree of disagreement and delay, thereby improving the fault tolerance and scalability of multi-chain networks.

[0066] The multi-version concurrency control mechanism maintains a global version number on the cross-chain relay and a local version number on each application chain to ensure the consistency and serialized execution of cross-chain data migration transactions, thereby achieving high-concurrency and reliable data migration across multiple chains in a multi-chain network.

[0067] This invention implements multi-version concurrency control for cross-chain data migration transactions. Participants in cross-chain data migration can view and track the status of cross-chain data migration transactions through shared state tree nodes deployed on the relay chain, which increases the transparency and trustworthiness of cross-chain operations and ensures the effectiveness and consistency of cross-chain data migration transactions.

[0068] The cross-chain mutual trust contract designed in this invention includes a function for transferring trust from one chain to another. It can calculate a multi-dimensional trust vector based on the similarity of trust factors on the two chains and retain the trust information on both chains, thereby improving the credibility of the data source in cross-chain data migration transactions.

[0069] The basic idea of ​​a message-oriented verification mechanism is that each cross-chain data packet needs to contain a signature generated by a trusted entity on the data-providing chain and appended to the data packet. When the requesting chain receives the data packet, it first verifies whether the signature is valid. After successful verification, it performs the corresponding operation based on the information in the signature. This message-oriented verification mechanism can improve the efficiency and security of cross-chain data migration, while also reducing development and maintenance costs.

[0070] In summary, this invention, based on a relay cross-chain mechanism, introduces cross-chain mutual trust contracts to ensure the trustworthiness of application chains, introduces a message-oriented verification mechanism to ensure data reliability, sets up shared state tree nodes to track the status of data migration transactions, and introduces a multi-version concurrency control mechanism to resolve cross-chain data migration transaction conflicts. It can ensure data security, migration transaction reliability, and efficient execution of concurrent processing in multi-chain scenarios, realizing data migration and collaboration between different blockchains in multi-chain scenarios. This improves the security and efficiency of cross-chain data migration, reduces the cost of cross-chain data migration and the complexity of multi-chain systems, and can be used to establish more secure and efficient multi-chain networks.

[0071] Example 1

[0072] In one or more embodiments, a method for trusted cross-chain data migration in a multi-consortium blockchain network is disclosed, such as... Figure 1 As shown, it includes the following steps:

[0073] Step S1: Based on the relay cross-chain mechanism, the data request chain requests cross-chain data from each adjacent application chain, and uses the cross-chain mutual trust contract to verify the trustworthiness of the two chains in the cross-chain data migration transaction, and receives the cross-chain data sent by the adjacent application chain that has passed the verification.

[0074] Step S2: The data request chain constructs a new block for the received new data and broadcasts the new block to all adjacent blockchains to achieve multi-chain data synchronization;

[0075] Specifically, a shared state tree node is set up on the relay chain of the relay cross-chain mechanism to track the status of the cross-chain data migration transaction, and a multi-version concurrency control mechanism is introduced to resolve cross-chain data migration transaction conflicts.

[0076] The following is a detailed description of the implementation process of a cross-chain data trusted migration method for a multi-consortium blockchain network in this embodiment.

[0077] The technical solution of this embodiment includes three parts: data migration, data synchronization, and multi-version concurrency control. The relationship between these three, especially the relationship between data migration and data synchronization, is explained below. Figure 2 As shown: Data migration is used to migrate data from all application chains in a multi-consortium blockchain network to a single application chain LA, i.e., data integration onto a single application chain LA. Data synchronization is used to synchronize the integrated data on application chain LA to other application chains in the multi-consortium blockchain network. Multi-version concurrency control is used to control the consistency of data involved in cross-chain data migration transactions during data migration.

[0078] During the data migration phase, the application chain registers its chain information on the relay chain in advance; LA generates a request message msg and sends it to the consensus node C on the relay chain. AAsynchronous consensus is achieved. After consensus is reached, the shared state tree node SN creates a migration transaction Tx-migrate, and the consensus node C... B Send msg to LB's interactive node I B I B Upon receiving the message, select an appropriate cryptographic hash function to generate a message authentication code (MAC), and then send the requested data (data) and the MAC to the interaction node I of LA. A After receiving the data, I A The data is verified and a choice is made whether to add it to the local cache. Then the SN updates the shared state tree. After completing the cross-chain data migration transaction with the LB, the LA repeats the above operation until it has received cross-chain data from all adjacent blockchains.

[0079] During the multi-chain data synchronization phase, LA selects local data to put into a new block and calculates its MAC, then broadcasts the new block and MAC to all neighboring blockchains. Neighboring blockchains verify the MAC and choose whether to accept it; if accepted, LA adds the new block to its ledger.

[0080] Multi-version concurrency control works as follows: When a cross-chain data migration transaction Tx_change needs to modify data in LA, it first creates a snapshot. Tx_change modifies the snapshot to reflect the expected data and checks whether there are conflicts with other transactions. If there are no conflicts, it commits the modification; otherwise, Tx_change will abort and roll back.

[0081] Based on the above three parts, a more detailed example of a trusted cross-chain data migration process in a multi-consortium blockchain network is given. Steps 1-6 constitute the data migration part, and the specific data migration process is as follows: Figure 3 As shown, step 7 is the data synchronization part, which specifically includes:

[0082] 1. Application Chain Registration

[0083] Before data migration, to ensure the data source is trustworthy, each application chain in the multi-consortium blockchain network needs to register its chain information in the relay chain.

[0084] Specifically, the registration information includes: the user-defined application chain name (name), communication link (Link), application chain type (type), configuration file path (Config-addr, which contains configuration information about the application chain, such as node address, port, consensus algorithm, etc.), and certificate file path (CA-addr).

[0085] After the application chain information is received and verified by the relay chain, the relay chain assigns each application chain an access key (ACCESS-key) and a consensus node for communication with the relay chain during data migration.

[0086] The relay chain deploys consensus nodes, shared state tree nodes, and shared state tree contracts, specifically:

[0087] Consensus nodes: Consensus nodes verify and package transactions and blocks on the multi-chain network by executing asynchronous consensus protocols, thereby ensuring the security of the entire network; they ensure the legality and consistency of on-chain transactions through asynchronous consensus mechanisms, preventing double-spending, fraud and other malicious behaviors; consensus nodes coordinate and verify cross-chain transactions on the relay chain, enabling smooth cross-chain operations such as digital asset migration, contract calls and state sharing between different chains, ensuring the credibility and effectiveness of cross-chain interactions.

[0088] Shared state tree nodes: used to record cross-chain transaction information and data ownership information; acting as a bridge in the multi-chain network, allowing different chains to query and verify the state on other chains, thereby supporting functions such as cross-chain transactions, contract calls and data migration, and ensuring the security and consistency of the entire multi-chain network.

[0089] The shared state tree node deploys a shared state tree contract to manage read and update operations on the shared state tree, ensuring the validity and consistency of cross-chain transactions. The shared state tree contract includes three methods: `createMigrationTask()` creates a cross-chain data migration transaction, specifying the data request chain and data provider chain to be used; `executeMigrationTask()` verifies and executes the cross-chain data migration transaction, ensuring its validity and security; it verifies the transaction's state, data request chain, and data provider chain, executes data transfer operations, and updates the transaction state to record the transaction's execution status; `completeMigrationTask()` marks the cross-chain data migration transaction as completed and maintains the transaction's historical record. It verifies the transaction's state and related information, records the transaction's completion time and state, and updates the shared state tree to reflect the final state.

[0090] 2. Data Request LA initiates a request and verifies it through consensus.

[0091] LA selects a neighboring blockchain LB from its adjacent application chain set Z as the data provider chain; LA's interaction node I A A predefined request message msg will be generated, including the latest cached data of LB and the message authentication code (MAC) of that data, and will be sent to the consensus node C assigned by the relay chain via the registered communication link. A After receiving the message, C A This request message is broadcast to all consensus nodes on the relay chain using a peer-to-peer protocol, and then an asynchronous consensus protocol is invoked to achieve consensus, such as... Figure 4 As shown, the consensus steps are as follows:

[0092] 2.1 Initialization

[0093] Each consensus node sets up a local buffer and a timer t0.

[0094] 2.2 Verify Transaction Requests

[0095] The consensus node of the application chain receives the request message from the application chain, then broadcasts it to all consensus nodes on the relay chain and puts it into its local buffer; each consensus node checks whether the request message in its local buffer is valid, and deletes it if it is invalid.

[0096] 2.3 Proposal

[0097] When the timer reaches the preset time interval t0, each consensus node selects a request message from its local buffer and packages it into a proposal; each consensus node broadcasts the generated proposal to other consensus nodes; then each consensus node receives the proposals broadcast by other consensus nodes and puts them into a candidate set; each consensus node selects the optimal proposal from the candidate set as the consensus object for the current round according to certain rules.

[0098] 2.4 Voting

[0099] Consensus nodes vote on the best proposal and broadcast the voting results to other consensus nodes; each consensus node receives the voting results broadcast by other consensus nodes and updates its own voting record table.

[0100] 2.5 Determining Consensus Conditions

[0101] Each consensus node determines whether the consensus condition is met based on the voting record table. In this embodiment, the consensus condition is: whether more than two-thirds of the total number of consensus nodes have valid support for a certain proposal. If the consensus condition is met, a consensus is reached; otherwise, the next round of consensus is initiated. If a consensus is reached, the consensus result is added to the relay chain, and a confirmation message is sent to the application chain.

[0102] 2.6 Achieve consensus

[0103] Once consensus is reached, the shared state tree node SN calls the createMigrationTask method to create a cross-domain data migration transaction Tx_migrate, specifying the data request chain and data provider chain to be migrated within the transaction; the shared state tree node SN will record detailed information about Tx_migrate; consensus node C... B Send msg to LB's interactive node I B .

[0104] 3. LB's interaction node I B Generate response message

[0105] Upon receiving the request message msg, firstly, I B Choose an appropriate cryptographic hash function, such as HMAC-SHA256, a hash message authentication code based on SHA-256. B Using a shared key as the key input to the cryptographic hash function, and then using the data to be sent as the message input to the cryptographic hash function, a fixed-length hash value is generated; this hash value is the MAC. Subsequently, I... B A response message is generated, which includes all cross-chain data in the local cache and the MAC address of that data; then, the shared state tree node calls the executeMigrationTask method to execute the cross-chain data migration transaction Tx_migrate. B Send the data and MAC address from the response to the interaction node I of LA. A .

[0106] 4. LA's Interaction Node I A Compare trust vectors

[0107] I A Before receiving cross-chain data, the Trust Vector Comparator (TVC) of the cross-chain mutual trust contract is used to compare the data sending node I. B Trust vector V B With its own trust vector V A Compare. If V B If the trust criteria set by LA are met, then I A Accept cross-chain data from this node; if the sending node's trust vector fails to meet the trust criteria, I A You can refuse to receive data from this node.

[0108] 5. LA's Interaction Node I A Receive and verify data

[0109] I A Select receive I B After sending cross-chain data and MAC, I A The same shared key and the same hash function are used to calculate the MAC of the received data, and the calculated MAC is compared with the received MAC. If the calculated result matches the received MAC, then I... A It can verify the integrity and authenticity of the data because only the LB with the correct key can generate a matching MAC.

[0110] Then I A Check each piece of cross-chain data; if the cross-chain data already exists in I...A If the data is in the local cache, then ignore it; if I A If there is no cross-chain data in the local cache, then I A Add cross-chain data to I A Local cache. If MAC verification fails, I A You can refuse to accept the data because this indicates that the data may have been tampered with during transmission.

[0111] Once the data migration transaction is successfully completed, the shared state tree node calls the completeMigrationTask method to mark the cross-chain data migration transaction Tx_migrate as completed and update the shared state tree to indicate the success of the cross-chain data migration.

[0112] 6. Repeat steps 2 to 5 until the data request chain LA selects all neighboring blockchains from the set of neighboring application chains Z, that is, iterates through all neighboring blockchains and receives all cross-chain data sent by them, that is, it integrates the data on the multi-consortium blockchain network.

[0113] 7. Data synchronization

[0114] Data synchronization involves synchronizing the integrated data across all adjacent blockchains to facilitate cross-chain interaction and business logic processing, such as... Figure 5 As shown, the specific steps are as follows:

[0115] 7.1 Encapsulation Transaction

[0116] The application chain LA, where the integrated data resides, constructs a new block for the received new data. The interaction node I of application chain LA... A Some cross-chain data will be selected from the local cache and put into the new block as transactions. These transactions are called encapsulated transactions because they encapsulate information from other blockchains.

[0117] 7.2 Generate and broadcast MAC

[0118] The application chain LA calculates the MAC of the new block and broadcasts the new block along with the MAC to all neighboring blockchains in the multi-consortium blockchain network.

[0119] 7.3 Verify MAC

[0120] When a neighboring blockchain receives a new block and its MAC, it calculates the MAC of the new block to ensure its authenticity. If the MAC is valid, the neighboring blockchain replies with a confirmation message to the LA. If the LA receives more than half of the confirmation messages from the neighboring blockchains, it considers the new block accepted; otherwise, the new block is considered rejected.

[0121] 7.4 Complete data synchronization

[0122] If the new block is accepted, the application chain LA adds it to the ledger and removes the cross-chain data already encapsulated in the new block from the local cache; if the new block is rejected, it is discarded and a new block is generated.

[0123] The above process involves cross-chain data migration transactions, which may occur in scenarios where the same data is updated or modified at the same time. In such scenarios, multiple versions of data may exist on each blockchain. To ensure data consistency, this embodiment adopts a multi-version concurrency control mechanism, maintaining a global version number on the cross-chain relay and a local version number on each application chain to ensure the consistency and serialized execution of cross-chain transactions, thereby achieving high-concurrency, reliable data migration across multiple chains in a multi-chain network. Figure 6 As shown, the specific steps are as follows:

[0124] (1) Generate snapshot

[0125] When a cross-chain data migration transaction Tx_change initiated by another application chain needs to modify a piece of data in LA, it first creates a new version of the data, called a snapshot. The snapshot contains the state of the data before Tx_change makes any changes.

[0126] (2) Multi-version data creation

[0127] Transaction Tx_change modifies a snapshot to reflect the expected changes to the target data; meanwhile, other cross-chain data migration transactions may also be modifying their own snapshots of the same data, thus creating multiple versions of the data.

[0128] (3) New version data generation

[0129] When a Tx_change is ready to commit its modifications to data, it checks for conflicts with other transactions' snapshots of the same data. If there are no conflicts, the Tx_change commits its modifications by creating a new version of the data and adding it to the LA. If a conflict exists, the Tx_change aborts and rolls back its modifications. It then retryes the transaction with the new data snapshot and commits its modifications if there are no conflicts.

[0130] Example 2

[0131] In one or more embodiments, a cross-chain data trusted migration system for a multi-consortium blockchain network is disclosed, including a data migration module and a data synchronization module:

[0132] The data migration module is configured to: based on the relay cross-chain mechanism, the data request chain requests cross-chain data from each adjacent application chain, and uses the cross-chain mutual trust contract to verify the trustworthiness of the two chains in the cross-chain data migration transaction, and receive the cross-chain data sent by the adjacent application chain that has passed the verification.

[0133] The data synchronization module is configured to: construct a new block for the new data received by the data request chain, and broadcast the new block to all adjacent blockchains to achieve multi-chain data synchronization;

[0134] The cross-chain data migration transaction uses multi-version concurrency control to create multiple versions of the same data, and ensures data consistency through conflict checks of multiple versions.

[0135] Example 3

[0136] The purpose of this embodiment is to provide a computer-readable storage medium.

[0137] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a cross-chain data trusted migration method for a multi-consortium blockchain network as described in Embodiment 1 of this disclosure.

[0138] Example 4

[0139] The purpose of this embodiment is to provide an electronic device.

[0140] An electronic device includes a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in a cross-chain data trusted migration method for a multi-consortium blockchain network as described in Embodiment 1 of this disclosure.

[0141] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for trusted cross-chain data migration in a multi-consortium blockchain network, characterized in that, include: Based on the relay cross-chain mechanism, the data request chain requests cross-chain data from each adjacent application chain and uses a cross-chain mutual trust contract to verify the trustworthiness of the two chains in the cross-chain data migration transaction. It receives cross-chain data sent by adjacent application chains that have passed the verification. Specifically, during the data migration phase, the application chain registers its chain information on the relay chain in advance; the application chain LA generates a request message msg and sends it to the consensus node CA on the relay chain for asynchronous consensus. After the consensus is passed, the shared state tree node SN creates a migration transaction Tx-migrate. The consensus node CB sends msg to the interaction node IB of the application chain LB. After receiving msg, IB selects a cryptographic hash function to generate a message authentication code MAC and sends the requested data data and MAC to the interaction node IA of the application chain LA; after receiving the data, IA verifies the data and chooses whether to add it to the local cache. Subsequently, SN updates the shared state tree. After completing the cross-chain data migration transaction with application chain LB, application chain LA repeats the above operation until it has received cross-chain data from all adjacent blockchains. The data request chain constructs a new block for the new data it receives and broadcasts the new block to all neighboring blockchains to achieve multi-chain data synchronization. Specifically, during the multi-chain data synchronization phase, the application chain LA selects local data to put into the new block and calculates its MAC. The new block and MAC are then broadcast to all neighboring blockchains. The neighboring blockchains verify the MAC and choose whether to accept it. If accepted, the application chain LA adds the new block to its ledger. Specifically, a shared state tree node is set on the relay chain of the relay cross-chain mechanism to track the status of the cross-chain data migration transactions. A multi-version concurrency control mechanism is introduced to resolve cross-chain data migration transaction conflicts. Specifically, when the cross-chain data migration transaction Tx_change needs to modify data in the application chain LA, a snapshot is first created. Tx_change modifies the snapshot to reflect the expectation of the data and checks whether there is a conflict with other transactions. If there is no conflict, the modification is committed; otherwise, Tx_change will abort and roll back.

2. The cross-chain data trusted migration method for a multi-consortium blockchain network as described in claim 1, characterized in that, The relay-based cross-chain mechanism, where the data request chain requests cross-chain data from each adjacent application chain, involves traversing each adjacent application chain in the set of adjacent application chains. Specifically: In a multi-consortium blockchain network, all application chains register their chain information with the relay chain, which then assigns access keys and consensus nodes to each application chain. The data request chain initiates a request based on a cross-chain data migration transaction and sends a request message verified through consensus to the data provider chain. The request message includes the latest cached data of the data request chain and the message authentication code of the data. The data provider chain generates a response message and sends it to the data request chain; The data request chain utilizes cross-chain mutual trust contracts to verify the trustworthiness of two chains in cross-chain data migration transactions by comparing trust vectors. The data request link is received and the cross-chain data is verified.

3. The cross-chain data trusted migration method for a multi-consortium blockchain network as described in claim 2, characterized in that, The data request chain initiates a request based on a cross-chain data migration transaction and sends the consensus-verified request message to the data provider chain, specifically as follows: The data request chain selects a neighboring blockchain from the set of adjacent application chains to serve as the data provider chain; The interaction nodes in the data request chain generate request messages in a predefined format; The request message is sent to the consensus node assigned by the relay chain via the registered communication link; Upon receiving the request message, the consensus node broadcasts the request message to all consensus nodes on the relay chain using a peer-to-peer protocol; Invoke the asynchronous consensus protocol to achieve consensus; Once consensus is reached, the shared state tree node of the relay chain creates a cross-chain data migration transaction, and the consensus node of the data provider chain sends the request message to the interaction node of the data provider chain.

4. The cross-chain data trusted migration method for a multi-consortium blockchain network as described in claim 3, characterized in that, The specific steps of the asynchronous consensus protocol are as follows: Each consensus node sets up a local buffer and a timer; The consensus nodes of the data request chain receive the request messages from the interaction nodes and then broadcast them to all consensus nodes on the relay chain. Each consensus node constructs a proposal based on the request information and broadcasts it to other consensus nodes, selecting the best proposal from a set of proposals as the consensus object for the current round; Consensus nodes vote on the best proposal and broadcast the voting results to other consensus nodes; Determine whether the voting results meet the preset consensus conditions. If they do, a consensus is reached, a cross-chain data migration transaction is created, and a confirmation message is sent to the data request chain.

5. The cross-chain data trusted migration method for a multi-consortium blockchain network as described in claim 2, characterized in that, The response message generated by the data providing chain includes all cross-chain data in the local cache and the message authentication code of that data. The shared state tree node executes the cross-chain data migration transaction, and the interaction node of the data providing chain sends the response message to the interaction node of the data request chain.

6. The cross-chain data trusted migration method for a multi-consortium blockchain network as described in claim 2, characterized in that, The comparison trust vector is specifically: Using the trust vector comparator of the cross-chain mutual trust contract, the trust vector of the interaction node of the data providing chain is compared with the trust vector of the interaction node of the data requesting chain. If the comparison result meets the preset trust standard of the data requesting chain, the response message from the interaction node is received; otherwise, the response message from the interaction node is rejected.

7. The cross-chain data trusted migration method for a multi-consortium blockchain network as described in claim 2, characterized in that, The data request link receives and verifies cross-chain data, specifically as follows: When the interaction node of the data request chain receives the response message sent by the interaction node of the data provider chain, it recalculates the message authentication code of the cross-chain data in the response message and compares it with the message authentication code of the response message. If they match, incremental caching is performed; otherwise, caching is rejected. The shared state tree node marks the cross-chain data migration transaction as completed and updates the shared state tree.

8. A trusted cross-chain data migration system for a multi-consortium blockchain network, characterized in that, Includes a data migration module and a data synchronization module: The data migration module is configured as follows: Based on the relay cross-chain mechanism, the data request chain requests cross-chain data from each adjacent application chain, and uses a cross-chain mutual trust contract to verify the trustworthiness of the two chains in the cross-chain data migration transaction. It receives cross-chain data sent by adjacent application chains that have passed the verification. Specifically, during the data migration phase, the application chain registers its chain information on the relay chain in advance; the application chain LA generates a request message msg and sends it to the consensus node CA on the relay chain for asynchronous consensus. After consensus is passed, the shared state tree node SN creates a migration transaction Tx-migrate. The consensus node CB sends msg to the interaction node IB of the application chain LB. After receiving msg, IB selects a cryptographic hash function to generate a message authentication code MAC, and sends the requested data data and MAC to the interaction node IA of the application chain LA; after receiving the data, IA verifies the data and chooses whether to add it to the local cache, and then SN updates the shared state tree. After completing the cross-chain data migration transaction with application chain LB, application chain LA repeats the above operation until it has received cross-chain data from all adjacent blockchains. The data synchronization module is configured as follows: the data request chain constructs a new block for the received new data and broadcasts the new block to all neighboring blockchains to achieve multi-chain data synchronization. Specifically, during the multi-chain data synchronization phase, the application chain LA selects local data to put into the new block and calculates its MAC, and broadcasts the new block and MAC to all neighboring blockchains; the neighboring blockchains verify the MAC and choose whether to accept it. If accepted, the application chain LA adds the new block to its ledger. Specifically, a shared state tree node is set on the relay chain of the relay cross-chain mechanism to track the status of the cross-chain data migration transactions. A multi-version concurrency control mechanism is introduced to resolve cross-chain data migration transaction conflicts. Specifically, when the cross-chain data migration transaction Tx_change needs to modify data in the application chain LA, a snapshot is first created. Tx_change modifies the snapshot to reflect the expectation of the data and checks whether there is a conflict with other transactions. If there is no conflict, the modification is committed; otherwise, Tx_change will abort and roll back.

9. An electronic device, characterized in that it comprises: Memory is used to store computer-readable instructions in a non-transitory manner. as well as Processor, for executing the computer-readable instructions, When the computer-readable instructions are executed by the processor, they perform the method described in any one of claims 1-7.

10. A storage medium, characterized in that, The computer-readable instructions are stored non-transitory, wherein when the non-transitory computer-readable instructions are executed by a computer, the instructions of the method according to any one of claims 1-7 are executed.

Images