A cross-chain sharding scheduling method based on DAG

Abstract

The present invention discloses a cross-chain shard scheduling method based on DAG, which belongs to the technical field of cross-chain shard scheduling; including: constructing a transaction dependency graph DAG model; adopting an out-degree-based node selection algorithm to select nodes with high priority from nodes without preorder in a directed graph for scheduling; adopting a FAST-MCTS algorithm to allocate transactions to the best shard, minimizing the number and delay of cross-shard communications; adopting an ODS-BFS scheduling algorithm to traverse the dynamic DAG, giving priority to processing nodes with higher out-degree. The present invention models cross-chain transactions through a dynamic DAG graph, captures the dependencies between different transactions, ensures that transactions are executed in the order of dependencies, and avoids the probability of rollback in the process of cross-chain transactions; by scheduling transactions with dependencies to the same shard, the conflict of cross-shard transactions is reduced, the number of shards of different sizes is adapted, and a low cross-shard ratio and a high throughput are maintained.

Description

Technical Field

[0001] The present invention belongs to the technical field of cross-chain shard scheduling, and specifically relates to a cross-chain shard scheduling method based on DAG. Background Art

[0002] With the rapid development of information technology, blockchain technology, as a decentralized distributed ledger technology, has shown great application potential in many fields such as finance, Internet of Things, and healthcare. However, due to the significant differences between different blockchain platforms in terms of system architecture, consensus mechanism, smart contract language, and application scenarios, relatively independent data and asset islands have been formed between each blockchain, which seriously limits the widespread application and coordinated development of blockchain technology. Cross-chain technology came into being, which is committed to breaking down the barriers between blockchains, realizing information interaction, asset transfer, and business collaboration between different blockchains, thereby improving the interoperability and scalability of blockchains. The development of cross-chain technology is of vital importance to building a more open, interconnected, and efficient blockchain ecosystem.

[0003] Transaction parallelization has been widely discussed in recent blockchain research and can significantly improve the scalability of blockchain systems. Sharding technology, in particular, is widely used in blockchain systems as an effective scalability solution. By dividing the blockchain network into multiple shards, each shard can independently process part of the transaction and state information, thereby improving the overall throughput and processing power of the system.

[0004] Introducing sharding technology in a cross-chain system not only helps improve the processing efficiency of cross-chain transactions, but also alleviates the performance bottleneck of the system. However, sharding technology in a cross-chain system also faces many challenges. Since cross-chain transactions involve interactions and coordination between multiple blockchains, there are complex dependencies between transactions. These dependencies need to be properly handled during the sharding process to ensure the correctness and consistency of cross-chain transactions. In addition, the dynamic cross-chain transaction environment requires sharding technology to be able to adapt to changes in transactions in real time and efficiently schedule transactions to appropriate shards for processing. In a cross-chain system, how to efficiently process a large number of cross-chain transactions is a key issue. With the continuous expansion of blockchain applications, the number and complexity of cross-chain transactions are increasing rapidly, and traditional transaction processing methods have been unable to meet the performance requirements of the system.

[0005] The Chinese patent discloses (application number: 202410988820X) a sharded blockchain transaction allocation method based on the WPR graph algorithm, including: creating transaction information for users and performing signature confirmation, the transaction information includes relevant transaction data, shard queue load information and macro timeliness parameters; after receiving the transaction, the verification node performs a legality check to confirm that the transaction does not have problems such as invalid signature, insufficient balance or double spending; after the transaction is verified, the node will obtain the predecessor transaction information and macro timeliness parameters for subsequent shard allocation; the system uses the WPR graph algorithm to calculate the shard matching degree of the transaction, and by analyzing the reference information of the predecessor transaction and its adjacent nodes, combined with the timeliness parameters, the fitness of the transaction in each shard is obtained; according to the matching degree and the load of each shard, the system sorts the shards and selects the best shard for transaction allocation; the transaction is sent to the target shard, verified and recorded, and the status information of this allocation is fed back to the blockchain system to ensure real-time update of the system.

[0006] The Chinese patent discloses (application number: 2023109758004) a transaction execution method, device and storage medium based on a DAG blockchain system, including: extracting each transaction from a transaction pool and generating a transaction dependency graph for representing the dependency relationship between each transaction; eliminating the cyclic dependency relationship in the transaction dependency graph to obtain an acyclic dependency graph and a dependency table; eliminating the dependency relationship in the acyclic dependency graph, and generating a secure transaction sequence with the goal of maximizing the interval between transactions with dependencies in the dependency table; based on the secure transaction sequence and the dependency table, executing transactions not in the dependency table in parallel, and executing transactions in the dependency table according to the dependency relationship.

[0007] In summary, how to solve the problem of estimating the maximum distance of human intrusion detection by the intrusion detection boundary model, thereby improving the accuracy of the intrusion detection boundary model, is a technical problem that the present invention aims to solve.

[0008] A patent for a sharded blockchain transaction allocation method based on the WPR graph algorithm has the following deficiencies:

[0009] 1. Failure to fully consider the complex dependencies between multiple cross-chain transactions may lead to complex interdependencies between multiple transactions, which may cause transaction delays, blockages, or cross-chain transaction conflicts, affecting the overall performance and throughput of the system;

[0010] 2. The transaction load in the blockchain network changes dynamically, and some shards may bear different transaction pressures at different times. The lack of a dynamic load adjustment mechanism may cause some shards to be overloaded while other shards are relatively idle, affecting the overall parallelism of the system.

