A cross-chain architecture-oriented elastic consensus verification and node resource scheduling method and system

Abstract

The application provides a cross-chain architecture-oriented flexible consensus verification and node resource scheduling method and system and a storage medium. The method comprises the following steps: a blockchain node initiates a cross-chain transaction request, performs internal consensus, sends a cross-chain gateway, performs gateway analysis and sends a relay chain, a relay chain node verifies and signs, adopts a BFT consensus mechanism to reach consensus and performs on-chain storage. The application can verify the transaction legality through a smart contract, and ensures the efficiency and consistency of cross-chain transactions.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain cross-chain architecture, and more particularly, to a flexible consensus verification and node resource scheduling method and system for cross-chain architecture, and a storage medium. BACKGROUND

[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 mechanism between different blockchain systems, making it difficult for them to directly interact and share data. Existing cross-chain technologies usually rely on fixed consensus mechanisms and static node resource allocation, which, when dealing with consensus differences between heterogeneous chains, require complex protocol conversion and adaptation, thus reducing efficiency. In addition, single-chain consensus mechanisms mainly focus on intra-chain state updates and verification, lacking support for inter-chain state consistency, which makes cross-chain transaction processing face the risk of delay and failure. In terms of node resource scheduling, static resource allocation cannot adapt to high-concurrency transactions or sudden traffic, resulting in low resource utilization and failing to meet actual transaction demands. These problems limit the application range and efficiency of cross-chain technology, affecting the further development and popularization of blockchain technology.

[0003] In the implementation of the embodiments of the present application, the inventors have found that the existing cross-chain architecture lacks flexibility and dynamics, and cannot adapt to the dynamic changes of different chains and network environments, and there are challenges in ensuring the atomicity and state consistency of cross-chain transactions. SUMMARY

[0004] The present application provides a flexible consensus verification and node resource scheduling method and system for cross-chain architecture, and a storage medium.

[0005] In a first aspect of the present application, a flexible consensus verification method for 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 legality of the transaction;

[0008] Step S3: Send the cross-chain transaction demand 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 source chain according to the chain ID information, and performs rule verification through the smart contract;

[0011] Step S6: The relay chain node verifies the transaction signature and attaches the verification result, and sends the transaction to other nodes for packaging;

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

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

[0014] In a second aspect of the present application, 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 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 nodes in the shard complete the consensus and store the transaction;

[0018] Step R4: If the nodes in the shard do not complete the consensus within a specified time, the node resource scheduling process is triggered;

[0019] Step R5: The relay chain built-in node detection algorithm detects the integrity value of the node, and adjusts the node according to the integrity value;

[0020] Step R6: If the number of shard nodes is less than the specified number, a new node is added 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] Further, the inter-shard state synchronization mechanism includes constructing a Merkle tree of the latest state of the current shard, and after the new node synchronizes the ledger data, the Merkle tree is constructed again and the root hash values are compared to verify the state consistency.

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

[0024] A cross-chain gateway module for parsing cross-chain transaction requests and sending them to the relay chain;

[0025] A relay chain module for performing rule verification, consensus chaining, and node resource scheduling;

[0026] A smart contract module for deploying and executing transaction verification rules;

[0027] A node detection and scheduling module for detecting node integrity and scheduling nodes;

[0028] An inter-shard state synchronization module for synchronizing ledger data and verifying state consistency when adding nodes.

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

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

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

[0032] Further, the inter-shard state synchronization module ensures that newly added nodes are consistent with the states of other nodes within the shard.

[0033] In a fourth aspect of the present application, a computer-readable storage medium is provided, which includes instructions that, when executed on a computer, cause the computer to perform the method of any one of the first aspect.

[0034] The above-mentioned embodiments of the present application have at least the following beneficial effects: The cross-chain architecture-oriented flexible consensus verification and node resource scheduling method provided by the present application can effectively solve the compatibility problem of heterogeneous blockchains in cross-chain operation in the prior art, enabling different types of blockchains to efficiently interconnect and interoperate, supporting flexible interaction between multiple blockchains. By extracting transaction rule verification of each business chain to form a flexible transaction verification mechanism, it ensures that the state of each business chain remains consistent during cross-chain operation, avoiding transaction failure or data loss due to inconsistent states between chains, and improving the reliability of cross-chain transactions.

