Elastic consensus verification and node resource scheduling method and system for cross-chain architecture

Abstract

The invention provides a cross-chain architecture-oriented elastic consensus verification and node resource scheduling method and system, and a storage medium. The method comprises the steps of initiating a cross-chain transaction request by a block chain node, performing internal consensus, sending a cross-chain gateway, performing gateway analysis and sending a relay chain, performing relay chain node verification and signature, and adopting a BFT consensus mechanism to achieve a consensus and performing chaining. According to the invention, transaction legality can be verified through the smart contract, and high efficiency and consistency of cross-chain transaction are ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain cross-chain architecture, and more specifically, to a method, system and storage medium for elastic consensus verification and node resource scheduling for a cross-chain architecture. Background Art

[0002] Existing blockchain technology faces a series of challenges in cross-chain communication and transaction processing. The main problem is that there are differences in technical architecture and consensus mechanisms between different blockchain systems, which makes it difficult for them to interact and share data directly. Existing cross-chain technology usually relies on fixed consensus mechanisms and static node resource allocation, which requires complex protocol conversion and adaptation when dealing with consensus differences between heterogeneous chains, thereby reducing efficiency. In addition, the single-chain consensus mechanism mainly focuses on intra-chain state updates and verification, lacks support for inter-chain state consistency, and makes cross-chain transaction processing face the risk of delays and failures. In terms of node resource scheduling, the static resource allocation method cannot adapt to high-concurrency transactions or burst traffic, resulting in low resource utilization and failure to meet actual transaction needs. These problems limit the application scope and efficiency of cross-chain technology and affect the further development and popularization of blockchain technology.

[0003] In the process of implementing the embodiments of the present invention, the inventors found that there are at least the following problems or defects in the prior art: the existing cross-chain architecture lacks flexibility and dynamism, cannot adapt to the needs of different chains and dynamic changes in the network environment, and there are challenges in ensuring the atomicity and state consistency of cross-chain transactions. Summary of the invention

[0004] The present invention provides a cross-chain architecture-oriented elastic consensus verification and node resource scheduling method, system and storage medium.

[0005] In a first aspect of the present invention, a flexible consensus verification method for a cross-chain architecture is provided, comprising:

[0006] Step S1: The blockchain node initiates a cross-chain transaction request and packages the transaction information;

[0007] Step S2: The consensus process is completed within the blockchain to ensure the validity and legitimacy of the transaction;

[0008] Step S3: Send the cross-chain transaction request to the cross-chain gateway;

[0009] Step S4: The cross-chain gateway parses the request content, generates a transaction in a unified data format and sends it to the relay chain;

[0010] Step S5: The relay chain node receives the transaction, confirms the transaction source chain based on the chain ID information, and verifies the rules through the smart contract;

[0011] Step S6: The relay chain node verifies the transaction, signs it, attaches the verification result, and packages the transaction and sends it to other nodes;

[0012] Step S7: The relay chain adopts the BFT consensus mechanism to collect verification results. If more than 2 / 3 of the nodes have valid verification results, a consensus is reached and the results are uploaded to the chain.

[0013] Furthermore, the smart contract is deployed by the relay chain administrator to verify the legitimacy and validity of the transaction.

[0014] In a second aspect of the present invention, a node resource scheduling method for a cross-chain architecture is provided, comprising:

[0015] Step R1: When the relay chain is initialized, the initial shards are divided according to the configuration file;

[0016] Step R2: The chain gateway sends the transaction to the corresponding shard according to the transaction type field in the transaction information;

[0017] Step R3: After receiving the cross-chain transaction, the internal nodes of the shard complete the consensus and store the transaction;

[0018] Step R4: If the nodes in the shard fail to reach consensus within the specified time, the node resource scheduling process is triggered;

[0019] Step R5: The relay chain’s built-in node detection algorithm detects the node’s integrity value and adjusts the node based on the integrity value;

[0020] Step R6: If the number of nodes in the shard is lower than the specified number, add new nodes to the shard through the node detection algorithm;

[0021] Step R7: The newly added node synchronizes the ledger data through the inter-shard state synchronization mechanism and constructs a Merkle tree for state consistency verification.