[0011] 3. The computational complexity is high, especially in large-scale sharded blockchain systems, which affects the efficiency of real-time transaction allocation.

[0012] The patent application for the transaction execution method, device and storage medium based on the DAG blockchain system has the following deficiencies:

[0013] 1. There are still some deficiencies in the global optimal transaction scheduling method, and it is difficult to guarantee the global optimal solution, especially in an environment with high dependency and complex dependencies, which may lead to the emergence of suboptimal solutions;

[0014] 2. In reality, blockchain transaction dependencies often change dynamically, especially in high-concurrency scenarios. The order and dependencies of transactions may change during execution. Static scheduling algorithms cannot adapt to such dynamic changes and may encounter bottlenecks when processing complex and dynamically changing dependencies.

[0015] 3. It is impossible to precisely control the order of parallel execution and the decoupling of dependencies.

[0016] To sum up, how to solve the problems of transaction blocking and cross-shard communication overhead in cross-chain transactions, optimize throughput, reduce the number of cross-shards, and thus improve the overall operating efficiency of the cross-chain system. Summary of the invention

[0017] The purpose of the present invention is to provide a DAG-based cross-chain sharding scheduling method to solve the problems raised in the above background technology.

[0018] The object of the present invention is achieved by: a cross-chain sharding scheduling method based on DAG, characterized in that the method comprises the following steps:

[0019] Step S1: Define the dependencies between cross-chain transactions and their internal sub-transactions, and build a transaction dependency graph DAG model;

[0020] Step S2: Use the out-degree-based node selection algorithm, set the priority queue, and select the nodes with high priority from the nodes without preceding order in the directed graph for scheduling;

[0021] Step S3: Use the FAST-MCTS algorithm to assign simulation nodes to the best shards to minimize the number and latency of cross-shard communications;

[0022] Step S4: Feedback the optimal scheduling queue generated by the FAST-MCTS algorithm to the dynamic DAG graph to perform scheduling operations, use the ODS-BFS scheduling algorithm to traverse the dynamic DAG, and give priority to processing nodes with higher out-degree.

[0023] Preferably, in step S1, the cross-chain transaction and its internal sub-transaction dependencies are defined, and a transaction dependency graph DAG model is constructed. The specific operations are:

[0024] Step S1-1: Determine the cross-chain transaction in the transaction defining the cross-chain system;

[0025] The cross-chain system includes a relay chain, which includes several business chains. The relay chain is used to connect and coordinate multiple business chains. The business chain is responsible for processing its internal transactions, smart contract execution and business logic, and collaborates with the relay chain through the cross-chain protocol to achieve information exchange with other business chains.

[0026] definition For registration matters, To record transactions, To confirm the transaction, For cross-chain transactions, in the cross-chain system transaction, complete the i-th cross-chain transaction across m chains , m+1 sub-transactions are required for verification on the relay chain. The verified transactions include registration transactions, record transactions, and confirmation transactions;

[0027] Step S1-2: Determine the dependencies between cross-chain transactions;

[0028] The dependencies include transaction internal sub-transaction dependency, registration transaction sequence dependency, cross-chain sub-transaction dependency, and confirmation transaction sequence dependency. The transaction internal sub-transaction dependency means that the registration transaction, record transaction, and confirmation transaction completed in a cross-chain transaction need to be executed in chronological order.

[0029] The order of registration transactions depends on the sequential order of registration transactions on the relay chain. The order of cross-chain transactions depends on the transaction information of the business chain being recorded and confirmed on the relay chain before the business chain can execute the next transfer-in or transfer-out transaction. The order of confirmation transactions depends on the confirmation transaction on the relay chain, which needs to detect that all cross-chain transactions have been completed before continuing to confirm the next cross-chain transaction.

[0030] Step S1-3: Dynamically construct a cross-chain transaction dependency graph based on the dependency relationship to form a DAG graph.

[0031] Preferably, in step S1-3, a cross-chain transaction dependency graph is dynamically constructed according to the dependency relationship to form a DAG graph, and the specific operations are as follows:

[0032] Defining a directed graph Represents the DAG task model, where is a node set, is the edge set; each node Represents a transaction in DAG, each directed edge Specify an execution order, nodes Only in the previous node After completion, define Represents the pre-order node set, which is all directly pointed nodes The preceding node of , ensuring that all preceding nodes complete scheduling and execution:

[0033] ;

[0034] ;

[0035] ;

[0036] in, Indicates the time when the system executes to the previous node; Represents the previous node The execution time, Represents the end of the previous node of the system execution time, Representation Node Execution time; End node for system execution the time taken;

[0037] According to cross-shard communication, in cross-shard transactions, it is necessary to ensure that the data and status between multiple shards are consistent. Each shard , calculate the node Dispatch to Incremental cross-shard transactions for shards :

[0038] ;

[0039] in, Represents the previous node The fragments, Representation Node The dispatched fragments, Represents the previous node and Not in the same shard, Representation Node During cross-shard communication The node immediately following the previous node implement.

[0040] Preferably, in step S2, a node selection algorithm based on out-degree is adopted, a priority queue is set, and nodes with high priority are selected from the nodes without preceding order in the directed graph for scheduling. The specific operations are as follows:

[0041] Define the heuristic evaluation function , expressed as follows:

[0042] ;