[0035] In addition, the relay chain sharding node resource scheduling mechanism introduced by the present application 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. At the same time, the present application 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 state of each node, and enhance the stability and security of the entire cross-chain system. BRIEF DESCRIPTION OF DRAWINGS

[0036] The above and other objects, features and advantages of the exemplary embodiments of the present application will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0037] Figure 1 A flowchart of a cross-chain architecture-oriented elastic consensus verification method provided by an embodiment of the present application is shown in FIG. 1.

[0038] Figure 2 A flowchart of a cross-chain architecture-oriented node resource scheduling method provided by an embodiment of the present application is shown in FIG. 2.

[0039] Figure 3 A structural diagram of a cross-chain architecture-oriented elastic consensus verification and node resource scheduling method provided by an embodiment of the present application is shown in FIG. 3. DETAILED DESCRIPTION

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

[0041] Those skilled in the art know that the embodiments of the present application can be implemented as a system, device, apparatus, method or computer program product. Therefore, the present application can be embodied as a 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 used for example only, and not for limitation, and any naming is only for distinction, and does not have any limiting meaning.

[0043] Reference will be made to the following Figure 1 , Figure 1 A flowchart of a cross-chain architecture-oriented elastic consensus verification method provided by an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, a cross-chain architecture-oriented elastic consensus verification method 100 includes: Figure 1

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

[0045] Step S2: A consensus process is completed inside the blockchain to ensure the validity and legality of the transaction;

[0046] Step S3: The cross-chain transaction requirement is sent to a 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 a relay chain;

[0048] ​Step S5: The relay chain node receives the transaction, confirms the source chain according to the chain ID information, and performs rule verification through the smart contract.

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

[0050] Step S7: The relay chain adopts BFT consensus mechanism to collect verification results. If more than 2 / 3 of the node quantity has valid verification results, consensus is reached and the transaction is recorded on the chain.

[0051] It should be noted that the present embodiment relates to a flexible consensus verification method for cross-chain architecture, which includes a blockchain node initiating a cross-chain transaction request and packaging transaction information. Here, the 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. Cross-chain transaction request refers to the request of a node in one blockchain network to interact with another blockchain network.

[0052] Specifically, when initiating a cross-chain transaction request, the blockchain node will package the relevant transaction information to form a message containing all necessary data. These data may include the addresses of both parties, transaction amount, timestamp, signature, etc. The packaging process involves organizing these information according to a specific data structure to facilitate subsequent processing and verification.

[0053] Preferably, the blockchain node 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] Further, to improve security, the node can also add mechanisms such as multi-signature or time lock during packaging to prevent transaction tampering or execution under certain conditions. These mechanisms can be customized according to specific business needs and security requirements.

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

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

[0057] Specifically, after the smart contract is deployed on the relay chain, it will contain a series of predefined rules and logic for verifying whether cross-chain transactions comply with the consensus mechanisms and transaction rules of the originating chain and the receiving chain. The deployment of the smart contract involves writing contract code, testing, auditing, and finally publishing on the blockchain. During the deployment process, the administrator needs to set parameters such as gas limit, execution authority, and contract storage fee.

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

[0059] Further, during the execution of the contract, monitoring and alarm mechanisms can also be set up to respond promptly in the event of abnormalities. These mechanisms can serve as a supplementary solution to the deployment and management of smart contracts to ensure the smooth progress of cross-chain transactions.

[0060] As shown in Figure 2 , a node resource scheduling method 200 for a cross-chain architecture of some embodiments, the method 200 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 sends transactions 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 node of the shard completes the consensus and stores the transaction;

[0064] Step R4: If the nodes within the shard do not complete the consensus within the specified time, the node resource scheduling process is triggered;

[0065] Step R5: The built-in node detection algorithm of the relay chain detects the integrity value of the node and adjusts the node according to the integrity value;

[0066] Step R6: If the number of shard nodes is less than the specified number, new nodes are added to the shard through the node detection algorithm;

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

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

[0069] Specifically, the relay chain will divide the initial shards according to the preset configuration file during initialization. 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 of cross-chain transactions, more shards and more nodes in each shard can be set to improve processing capacity.