[0022] Furthermore, the inter-shard state synchronization mechanism includes constructing a Merkle tree of the latest state of the current shard. After the newly added node synchronizes the ledger data, the Merkle tree is constructed again and the root hash value is compared to verify the state consistency.

[0023] In a third aspect of the present invention, a cross-chain architecture-oriented elastic consensus verification and node resource scheduling system is provided, comprising:

[0024] The cross-chain gateway module is used to parse cross-chain transaction requests and send them to the relay chain;

[0025] Relay chain module, used to perform rule verification, consensus chain and node resource scheduling;

[0026] Smart contract module, used to deploy and execute transaction verification rules;

[0027] Node detection and scheduling module, used to detect node integrity and perform node scheduling;

[0028] The inter-chip state synchronization module is used to synchronize ledger data and verify state consistency when adding nodes.

[0029] Furthermore, the relay chain module adopts a sharding architecture to improve the efficiency of cross-chain transaction processing.

[0030] Furthermore, the smart contract module allows the business chain to register and deploy transaction verification rules on the relay chain.

[0031] Furthermore, the node detection and scheduling module can dynamically adjust the number of nodes in a shard to optimize resource allocation.

[0032] Furthermore, the inter-shard state synchronization module ensures that the state of the newly added node is consistent with that of other nodes in the shard.

[0033] In a fourth aspect of the present invention, a computer-readable storage medium is provided, which includes instructions, and when the instructions are executed on a computer, the computer executes any one of the methods in the first aspect.

[0034] The above-mentioned embodiments of the present invention have at least the following beneficial effects: the elastic consensus verification and node resource scheduling method for cross-chain architecture provided by the present invention can effectively solve the compatibility problem of heterogeneous blockchains in cross-chain operations in the prior art, so that different types of blockchains can be interconnected efficiently and support flexible interaction between multiple blockchains. By extracting the transaction rules of each business chain to verify the formation of a flexible transaction verification mechanism, it is ensured that the status of each business chain remains consistent during the cross-chain operation process, which can avoid transaction failures or data loss caused by inconsistent inter-chain status, and improve the reliability of cross-chain transactions.

[0035] In addition, the relay chain shard node resource scheduling mechanism introduced by the present invention can dynamically adjust the number of nodes in each shard in the relay chain according to business needs, optimize resource allocation, and improve the processing capacity and efficiency of the cross-chain system under high load conditions. At the same time, the present invention can solve the state synchronization problem of newly added nodes in the node scheduling process, avoid the problem of unsynchronized data of newly added nodes, ensure the consistency of the ledger status of each node, and enhance the stability and security of the entire cross-chain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The above and other objects, features and advantages of the exemplary embodiments of the present invention will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the accompanying drawings, several embodiments of the present invention are shown in an exemplary and non-limiting manner, in which:

[0037] Figure 1 A schematic diagram of a flow chart of a flexible consensus verification method for a cross-chain architecture provided by an embodiment of the present invention;

[0038] Figure 2 A schematic diagram of a process flow of a node resource scheduling method for a cross-chain architecture provided by an embodiment of the present invention;

[0039] Figure 3 A schematic diagram of the structure of a flexible consensus verification and node resource scheduling method for a cross-chain architecture provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0040] The principles and spirit of the present invention will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. On the contrary, these embodiments are provided to make the present invention more thorough and complete, and to fully convey the scope of the present invention to those skilled in the art.

[0041] Those skilled in the art know that the embodiments of the present invention can be implemented as a system, device, apparatus, method or computer program product. Therefore, the present invention can be specifically implemented in the following forms, namely: complete hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0042] It should be noted that any number of elements in the drawings is for illustration rather than limitation, and any naming is only for distinction and does not have any limiting meaning.

[0043] Reference below Figure 1 , Figure 1 The following is a flow chart of a flexible consensus verification method for a cross-chain architecture provided by an embodiment of the present invention. Figure 1 As shown, a flexible consensus verification method 100 for a cross-chain architecture includes:

[0044] Step S1: The blockchain node initiates a cross-chain transaction request and packages the transaction information;

[0045] Step S2: The consensus process is completed within the blockchain to ensure the validity and legitimacy of the transaction;