[0043] in, is the weight coefficient 1, is the weight coefficient 2, The estimated execution time for the node, The out-degree is the number of directed edges from the node. The larger the out-degree is, the more transactions the node will be associated with, and the higher its importance in scheduling.

[0044] Whenever a new node is added to the DAG graph, the degree, execution time, and dependency complexity are calculated immediately, its priority is calculated using a heuristic evaluation function, and then the node and its priority information are inserted into the priority queue.

[0045] Preferably, in step S3, the FAST-MCTS algorithm is used to allocate the simulated nodes to the best shards. The FAST-MCTS algorithm allocates the simulated nodes to the best shards in four stages: the four stages include a selection stage, an expansion stage, a simulation stage, and a back propagation stage. The specific operations are:

[0046] Selection phase: The currently selected node is used as the root simulation node, and the load of each shard at that time is recorded. Starting from the root simulation node, which represents the initial state, all tasks are not assigned to any shard, the search is gradually deepened until an unexpanded simulation node or a leaf simulation node is reached;

[0047] Calculate the UCT value, select the child simulation node with the highest value, and repeat the process until you reach a simulation node that is not fully expanded or a leaf simulation node. The UCT expression is as follows:

[0048] ;

[0049] in, Is the MCTS sub-simulation node The cumulative reward value, is the number of visits to the MCTS parent node, Is the MCTS sub-simulation node Number of visits; To select a simulated node with a known higher reward ; Balance exploration parameters for MCTS; To select simulation nodes with fewer visits .

[0050] Preferably, in the expansion stage, the expanded Monte Carlo tree is simplified into a binary tree to reduce the randomness of the action, and two sub-simulation nodes are expanded each time, which are respectively the simulation node of the shard with the smallest load when not crossing shards and a random MCTS virtual shard;

[0051] Create a new MCTS simulation node based on the new state and add it to the collection of child simulation nodes of the current simulation node.

[0052] Preferably, the two extended simulation nodes in the simulation stage perform simulated transaction allocation, randomly select a shard with a smaller load to allocate the simulation, and the extended child simulation node updates the simulated transaction execution time and the simulated cross-shard communication time in the simulated shard according to the simulated shard situation of its own simulation, and the simulated maximum system time is used as the reward value, and the time is used as a negative value:

[0053] ;

[0054] in, Indicates the execution time of the parent simulation node, Represents a simulation node The average time to execute a transaction, For simulation nodes The fragments, is the cross-shard communication time, Incremental cross-shard transactions when scheduling simulated nodes to shards.

[0055] Preferably, the back propagation stage back propagates the simulation results to all passed nodes, traces back layer by layer, and updates the number of visits and values ​​of the nodes along the way, specifically:

[0056] The number of visits to each simulated node Increase by 1. If the number of iterations M is not reached, return to the selection stage to continue execution. When the number of iterations ends, generate a scheduling strategy, traverse from the leaf simulation node to the root simulation node, flip the path, and find the best scheduling solution.

[0057] Compared with the prior art, the present invention has the following improvements and advantages:

[0058] 1. Model cross-chain transactions through dynamic DAG graphs to capture the dependencies between different transactions, ensure that transactions are executed in the order of dependencies, and avoid the probability of rollback during cross-chain transactions.

[0059] 2. Through the out-degree-based dynamic DAG scheduling algorithm, transactions with dense dependencies are prioritized, and nodes with larger out-degrees are scheduled first, ensuring that transactions that depend on more transactions can be executed earlier, reducing the system's blocking time, thereby reducing the delay problem caused by cross-shard communication and ensuring that cross-chain transactions can be quickly confirmed.

[0060] 3. By adjusting the Monte Carlo search tree algorithm, the Monte Carlo search tree algorithm; at the same time, by scheduling dependent transactions to the same shard as much as possible, the conflict of cross-shard transactions is reduced, and it can adapt to the number of shards of different sizes. Whether in an environment with a small number of shards or a large number of shards, it can maintain a low cross-shard ratio and a high throughput. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 Flow chart of the method of the present invention.

[0062] Figure 2 This is a schematic diagram of the cross-chain transaction of the present invention.

[0063] Figure 3 This is a schematic diagram of the dynamic formation of the cross-chain transaction dependency graph of the present invention.

[0064] Figure 4 It is a schematic diagram of time comparison before and after scheduling of the present invention.

[0065] Figure 5 Schematic diagram of the FO-MCTS algorithm of the present invention.

[0066] Figure 6 It is a schematic diagram of the FAST-MCTS algorithm of the present invention.

[0067] Figure 7 This is a comparison chart of the throughput effect of sending 2000 transactions in the present invention.

[0068] Figure 8 It is a comparison chart of the effect of the cross-shard communication ratio in sending 2000 transactions in the present invention.

[0069] Fig. 9 This is a comparison chart of the effects of various algorithms when dealing with scenes of different densities.

[0070] Fig.10 This is a comparison chart of the effects of each cross-chain transaction with 8 shards.

[0071] Fig.11 This is a comparison chart of the effects of each cross-chain transaction when the number of shards is 16.

[0072] Fig.12 This is a comparison chart of the effects of each cross-chain transaction with 32 shards.

[0073] Fig.13This is a comparison chart of the effects of each cross-chain transaction with 64 shards.

[0074] Fig.14 This is a comparison chart of the average delay time for processing each transaction. DETAILED DESCRIPTION

[0075] The present invention is further summarized below with reference to the accompanying drawings.

[0076] like Figure 1 As shown, a DAG-based cross-chain sharding scheduling method includes the following steps:

[0077] Step S1: Define the dependencies between cross-chain transactions and their internal sub-transactions, and build a transaction dependency graph DAG model;

[0078] Step S1-1: Determine the cross-chain transaction in the transaction defining the cross-chain system;

[0079] The cross-chain system includes a relay chain, which includes several business chains. The relay chain is used to connect and coordinate multiple business chains. The business chain is responsible for processing its internal transactions, smart contract execution and business logic, and collaborates with the relay chain through the cross-chain protocol to achieve information exchange with other business chains.

[0080] definition For registration matters, To record transactions, To confirm the transaction, For cross-chain transactions, in the cross-chain system transaction, complete the i-th cross-chain transaction across m chains , m+1 sub-transactions are required for verification on the relay chain, and the verified transactions include registration transactions, record transactions, and confirmation transactions.

[0081] Step S1-2: Determine the dependencies between cross-chain transactions;

[0082] There is a strict order of transactions in cross-chain transactions, and the following dependencies exist:

[0083] The smart contract or specific protocol on the source chain is responsible for locking the user's assets to ensure that these assets will not be used again or tampered with before the cross-chain transaction is completed; the asset status of the source chain is locked on the relay chain to ensure the security and integrity of the assets during the cross-chain transaction process; cross-chain transactions are extremely time-sensitive, and transactions need to be executed strictly in sequence. The dependencies between transactions on the relay chain are determined by the following:

[0084] Internal transaction dependencies: The registration transaction, record transaction, and confirmation transaction completed in a cross-chain transaction need to be executed in chronological order.

[0085] Registration transaction order dependency: The order of registering transactions on the relay chain is sequential. The execution depends on the registration transaction Completion of transaction registration;

[0086] Dependence between cross-chain sub-transactions: In a cross-chain system, the transaction information of the previous business chain is recorded and confirmed on the relay chain before the business chain can execute the next transfer-in or transfer-out transaction;

[0087] Confirmation transaction order dependency: In cross-chain transactions, confirmation transactions ensure the atomicity of the entire transaction process. Either all steps are completed successfully, or all fail and roll back. Therefore, confirmation of transactions on the relay chain requires detection of the completion of all cross-chain transactions before the next cross-chain transaction can be confirmed.

[0088] Step S1-3: Dynamically construct a cross-chain transaction dependency graph based on the dependency relationship to form a DAG graph;

[0089] Specifically:

[0090] Defining a directed graph Represents the DAG task model, where is a node set, is the edge set; each node Represents a transaction in DAG, each directed edge Specify an execution order, nodes Only in the previous node After completion, define Represents the pre-order node set, which is all directly pointed nodes The preceding node of , ensuring that all preceding nodes complete scheduling and execution:

[0091] ;

[0092] ;

[0093] ;

[0094] in, Indicates the time when the system executes to the previous node; Represents the previous node The execution time, Represents the end of the previous node of the system execution time, Representation Node Execution time; End node for system execution the time taken;

[0095] According to cross-shard communication, in cross-shard transactions, it is necessary to ensure that the data and status between multiple shards are consistent. Each shard , calculate the node Dispatch to Incremental cross-shard transactions for shards :

[0096] ;

[0097] in, Represents the previous node The fragments, Representation Node The dispatched fragments, Represents the previous node and Not in the same shard, Representation Node During cross-shard communication The node immediately following the previous node implement.

[0098] like Figure 2 As shown in the figure, suppose a cross-chain system contains 1 relay chain and 3 business chains. Three cross-chain transactions are initiated in the cross-chain system, among which transaction 1 involves three chains, which are respectively as follows in chronological order:

[0099] Transaction 1: Chain 1 transfers to Chain 2, and Chain 2 transfers to Chain 3;

[0100] Transaction 2: Chain 2 transfers funds to chain 1;

[0101] Transaction 3: Chain 3 transfers funds to chain 2;

[0102] The three cross-chain transactions generated on the relay chain are recorded as , The chains are chained in chronological order, namely chain 1, chain 2, and chain 3. Chain 1: , chain 2: , chain 3: .

[0103] Due to the order of arrival of Chain 1, Chain 2, and Chain 3, some transactions of Chain 1 and Chain 2 arrive at the relay chain first and begin to build dependencies. According to the order of registration transaction dependency, the sub-transactions in Chain 1 are executed in the order of registration transaction, recording transaction, and confirmation transaction. At the same time, according to the dependency between cross-chain sub-transactions, the registration transactions of Chain 1 and Chain 2 build dependencies with each other. They are mutually dependent in sequence to form a DAG graph. The result is as follows Figure 3 As shown in (a).

[0104] like Figure 3 As shown in (b), according to the confirmation transaction order dependency, transaction 2 contains transfer-in and transfer-out operations on chain 1 and chain 2. This operation can only be performed after the operations involving these two chains in transaction 1 are completed. Therefore Depends on .

[0105] like Figure 3 As shown in (c), when After being put on the chain, the registration transaction The transfer operation of chain 3 is included, so Depends on ; In terms of transaction confirmation, according to cross-shard communication: In cross-shard transactions, it is necessary to ensure that the data and status between multiple shards are consistent; this means that cross-shard communication must solve the synchronization problem of different shards when processing the same transaction; Confirmed transaction 3 Depends on confirming transaction 2 Depends on confirming transaction 1 , based on this dependency relationship, a cross-chain transaction dependency graph is dynamically constructed, and the final DAG is formed.