[0070] Preferably, the sharding process can be automatically completed by an algorithm that optimizes the configuration of shards based on the geographical location, processing capacity, and other performance indicators of the nodes. In addition, the configuration of shards is not static and can be dynamically adjusted according to the actual running situation of the network. For example, if the load of a certain 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 based on real-time monitoring data and preset performance thresholds. These dynamic adjustment mechanisms can be used as a complementary solution to node resource scheduling to ensure that the relay chain can efficiently handle 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, and after the newly added node synchronizes the ledger data, the Merkle tree is constructed again and the root hash values are compared to verify the consistency of the state.

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

[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 first synchronizes the latest ledger data from other nodes in the current shard.

[0074] More specifically, after synchronization is complete, 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 Merkle trees based on the same ledger data and generate root hash values.

[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 network transmission, and only the changed part of the ledger data is synchronized, rather than the entire ledger.

[0076] Further, a threshold can be set, when the root hash value of the Merkle tree does not match, the system will automatically trigger re-synchronization or other error correction mechanisms. These mechanisms can be used as a supplement to inter-shard state synchronization to ensure that the new node can quickly and accurately reach a state agreement with other nodes in the shard.

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

[0078] Cross-chain gateway module 301, for parsing cross-chain transaction request and sending to relay chain;

[0079] Relay chain module 302, for performing rule verification, consensus on-chain and node resource scheduling;

[0080] Smart contract module 303, for deploying and executing transaction verification rules;

[0081] Node detection and scheduling module 304, for detecting node integrity and node scheduling;

[0082] Inter-shard state synchronization module 305, for synchronizing ledger data and verifying state consistency when adding nodes.

[0083] It should be noted that the present embodiment describes a cross-chain architecture-oriented flexible consensus verification and node resource scheduling system, which includes a cross-chain gateway module, a relay chain module, a smart contract module, a node detection and scheduling module and an inter-shard 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 performing cross-chain transaction verification, consensus formation and node resource scheduling.

[0084] Specifically, the cross-chain gateway module receives transaction requests from business chains, parses and generates uniform format transaction data packets, and then sends them to the relay chain module. The relay chain module receives the transaction data packets, verifies the transactions using the verification rules in the smart contract module, and schedules node resources through the node detection and scheduling module. The inter-shard state synchronization module ensures that new nodes can maintain the consistency of the ledger state with other nodes in the shard when nodes join or leave the shard.

[0085] Preferably, the relay chain module can adopt a sharding architecture to improve cross-chain transaction processing efficiency. This means that the relay chain can be divided into multiple parallel processing sub-chains, each responsible for processing a part of the transaction, thereby improving the overall processing speed and throughput. The smart contract module can allow business chains to register and deploy transaction verification rules on the relay chain, so that different business chains can customize 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 newly added nodes are consistent with the state of other nodes in the shard, which can be achieved through a Merkle tree or other data synchronization technology. The coordinated work of these modules enables the entire system to efficiently and securely process cross-chain transactions.

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

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

[0088] Specifically, when the relay chain module adopts a sharding architecture, it allocates nodes in the network to different shards. Each shard can process transactions in parallel, which can reduce the load of individual nodes and improve the efficiency of the entire network. The number of shards can be set according to the size of the network and the amount of transactions, for example, the number of shards can be dynamically adjusted according to 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, geographic location, and network connection quality.

[0089] Preferably, 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 can monitor the transaction load of each shard in real-time and automatically redistribute transactions to less loaded shards when needed.

[0090] Further, a dynamic adjustment mechanism can be set up to adjust the size and number of shards based on real-time performance data of the network. These mechanisms can serve as complementary solutions 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 chains to register and deploy transaction verification rules on the relay chain.

[0092] It should be noted that the present embodiment relates to a system in which the smart contract module allows the business chains to register and deploy transaction verification rules on the relay chain. Here, the smart contract module refers to the component in the system responsible for managing and executing smart contracts, while the business chain refers to the various blockchain networks participating in cross-chain transactions. Registration refers to the process of identity confirmation and information registration of the business chain on the relay chain, so as to be able to deploy specific transaction verification rules on the relay chain.

[0093] Specifically, the smart contract module enables the business chain 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 of its chain, such as the chain identifier, consensus mechanism, transaction verification rules, etc. These information will be verified by the relay chain and stored, so that subsequent cross-chain transactions can refer to these rules for verification. Deploying transaction verification rules involves writing smart contract code that contains the transaction verification logic specific to the business chain, and then uploading it to the relay chain.

[0094] Preferably, the smart contract module can provide a set of graphical user interface, so that the administrator of the business chain can more easily perform registration and deployment operations. In addition, some security measures such as code audit and formal verification of smart contracts can be implemented to ensure the security and correctness of the 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 complementary solutions 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 the shard to optimize resource allocation.

[0096] It is important to note that this embodiment describes a system where 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 based on network conditions. Dynamic adjustment means that the system can automatically change the configuration of nodes based on real-time data and pre-set strategies to adapt to different network demands and improve efficiency.

[0097] Specifically, the node detection and scheduling module monitors the performance of nodes in each shard in real time, including processing speed, transaction throughput, online status, and other key indicators. Based on these indicators, the module assesses the load of each shard and decides whether to increase or decrease the number of nodes. For example, if the transaction volume of a certain shard suddenly increases, the module may automatically add new nodes to the shard to share the load and improve processing capacity. Conversely, if the load of a certain shard is low, the module may redistribute nodes to shards that need 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] Further, a feedback mechanism can be set up to adjust the parameters of the prediction model based on actual network performance and user feedback to improve the accuracy of the prediction. These advanced features can be used as a supplement to the node detection and scheduling module to ensure that the system can more intelligently and efficiently manage resources.

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

[0101] It is important to note that this embodiment relates to a system where the inter-shard state synchronization module ensures that the newly added node is consistent with the state of other nodes within the shard. Here, the inter-shard state synchronization module refers to the component in the system responsible for synchronizing the latest ledger data of the new node with 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 that of other nodes in the shard, so that all nodes in the network can operate based on the same data.

[0102] Specifically, the inter-shard state synchronization module synchronizes the latest ledger data from other nodes in the shard when a new node joins the shard. During this process, the new node receives the records of all historical transactions in the shard and updates its own ledger until it is consistent with the ledger of other nodes in the shard. To verify whether the synchronized data is correct, the new node constructs its own Merkle tree and compares it with the Merkle tree root hash value of other nodes in the shard.

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

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

[0105] The above-mentioned various embodiments of the present application have the following beneficial effects: The cross-chain architecture-oriented flexible consensus verification and node resource scheduling method provided by the present application can significantly improve the efficiency and reliability of cross-chain transactions. By adopting smart contracts and BFT consensus mechanisms, this method can ensure the legality and effectiveness of transactions between different blockchain systems while maintaining state consistency. This method can solve the compatibility problem of heterogeneous blockchains in cross-chain operations, enabling different types of blockchains to efficiently interconnect and support flexible interaction between multiple blockchains.

[0106] In addition, the relay chain shard node resource scheduling mechanism introduced by the present application 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. This method can also 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 state of each node, and enhance the stability and security of the entire cross-chain system.

[0107] Further, the storage medium of the embodiments of the present application stores program instructions capable of implementing all the above methods, wherein the program instructions can be stored in the above-mentioned storage medium in the form of a software product, including a number of instructions to make a computer device (which can be a personal computer, server, or network device, etc.) or processor execute all or part of the steps of the methods described in the embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk, etc. Various media that can store program codes, or computer, server, mobile phone, tablet terminal device.

[0108] The above description is merely exemplary of some embodiments of the application and of the technology principle of the application. It is understood that the scope of the application is not limited to the specific combinations of technical features described above, and should also cover other technical solutions formed by any combination of the above technical features or equivalent features thereof without departing from the above inventive concept. For example, the above technical features can be replaced with technical features with similar functions disclosed in the embodiments of the application (but not limited to) to form technical solutions.

Claims

1. A node resource scheduling method for cross-chain architecture, characterized in that, Includes the following steps: Step R1: During relay chain initialization, initial shards are divided according to the configuration file; Step R2: The gateway sends the transaction to the corresponding shard based on the transaction type field in the transaction information; Step R3: After receiving the cross-chain transaction, the nodes within the shard complete the consensus and store the transaction; Step R4: If the nodes within a 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 integrity value of nodes and adjusts the nodes based on the integrity value; Step R6: If the number of shard nodes is less than the specified number, add new nodes to the shard using 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 to verify state consistency.

2. The method according to claim 1, characterized in that, The inter-shard state synchronization mechanism includes constructing a Merkle tree of the latest state of the current shard. After newly added nodes synchronize ledger data, the Merkle tree is reconstructed and the root hash value is compared to verify state consistency.

3. A computer-readable storage medium having a computer program stored thereon configured to perform the method of any one of claims 1 to 2.

Images