[0046] Step S3: Send the cross-chain transaction request to the cross-chain gateway;

[0047] Step S4: The cross-chain gateway parses the request content, generates a transaction in a unified data format and sends it to the relay chain;

[0048] Step S5: The relay chain node receives the transaction, confirms the transaction source chain based on the chain ID information, and verifies the rules through the smart contract;

[0049] Step S6: The relay chain node verifies the transaction, signs it, attaches the verification result, and packages the transaction and sends it to other nodes;

[0050] Step S7: The relay chain adopts the BFT consensus mechanism to collect verification results. If more than 2 / 3 of the nodes have valid verification results, a consensus is reached and the results are uploaded to the chain.

[0051] It should be noted that this embodiment relates to a flexible consensus verification method for a cross-chain architecture, which includes a blockchain node initiating a cross-chain transaction request and packaging transaction information. Here, a blockchain node refers to a single computing entity that constitutes a blockchain network, which is responsible for verifying transactions and maintaining the consistency of the blockchain. A cross-chain transaction request refers to a request from a node in a blockchain network to interact with another blockchain network.

[0052] Specifically, when a blockchain node initiates a cross-chain transaction request, it packages the relevant transaction information into a message containing all necessary data. This data may include the addresses of both parties to the transaction, the transaction amount, timestamp, signature, etc. The packaging process involves organizing this information according to a specific data structure for subsequent processing and verification.

[0053] Preferably, blockchain nodes can use a specific serialization format, such as JSON or Protocol Buffers, when packaging transaction information to ensure readability and consistency of the information.

[0054] Furthermore, in order to improve security, nodes can also add mechanisms such as multi-signature or time lock in the packaging process to prevent transactions from being tampered with or executed under specific conditions. These mechanisms can be customized according to specific business needs and security requirements.

[0055] In some embodiments, the smart contract is deployed by a relay chain administrator to verify the legitimacy and validity of the transaction.

[0056] It should be noted that this embodiment relates to a flexible consensus verification method for a cross-chain architecture, in which smart contracts are deployed by relay chain administrators to verify the legality and validity of transactions. Here, a smart contract is a computer program that automatically executes, controls or records legal events and actions. It runs on the blockchain and automatically executes the terms of the contract when the preset conditions are met. The relay chain administrator refers to the individual or organization responsible for managing the operation and maintenance of the relay chain, and they have the right to deploy and update smart contracts.

[0057] Specifically, after being deployed on the relay chain, the smart contract will contain a series of predefined rules and logics, which are used to verify whether the cross-chain transaction complies with the consensus mechanism and transaction rules of the initiating chain and the receiving chain. The deployment of smart contracts involves writing contract code, testing, auditing, and finally publishing it on the blockchain. During the deployment process, the administrator needs to set the contract parameters, such as gas limit, execution permissions, and contract storage fees.

[0058] Preferably, the deployment of smart contracts can be completed through a graphical interface or command line tool to adapt to the operating habits of different administrators. In addition, in order to improve the security and reliability of smart contracts, formal verification and other methods can be used to ensure the correctness of the contract logic.

[0059] Furthermore, during the contract execution process, monitoring and alarm mechanisms can be set up to respond promptly when anomalies occur. These mechanisms can serve as a supplementary solution for smart contract deployment and management to ensure the smooth progress of cross-chain transactions.

[0060] like Figure 2 As shown, a node resource scheduling method 200 for a cross-chain architecture in some embodiments includes:

[0061] Step R1: When the relay chain is initialized, the initial shards are divided according to the configuration file;

[0062] Step R2: The chain gateway sends the transaction to the corresponding shard according to the transaction type field in the transaction information;

[0063] Step R3: After receiving the cross-chain transaction, the internal nodes of the shard complete the consensus and store the transaction;

[0064] Step R4: If the nodes in the shard fail to reach consensus within the specified time, the node resource scheduling process is triggered;

[0065] Step R5: The relay chain’s built-in node detection algorithm detects the node’s integrity value and adjusts the node based on the integrity value;

[0066] Step R6: If the number of nodes in the shard is lower than the specified number, add new nodes to the shard through the node detection algorithm;