[0106] like Figure 4 As shown in the figure, compared with the situation before scheduling, the dynamic DAG is reasonably scheduled according to the dependencies, and the transactions with dependencies are assigned to one shard, which reduces the number of cross-shard communications and the blocking time between cross-chain transactions, and can greatly improve the throughput of the system.

[0107] To solve the cross-chain shard transaction scheduling problem, the Fast Monte Carlo Tree Search algorithm based on out-degree priority (FO-MCTS) is adopted. The Fast Monte Carlo Tree Search algorithm optimizes the scheduling path by giving priority to nodes with higher out-degrees, combining random simulation and tree search methods, reducing cross-shard communication overhead and improving the overall throughput of the system.

[0108] The fast Monte Carlo tree search algorithm is divided into three major steps, such as Figure 5 As shown, it is divided into:

[0109] Adopt the node selection algorithm based on out-degree, set the priority queue, select the nodes with high priority from the nodes without preorder in the directed graph for scheduling, use the FAST-MCTS algorithm to allocate transactions to the best shard to minimize the number and delay of cross-shard communications, and feed back the optimal scheduling queue generated by the FAST-MCTS algorithm to the dynamic DAG graph to perform scheduling operations. Use the ODS-BFS scheduling algorithm to traverse the dynamic DAG and give priority to processing nodes with higher out-degree. The specific operations are as follows:

[0110] Step S2: Use the out-degree-based node selection algorithm, set the priority queue, and select high-priority nodes from the nodes without a preceding order in the directed graph for scheduling. The specific operations are as follows:

[0111] Define the heuristic evaluation function , expressed as follows:

[0112] ;

[0113] in, is the weight coefficient 1, is the weight coefficient, For Node Estimated execution time, The out-degree is the number of directed edges from the node. The larger the out-degree is, the more transactions the node will be associated with, and the higher its importance in scheduling.

[0114] Whenever a new node is added to the DAG graph, the degree, execution time, and dependency complexity are calculated immediately, its priority is calculated using a heuristic evaluation function, and then the node and its priority information are inserted into the priority queue.

[0115] Through this priority scheduling mechanism, the system can ensure that high-priority tasks are processed first. In the cross-chain transaction scheduling scenario, this means that urgent tasks with large out-degree, short execution time and relatively simple dependencies can be processed first, thereby effectively avoiding the problem of task allocation falling into the local optimality and improving the scheduling efficiency and performance of the entire cross-chain system.

[0116] like Figure 6 As shown, step S3: use the FAST-MCTS algorithm to assign transactions to the best shards to minimize the number and latency of cross-shard communications;

[0117] The FAST-MCTS algorithm divides the assignment of transactions to the best shard into four stages: the selection stage, the expansion stage, the simulation stage, and the back-propagation stage. The specific operations are as follows:

[0118] Selection phase: The currently selected node is used as the root simulation node, and the load of each shard at that time is recorded. Starting from the root simulation node, which represents the initial state, all tasks are not assigned to any shard, the search is gradually deepened until an unexpanded simulation node or a leaf simulation node is reached;

[0119] Calculate the UCT value, select the child simulation node with the highest value, and repeat the process until you reach a simulation node that is not fully expanded or a leaf simulation node. The UCT expression is as follows:

[0120] ;

[0121] in, Is the MCTS sub-simulation node The cumulative reward value, is the number of visits to the MCTS parent node, Is the MCTS sub-simulation node Number of visits; To select a simulated node with a known higher reward ; Balance exploration parameters for MCTS; To select simulation nodes with fewer visits .

[0122] When selecting nodes, the FAST-MCTS algorithm not only considers the average reward of the current node, but also considers the exploration potential of the node; Select nodes with higher known rewards to make full use of currently known information and maximize current benefits; Select nodes that are visited less frequently in order to explore unknown areas and discover potential high-yield paths; by balancing the two, the algorithm can avoid falling into local optimal solutions while ensuring that the global optimal solution can be found.

[0123] In the expansion phase, the expanded Monte Carlo tree is simplified into a binary tree to reduce the randomness of the action. Two sub-simulation nodes are expanded each time, which are the simulation nodes of the shard with the smallest load when not crossing shards and a random MCTS virtual shard.

[0124] Create a new MCTS simulation node based on the new state and add it to the collection of child simulation nodes of the current simulation node.

[0125] By expanding nodes, the FAST-MCTS algorithm can better evaluate the pros and cons of different allocation schemes and find the optimal solution to reduce cross-shard communication. When dynamically added tasks arrive, the existing expansion nodes provide rich status information, which helps to find the best allocation scheme more quickly. This method not only reduces the search space of the MCTS tree, so that it can search for the optimal scheduling strategy in a very small number of iterations, but also maintains a certain degree of randomness, which can increase the breadth of expansion exploration and avoid ignoring scheduling paths with higher benefits.

[0126] In the simulation phase, the two extended simulation nodes perform simulated transaction allocation and randomly select a shard with a smaller load to allocate the simulation. The extended child simulation node updates the simulated transaction execution time and simulated cross-shard communication time in the simulated shard according to its own simulated shard situation and the simulated scheduled shard. The maximum system time of the simulation is used as the reward value, and the time is used as a negative value:

[0127] ;

[0128] in, Indicates the execution time of the parent simulation node, Represents a simulation node The average time to execute a transaction, For simulation nodes The fragments, is the cross-shard communication time, Incremental cross-shard transactions when scheduling simulated nodes to shards.

[0129] In the back propagation phase, the simulation results are back propagated to all passed nodes, tracing back layer by layer, and updating the number of visits and values ​​of nodes along the way. Specifically:

[0130] The number of visits to each node Increase by 1. If the number of iterations M is not reached, return to the selection stage to continue execution. When the number of iterations ends, generate a scheduling strategy, traverse from the leaf node to the root node, flip the path, and find the best scheduling solution.

[0131] Step S4: Feedback the optimal scheduling queue generated by the FAST-MCTS algorithm to the dynamic DAG graph to perform scheduling operations, use the ODS-BFS scheduling algorithm to traverse the dynamic DAG, and give priority to processing nodes with higher out-degree.

[0132] In the cross-chain sharding system of blockchain, the ODS-BFS scheduling algorithm has significant advantages; it can significantly reduce the waiting time of transactions in each shard, thereby improving the parallel processing capability and throughput of the system; through real-time monitoring and dynamic adjustment of transaction dependencies, the system can efficiently cope with complex blockchain transaction scenarios, ensuring that it can still maintain efficient operation under high load and complex environments, thereby optimizing the overall performance of the cross-chain system. The ODS-BFS scheduling algorithm fully considers the out-degree characteristics of nodes in the blockchain and the dependencies of transactions, and avoids the blocking problem caused by excessive concentration of tasks by reasonably arranging the scheduling order of nodes, thereby improving the utilization rate of system resources and overall performance.

[0133] In order to verify the feasibility and effect of the present invention, multiple groups of simulation experiments are designed to evaluate the performance of the FO-MCTS scheme we proposed, focusing on the difference between the FO-MCTS scheme and the traditional scheme in cross-shard ratio and throughput, and the experimental results are given.

[0134] The performance indicators include the following aspects: 1. Relay chain throughput, 2. Cross-chain transaction confirmation performance, that is, the number of cross-chain transactions confirmed per second (TPS), 3. Cross-shard ratio and, 4. Cross-chain transaction delay time.

[0135] Experimental setup:

[0136] The relay chain behavior of FO-MCTS is simulated on a system with Intel Core i7-13620H CPU @ 2.40 GHz and 16GB RAM using Python 3.10.9 for its performance evaluation.

[0137] In order to be closer to the real scenario, the throughput of the underlying blockchain is selected as 20. In the simulation, the number of shards varies from 4 to 64. The sleep function is used to simulate the time of consensus rounds in all blockchains. In the selection phase of the FO-MCTS model, we set the equilibrium exploration parameter c to ,In our simulation, it is set to take 50ms on average to process a cross-chain transaction sub-transaction.

[0138] We compare FO-MCTS with state-of-the-art baselines, focusing on differences in throughput, cross-shard ratio, and transaction confirmation latency:

[0139] Pyramid: By randomly assigning transactions, it greatly reduces the delay in cross-shard transaction confirmation, reduces the overhead and delay caused by multiple rounds of consensus, and thus produces better throughput performance.

[0140] Silver: Centralizes dependent transactions such as registration, recording, and final transactions on the relay chain on the same shard, and schedules each group of transactions through integer optimization. Silver has been proven to effectively eliminate cross-shard transactions, thereby significantly improving the throughput of the relay chain and the overall performance of the system.

[0141] MCTS: In view of the high uncertainty in the cross-chain sharding environment, MCTS uses the methods of selection, expansion, simulation, and feedback to perform random sampling and evaluation to optimize the best scheduling decisions, reduce the number of cross-shard transactions and the delay caused by cross-chain transaction confirmation, and improve the overall performance of the entire cross-chain system.

[0142] FO-MCTS: Optimizes the traditional MCTS algorithm, reduces the search space for finding the best schedule, reduces the cross-shard ratio in the cross-chain environment, and adds a DAG scheduling strategy based on out-degree, further reducing the delay time of cross-chain transaction confirmation.

[0143] Relay chain performance comparison:

[0144] We simulated interdependent sub-transaction scenarios on the relay chain, with each set of experiments containing 2,000 transactions, to evaluate the performance of different algorithms in terms of throughput and cross-shard communication ratio as the number of shards on the relay chain changes. Specifically, we gradually increased the number of shards on the relay chain from 4 to 64 to observe the performance changes of the algorithms under different shard sizes.

[0145] like Figure 7 , 8 As shown, from Figure 7 As can be seen from the figure, as the number of shards increases, the throughput of the proposed FO-MCTS algorithm steadily increases, especially when the number of shards is large, it shows a significant advantage. This shows that the algorithm can still efficiently handle complex cross-chain transactions and maintain a high system throughput in a large-scale sharding environment. Figure 8 It can be seen that the cross-shard communication ratio of the FO-MCTS algorithm shows a slow growth trend as the number of shards increases. Even in the case of 64 shards, the cross-shard ratio can still be controlled at around 8%, which shows the strong advantage of the algorithm in scalability.

[0146] Compared with FO-MCTS, the traditional MCTS algorithm performs better in the case of small-scale sharding but performs poorly in the case of large-scale sharding. This is because in the case of large-scale sharding, the search space of MCTS's randomly selected shards is too large, which makes it difficult to find the best sharding decision for the transaction, resulting in an increase in the cross-sharding ratio and thus affecting the overall throughput of the relay chain. The FO-MCTS algorithm reduces the search range of the traditional MCTS algorithm by improving the extended node part of MCTS, and can search for the optimal scheduling strategy in a small amount of time and iterations.