[0067] Step R7: The newly added node synchronizes the ledger data through the inter-shard state synchronization mechanism and constructs a Merkle tree for state consistency verification.

[0068] It should be noted that this embodiment describes a node resource scheduling method for a cross-chain architecture, which includes dividing the initial shards according to the configuration file when the relay chain is initialized. Here, the relay chain refers to a blockchain that acts as a bridge between multiple blockchains and is responsible for processing cross-chain transactions and communications. Sharding is a technology that divides a blockchain network into smaller parts, each part is called a shard, which can improve the processing power and efficiency of the entire network.

[0069] Specifically, the relay chain will divide the initial shards according to the preset configuration file when it is initialized. The configuration file contains the number of shards, the number of nodes in each shard, and other related network parameters. These parameters can be set according to the actual needs and expected load of the network. For example, if the network is expected to have high-concurrency cross-chain transactions, more shards and more nodes in each shard can be set to improve processing power.

[0070] Preferably, the sharding process can be automated by an algorithm that optimizes the configuration of shards based on the geographic location of the nodes, processing power, and other performance metrics. In addition, the configuration of shards is not static and can be adjusted dynamically based on the actual operation of the network. For example, if the load on a shard is too high, the system can automatically increase the number of nodes in that shard or create new shards to distribute the load. This dynamic adjustment can be achieved based on real-time monitoring data and preset performance thresholds. These dynamic adjustment mechanisms can serve as a supplementary solution to node resource scheduling to ensure that the relay chain can efficiently process cross-chain transactions.

[0071] In some embodiments, the inter-shard state synchronization mechanism includes constructing a Merkle tree of the latest state of the current shard. After the newly added node synchronizes the ledger data, the Merkle tree is constructed again and the root hash value is compared to verify the state consistency.

[0072] It should be noted that this embodiment relates to a node resource scheduling method for a cross-chain architecture, in which the inter-shard state synchronization mechanism includes constructing a Merkle tree of the latest state of the current shard. After the newly added node synchronizes the ledger data, the Merkle tree is constructed again and the root hash value is compared to verify the state consistency. Here, the Merkle tree is a data structure used to verify the integrity of data. It verifies the integrity of the entire data set by dividing the data into multiple blocks, then hashing each block, and finally generating a single root hash value.

[0073] Specifically, the implementation of the inter-shard state synchronization mechanism involves using the Merkle tree to ensure data consistency when synchronizing ledger data between shards. When a new node joins a shard, it will first synchronize the latest ledger data from other nodes in the current shard.

[0074] More specifically, after synchronization is completed, the new node will construct its own Merkle tree based on this data and generate a root hash value. At the same time, other nodes in the current shard will also construct a Merkle tree based on the same ledger data and generate a root hash value.

[0075] Preferably, in order to improve the efficiency and accuracy of state synchronization, some optimization measures can be adopted. For example, an efficient data synchronization algorithm can be used to reduce the amount of network transmission and synchronize only the changed part of the ledger data instead of the entire ledger.

[0076] Furthermore, a threshold can be set, and when the root hash value of the Merkle tree does not match, the system will automatically trigger resynchronization or adopt other error correction mechanisms. These mechanisms can serve as a supplementary solution for inter-shard state synchronization to ensure that new nodes can quickly and accurately reach state consistency with other nodes in the shard.

[0077] like Figure 3 As shown, in some embodiments, a flexible consensus verification and node resource scheduling system 300 for a cross-chain architecture is provided, and the system 300 includes:

[0078] The cross-chain gateway module 301 is used to parse the cross-chain transaction request and send it to the relay chain;

[0079] Relay chain module 302, used to perform rule verification, consensus chaining and node resource scheduling;

[0080] Smart contract module 303, used to deploy and execute transaction verification rules;

[0081] The node detection and scheduling module 304 is used to detect node integrity and perform node scheduling;

[0082] The inter-chip state synchronization module 305 is used to synchronize the ledger data and verify the state consistency when adding a node.