[0147] Cross-chain system performance comparison:

[0148] Initiate a complete cross-chain transaction on the cross-chain system. Experimental results show that Fig. 9 It can be observed that when the number of shards is 16 and 32, the FO-MCTS algorithm can always maintain a high throughput regardless of the number of chains involved in the cross-chain system. This is mainly due to the fact that the algorithm can effectively handle the dependencies and scheduling order between transactions under different numbers of chains and shard configurations.

[0149] When the number of chains is small, since each group of cross-chain transactions on the relay chain contains fewer recorded transactions, the Silver algorithm context switches too frequently, resulting in low overall system throughput. However, through our simulation analysis, we found that as the number of chains increases, the interval time for cross-chain transactions to be processed on the relay chain gradually shortens, and the density of dependencies between transactions also decreases. When the number of system chains increases from 4 to 10, the average number of dependencies per transaction decreases by about 3. This shows that in complex and dynamically changing cross-chain transaction scheduling scenarios, the FO-MCTS algorithm shows stronger adaptability and higher throughput.

[0150] As the number of chains in the system continues to increase, the interval time between cross-chain transactions on the relay chain is shortened, but the density of transactions and dependencies is reduced. In our simulated environment, a transaction with 4 chains has an average of 3 more dependencies than a transaction with 10 chains. This shows that the FO-MCTS model has a higher throughput in a complex, dynamic, and time-sensitive cross-chain transaction sharding scheduling environment.

[0151] It is concluded that the throughput of the cross-chain system is closely related to the density of transactions and dependencies on the relay chain. To explore this issue in depth, we conducted experiments with different numbers of shards. Fig.10 , 11 As shown in Figures 12 and 13, when the ratio of transactions to dependencies gradually increases, various algorithms show significant differences in dealing with different density scenarios.

[0152] The traditional MCTS algorithm shows relatively stable performance under different dependency densities and can maintain a relatively stable throughput. However, the Sliver algorithm shows obvious disadvantages in high-density environments, mainly because high-density dependencies require frequent context switching, which greatly increases the frequency of cross-shard operations, resulting in a significant increase in the cross-shard ratio, which in turn affects the overall performance.

[0153] In contrast, the FO-MCTS model shows strong adaptability and robustness when handling cross-chain transactions. Experimental results show that no matter how the number of shards increases, the cross-shard ratio of the FO-MCTS model remains at a low level, and the growth of this ratio tends to be flat as the density of transactions and dependencies increases. Even in scenarios with higher density, the model can still effectively control the number of cross-shards and maintain the efficiency of the system.

[0154] This phenomenon shows that MCTS-type algorithms are not easily affected by changes in density when facing changes in transaction and dependency density, and can maintain stable performance in different scenarios. The FO-MCTS model further optimizes this advantage. When dealing with complex and changing cross-chain transactions, it always maintains a low cross-shard ratio through its excellent scheduling strategy, achieving higher system parallelism and throughput. In summary, the FO-MCTS model shows extremely high robustness and scalability when dealing with environments with different dependency densities. Whether in cross-chain transaction scenarios with sparse or dense dependencies, the model can provide stable performance and a low cross-shard communication ratio, giving it a significant advantage in the dynamic and changing cross-chain transaction sharding environment.

[0155] Comparison of cross-chain transaction confirmation delay:

[0156] Record the confirmation delay waiting time of cross-chain transactions from entering the shard to confirmation completion. The average confirmation delay time of each transaction is as follows: Fig.14 As shown in , with the increase in the number of shards, the average confirmation delay time of each cross-chain transaction decreases significantly, and FO-MCTS performs well in reducing transaction delay waiting time. Specifically, the FO-MCTS algorithm reduces the delay time of cross-chain transactions and increases the priority of urgent transactions by introducing an out-degree priority scheduling mechanism.

[0157] In contrast, the traditional MCTS algorithm performs relatively close when the number of shards is small, but as the number of shards increases, the advantages of FO-MCTS gradually emerge, reflecting its better scalability. The Sliver algorithm can handle cross-chain transactions to a certain extent, but does not consider the time delay caused by the blockage of transaction interdependence in a large-scale sharding environment, indicating that its performance is slightly insufficient in a complex dependency environment. The Pyramid algorithm shows relatively stable delay time in different sharding environments, and the overall delay is relatively high.

[0158] The FO-MCTS algorithm can significantly reduce the confirmation delay of cross-chain transactions in sharding environments of different sizes. Especially when the number of shards reaches 64, the average confirmation delay time for FO-MCTS to process each transaction is reduced to about 2 milliseconds, demonstrating its superior performance in high-concurrency cross-chain systems.

[0159] The above description is only an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent substitution, improvement, etc. made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.

Claims

1. A cross-chain sharding scheduling method based on DAG, characterized by: The method comprises the following steps: Step S1: Define the dependencies between cross-chain transactions and their internal sub-transactions, and build a transaction dependency graph DAG model; Step S1-1: Determine the cross-chain transaction in the transaction defining the cross-chain system; The cross-chain system includes a relay chain, which includes several business chains. The relay chain is used to connect and coordinate multiple business chains. The business chain is responsible for processing its internal transactions, smart contract execution and business logic, and collaborates with the relay chain through the cross-chain protocol to achieve information exchange with other business chains. definition For registration matters, To record transactions, To confirm the transaction, For cross-chain transactions, in the cross-chain system transaction, complete the i-th cross-chain transaction across m chains , m+1 sub-transactions are required for verification on the relay chain. The verified transactions include registration transactions, record transactions, and confirmation transactions; Step S1-2: Determine the dependencies between cross-chain transactions; The dependencies include transaction internal sub-transaction dependency, registration transaction sequence dependency, cross-chain sub-transaction dependency, and confirmation transaction sequence dependency. The transaction internal sub-transaction dependency means that the registration transaction, record transaction, and confirmation transaction completed in a cross-chain transaction need to be executed in chronological order. The order of registration transactions depends on the sequential order of registration transactions on the relay chain. The order of cross-chain transactions depends on the transaction information of the business chain being recorded and confirmed on the relay chain before the business chain can execute the next transfer-in or transfer-out transaction. The order of confirmation transactions depends on the confirmation transaction on the relay chain, which needs to detect that all cross-chain transactions have been completed before continuing to confirm the next cross-chain transaction. Step S1-3: Dynamically construct a cross-chain transaction dependency graph based on the dependency relationship to form a DAG graph. The specific operations are as follows: Defining a directed graph Represents the DAG task model, where is a node set, is the edge set; each node Represents a transaction in DAG, each directed edge Specify an execution order, nodes Only in the previous node After completion, define Represents the pre-order node set, which is all directly pointed nodes The preceding node of , ensuring that all preceding nodes complete scheduling and execution: ； ； ； in, Indicates the time when the system executes to the previous node; Represents the previous node The execution time, Represents the end of the previous node of the system execution time, Representation Node Execution time; End node for system execution the time taken; According to cross-shard communication, in cross-shard transactions, it is necessary to ensure that the data and status between multiple shards are consistent. Each shard , calculate the node Dispatch to Incremental cross-shard transactions for shards : ； in, Represents the previous node The fragments, Representation Node The dispatched fragments, Represents the previous node and Not in the same shard, Representation Node During cross-shard communication The node immediately following the previous node implement; Step S2: Use the out-degree-based node selection algorithm, set the priority queue, and select the nodes with high priority from the nodes without preceding order in the directed graph for scheduling; The specific operations are: Define the heuristic evaluation function , expressed as follows: ； in, is the weight coefficient 1, is the weight coefficient, For Node Estimated execution time, The out-degree is the number of directed edges from the node. The larger the out-degree is, the more transactions the node will be associated with, and the higher its importance in scheduling. Whenever a new node is added to the DAG graph, the degree, execution time, and dependency complexity are calculated immediately, its priority is calculated using the heuristic evaluation function, and then the node and its priority information are inserted into the priority queue; Step S3: Use the FAST-MCTS algorithm to assign simulation nodes to the best shards to minimize the number and latency of cross-shard communications; The FAST-MCTS algorithm divides the allocation of simulated nodes to the best shards into four stages: the four stages include the selection stage, the expansion stage, the simulation stage, and the back-propagation stage. The specific operations are: Selection phase: The currently selected node is used as the root simulation node, and the load of each shard at that time is recorded. Starting from the root simulation node, which represents the initial state, all tasks are not assigned to any shard, the search is gradually deepened until an unexpanded simulation node or a leaf simulation node is reached; Calculate the UCT value, select the child simulation node with the highest value, and repeat the process until you reach a simulation node that is not fully expanded or a leaf simulation node. The UCT expression is as follows: ； in, Is the MCTS sub-simulation node The cumulative reward value, is the number of visits to the MCTS parent node, Is the MCTS sub-simulation node Number of visits; To select a simulated node with a known higher reward ; Balance exploration parameters for MCTS; To select simulation nodes with fewer visits ; In the simulation phase, the two extended simulation nodes perform simulated transaction allocation, randomly select a shard with a smaller load to allocate the simulation, and the extended child simulation node updates the simulated transaction execution time and the simulated cross-shard communication time in the simulated shard according to its own simulated shard situation and the simulated scheduled shard, and takes the simulated system maximum time as the reward value, and takes the time as a negative value: ； in, Indicates the execution time of the parent simulation node, Represents a simulation node The average time to execute a transaction, For simulation nodes The fragments, is the cross-shard communication time, Incremental cross-shard transactions when scheduling simulated nodes to shards; Step S4: Feedback the optimal scheduling queue generated by the FAST-MCTS algorithm to the dynamic DAG graph to perform scheduling operations, use the ODS-BFS scheduling algorithm to traverse the dynamic DAG, and give priority to processing nodes with higher out-degree.

2. According to claim 1, a DAG-based cross-chain sharding scheduling method is characterized by: In the expansion phase, the expanded Monte Carlo tree is simplified into a binary tree to reduce the randomness of the action, and two sub-simulation nodes are expanded each time, which are the simulation nodes of the shard with the smallest load when not crossing shards and a random MCTS virtual shard; Create a new MCTS simulation node based on the new state and add it to the collection of child simulation nodes of the current simulation node.

3. According to a DAG-based cross-chain sharding scheduling method according to claim 1, it is characterized by: The back propagation stage back propagates the simulation results to all passed nodes, traces back layer by layer, and updates the number of visits and values ​​of the nodes along the way, specifically: The number of visits to each simulated node Increase by 1. If the number of iterations M is not reached, return to the selection stage to continue execution. When the number of iterations ends, generate a scheduling strategy, traverse from the leaf simulation node to the root simulation node, flip the path, and find the best scheduling solution.

Images