[0083] It should be noted that this embodiment describes a flexible consensus verification and node resource scheduling system for a cross-chain architecture, which includes a cross-chain gateway module, a relay chain module, a smart contract module, a node detection and scheduling module, and an inter-chip state synchronization module. Here, the cross-chain gateway module refers to the component responsible for processing transaction requests from different blockchain networks and forwarding them to the relay chain. The relay chain module refers to the core blockchain component responsible for executing cross-chain transaction verification, consensus formation, and node resource scheduling.

[0084] Specifically, after receiving the transaction request from the business chain, the cross-chain gateway module will parse and generate a transaction data packet in a unified format, and then send it to the relay chain module. After receiving the transaction data packet, the relay chain module will verify the transaction using the verification rules in the smart contract module, and schedule node resources through the node detection and scheduling module. The inter-shard state synchronization module is responsible for ensuring that the new node can maintain the consistency of the ledger state with other nodes in the shard when the node joins or leaves the shard.

[0085] Preferably, the relay chain module can adopt a sharding architecture to improve the efficiency of cross-chain transaction processing. This means that the relay chain can be divided into multiple sub-chains that are processed in parallel, and each sub-chain (shard) is responsible for processing a part of the transaction, thereby improving the overall processing speed and throughput. The smart contract module can allow the business chain to register and deploy transaction verification rules on the relay chain, so that different business chains can customize the verification logic according to their own needs. The node detection and scheduling module can dynamically adjust the number of nodes in the shard to optimize resource allocation, which can be achieved by real-time monitoring of network load and node performance. The inter-shard state synchronization module ensures that the newly added node is consistent with the state of other nodes in the shard, which can be done through Merkle trees or other data synchronization technologies. The collaborative work of these modules enables the entire system to process cross-chain transactions efficiently and securely.

[0086] In some embodiments, the relay chain module adopts a sharding architecture to improve the efficiency of cross-chain transaction processing.

[0087] It should be noted that this embodiment describes a system for a cross-chain architecture, in which the relay chain module adopts a sharding architecture to improve the efficiency of cross-chain transaction processing. Here, sharding architecture refers to a technology that divides a blockchain network into multiple smaller, manageable parts, each of which is called a shard. This architecture allows each shard to process transactions and smart contracts independently, thereby improving the processing power and throughput of the entire network.

[0088] Specifically, when the relay chain module adopts a sharding architecture, it will distribute the nodes in the network to different shards. Each shard can process transactions in parallel, which can reduce the load on a single node and improve the efficiency of the overall network. The number of shards can be set based on the size and transaction volume of the network. For example, the number of shards can be dynamically adjusted based on the actual needs and expected load of the network. The creation and management of shards can be achieved through specific algorithms that take into account factors such as node performance, geographical location, and network connection quality.

[0089] Preferably, in order to further optimize the performance of the sharding architecture, some advanced scheduling strategies can be implemented. For example, a load balancing algorithm can be designed that monitors the transaction load of each shard in real time and automatically redistributes transactions to lighter shards when necessary.

[0090] Furthermore, a dynamic adjustment mechanism can be set up to adjust the size and number of shards based on the real-time performance data of the network. These mechanisms can serve as a supplementary solution to the sharding architecture to ensure that the relay chain module can adapt to changing network conditions and maintain high efficiency and stability.

[0091] In some embodiments, the smart contract module allows the business chain to register and deploy transaction verification rules on the relay chain.

[0092] It should be noted that this embodiment relates to a system in which a smart contract module allows a business chain to register and deploy transaction verification rules on a relay chain. Here, the smart contract module refers to the component in the system responsible for managing and executing smart contracts, and the business chain refers to each blockchain network involved in cross-chain transactions. Registration refers to the process of identity confirmation and information registration of the business chain on the relay chain so that specific transaction verification rules can be deployed on the relay chain.

[0093] Specifically, the smart contract module enables business chains to register on the relay chain through a series of predefined interfaces and protocols. During the registration process, the business chain needs to provide relevant information about its chain, such as the chain identifier, consensus mechanism, transaction verification rules, etc. This information will be verified and stored by the relay chain so that subsequent cross-chain transactions can reference these rules for verification. Deploying transaction verification rules involves writing smart contract code that contains the transaction verification logic unique to the business chain, and then uploading it to the relay chain.

[0094] Preferably, the smart contract module can provide a graphical user interface to make it easier for business chain administrators to register and deploy operations. In addition, some security measures can be implemented, such as code auditing and formal verification of smart contracts, to ensure the security and correctness of deployed smart contracts. Some tools and libraries can also be provided to help business chain developers quickly develop and test smart contracts. These tools and measures can serve as a supplementary solution to the smart contract module to improve the security and efficiency of cross-chain transactions.

[0095] In some embodiments, the node detection and scheduling module can dynamically adjust the number of nodes in a shard to optimize resource allocation.

[0096] It should be noted that this embodiment describes a system in which the node detection and scheduling module can dynamically adjust the number of nodes in a shard to optimize resource allocation. Here, the node detection and scheduling module refers to the component in the system responsible for monitoring node performance and adjusting node distribution according to network conditions. Dynamic adjustment means that the system can automatically change the configuration of nodes based on real-time data and preset policies to adapt to different network needs and improve efficiency.

[0097] Specifically, the node detection and scheduling module monitors the performance of nodes in each shard in real time, including key indicators such as processing speed, transaction throughput, and online status. Based on these indicators, the module evaluates the load of each shard and decides whether to increase or decrease the number of nodes. For example, if the transaction volume of a shard increases suddenly, the module may automatically add new nodes to the shard to share the load and improve processing power. On the contrary, if the load of a shard is low, the module may reallocate the node to a shard that needs more resources.

[0098] Preferably, the node detection and scheduling module can use machine learning algorithms to predict network load and optimize node allocation. Such algorithms can predict future network demand based on historical data and pattern recognition, and make resource adjustments in advance.

[0099] Furthermore, a feedback mechanism can be set up to adjust the parameters of the prediction model according to the actual network performance and user feedback to improve the accuracy of the prediction. These advanced features can be used as a supplementary solution to the node detection and scheduling module to ensure that the system can manage resources more intelligently and efficiently.

[0100] In some embodiments, the inter-shard state synchronization module ensures that the state of the newly added node is consistent with that of other nodes in the shard.

[0101] It should be noted that this embodiment relates to a system in which an inter-shard state synchronization module ensures that the state of a newly added node is consistent with that of other nodes in the shard. Here, the inter-shard state synchronization module refers to a component in the system that is responsible for synchronizing the ledger data of a new node with that of other nodes in the shard when the new node joins the shard. State consistency means ensuring that the data state of the new node is exactly the same as the data state of other nodes in the shard, so that all nodes in the network can operate based on the same data.

[0102] Specifically, when a new node joins a shard, the inter-shard state synchronization module will synchronize the latest ledger data from other nodes in the shard. During this process, the new node will receive records of all historical transactions in the shard and update its own ledger until its ledger is completely consistent with other nodes in the shard. In order to verify whether the synchronized data is correct, the new node will build its own Merkle tree and compare it with the Merkle tree root hash value of other nodes in the shard.

[0103] Preferably, the inter-shard state synchronization module can adopt an incremental synchronization method instead of synchronizing the entire ledger. This means that the new node only synchronizes the transaction data added to the shard since the last synchronization, which can greatly reduce the time and resources required for synchronization.

[0104] Furthermore, a verification mechanism can be set up, for example, to verify the integrity and authenticity of the synchronization data through digital signatures or timestamps. These mechanisms can be used as a supplementary solution to the inter-shard state synchronization module to ensure that new nodes can quickly and securely reach a consistent state with other nodes in the shard.

[0105] The above-mentioned embodiments of the present invention have the following beneficial effects: The elastic consensus verification and node resource scheduling method for cross-chain architecture provided by the present invention can significantly improve the efficiency and reliability of cross-chain transactions. By adopting smart contracts and BFT consensus mechanisms, the method can ensure the legitimacy and validity of transactions between different blockchain systems while maintaining the consistency of the state. This method can solve the compatibility problem of heterogeneous blockchains during cross-chain operations, enable different types of blockchains to be efficiently interconnected, and support flexible interaction between multiple blockchains.

[0106] In addition, the relay chain shard node resource scheduling mechanism introduced by the present invention can dynamically adjust the number of nodes in each shard in the relay chain according to business needs, optimize resource allocation, and improve the processing capacity and efficiency of the cross-chain system under high load conditions. This method can also solve the state synchronization problem of newly added nodes during node scheduling, avoid the problem of unsynchronized data of newly added nodes, ensure the consistency of the ledger status of each node, and enhance the stability and security of the entire cross-chain system.

[0107] Furthermore, the storage medium of the embodiment of the present application stores program instructions that can implement all the above methods, wherein the program instructions can be stored in the above storage medium in the form of a software product, including several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, or terminal devices such as a computer, a server, a mobile phone, and a tablet.

[0108] The above descriptions are only some preferred embodiments of the present invention and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present invention is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above inventive concept. For example, the above features are replaced with (but not limited to) technical features with similar functions disclosed in the embodiments of the present invention to form a technical solution.

Claims

1. A flexible consensus verification method for cross-chain architecture, characterized in that: The following steps are involved: Step S1: The blockchain node initiates a cross-chain transaction request and packages the transaction information; Step S2: The consensus process is completed within the blockchain to ensure the validity and legitimacy of the transaction; Step S3: Send the cross-chain transaction request to the cross-chain gateway; Step S4: The cross-chain gateway parses the request content, generates a transaction in a unified data format and sends it to the relay chain; Step S5: The relay chain node receives the transaction, confirms the transaction source chain based on the chain ID information, and verifies the rules through the smart contract; Step S6: The relay chain node verifies the transaction, signs it, attaches the verification result, and packages the transaction and sends it to other nodes; Step S7: The relay chain adopts the BFT consensus mechanism to collect verification results. If more than 2 / 3 of the nodes have valid verification results, a consensus is reached and the results are uploaded to the chain.

2. The method according to claim 1, characterized in that The smart contract is deployed by the relay chain administrator to verify the legitimacy and validity of the transaction.

3. A node resource scheduling method for a cross-chain architecture, characterized in that: The following steps are involved: Step R1: When the relay chain is initialized, the initial shards are divided according to the configuration file; Step R2: The chain gateway sends the transaction to the corresponding shard according to the transaction type field in the transaction information; Step R3: After receiving the cross-chain transaction, the internal nodes of the shard complete the consensus and store the transaction; Step R4: If the nodes in the shard fail to reach consensus within the specified time, the node resource scheduling process is triggered; Step R5: The relay chain’s built-in node detection algorithm detects the node’s integrity value and adjusts the node based on the integrity value; Step R6: If the number of nodes in the shard is lower than the specified number, add new nodes to the shard through the node detection algorithm; Step R7: The newly added node synchronizes the ledger data through the inter-shard state synchronization mechanism and constructs a Merkle tree for state consistency verification.

4. The method according to claim 3, characterized in that The inter-shard state synchronization mechanism includes constructing a Merkle tree of the latest state of the current shard. After the newly added node synchronizes the ledger data, the Merkle tree is constructed again and the root hash value is compared to verify the state consistency.

5. A flexible consensus verification and node resource scheduling system for cross-chain architecture, characterized in that: include: The cross-chain gateway module is used to parse cross-chain transaction requests and send them to the relay chain; Relay chain module, used to perform rule verification, consensus chain and node resource scheduling; Smart contract module, used to deploy and execute transaction verification rules; Node detection and scheduling module, used to detect node integrity and perform node scheduling; The inter-chip state synchronization module is used to synchronize ledger data and verify state consistency when adding nodes.

6. The system according to claim 5, characterized in that The relay chain module adopts a sharding architecture to improve the efficiency of cross-chain transaction processing.

7. The system according to claim 5, characterized in that The smart contract module allows the business chain to register and deploy transaction verification rules on the relay chain.

8. The system according to claim 5, characterized in that The node detection and scheduling module can dynamically adjust the number of nodes in a shard to optimize resource allocation.

9. The system according to claim 5, characterized in that The inter-shard state synchronization module ensures that the state of the newly added node is consistent with that of other nodes in the shard.

10. A computer-readable storage medium having a computer program stored thereon, the program being configured to execute the method according to any one of claims 1 to 9.

Images