Block chain multi-level fragment load balancing method and system based on predictive subgraph

Abstract

The invention discloses a block chain multi-level fragmentation load balancing method and system based on a predictive subgraph, and aims to solve the problems of load imbalance and frequent cross-fragmentation transaction in the existing block chain fragmentation technology. According to the scheme, a transaction relation graph is constructed in a block chain system; performing sub-graph division on the constructed transaction relation graph in each sub-graph division period; the target of division is to obtain N sub-graphs, so that the sum of edge weights of each sub-graph is maximized, and meanwhile, the number of nodes in the sub-graphs meets a preset threshold value. And executing a fragmentation division process aiming at the divided sub-graphs, and carrying out hierarchical management by adopting a multi-stage fragmentation strategy. A sub-graph attribution prediction process is executed before a sub-graph division cycle is started; and a time sequence prediction method is adopted to predict the affiliation of the subgraph to which the node belongs, and sampling correction is carried out on the edge based on a prediction result.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain multi-level sharding load balancing method and system based on a prediction subgraph. Background Art

[0002] Blockchain, an innovative distributed ledger technology, has seen widespread application and in-depth development in recent years across numerous fields, including finance, supply chain, healthcare, and government affairs. Its core decentralized nature breaks the reliance of traditional centralized systems on a single trusted center. By leveraging distributed nodes to jointly maintain the ledger, it ensures secure data storage and reliable transmission. In the financial sector, blockchain technology offers new solutions for cross-border payments. Traditional cross-border payment processes are cumbersome, involving multiple intermediaries, resulting in long processing times and high fees. Blockchain-based cross-border payment systems, on the other hand, enable direct, point-to-point transactions between transacting parties, eliminating intermediaries and reducing transaction costs. While significantly shortening transaction confirmation times and improving capital flow efficiency, blockchain can also provide an immutable record of product information throughout the entire process, from raw material procurement, production and processing, warehousing and logistics, to point of sale. By scanning a product's QR code, consumers can access detailed information, including the source of the raw materials, production batch, and shipping history. This enhances supply chain transparency and credibility, effectively addressing information asymmetry. However, with the continuous expansion of blockchain network scale and the continuous growth of transaction volume, blockchain systems face many challenges, among which sharding technology has become a key research direction to improve blockchain performance and scalability.

[0003] Traditional blockchain systems, such as Bitcoin and Ethereum, face significant performance bottlenecks when processing large-scale transactions. Bitcoin, a prime example of blockchain technology, was originally designed to create a decentralized digital currency. However, in practice, it can only process approximately seven transactions per second, far from meeting the demands of high-frequency, intensive transactions in industries like finance. While Ethereum's performance has improved compared to Bitcoin, its ability to process dozens of transactions per second remains insufficient for large-scale commercial transactions. This is primarily due to their consensus mechanisms and single-chain architecture. For example, Bitcoin's Proof-of-Work (PoW) consensus mechanism requires nodes across the network to compete for the right to record transactions. This process consumes significant computing resources and time, resulting in slow transaction processing. Furthermore, the single-chain architecture requires all nodes to process and verify every transaction. As the number of transactions increases, the burden on nodes increases, resulting in poor scalability.

[0004] However, existing sharding technologies still face several pressing challenges in practical applications. The sharding process often fails to fully consider the complex transaction relationships between nodes and load balancing. Some shards may experience excessive load and severe transaction congestion due to concentrated nodes and frequent transactions. Other shards may experience idle resources due to fewer nodes and sparse transactions, significantly impacting overall system performance. Furthermore, cross-shard transaction processing is complex. Issues such as data synchronization and differing transaction verification rules between shards can easily lead to data inconsistencies and transaction conflicts, further reducing system efficiency. Furthermore, the increasing diversity of blockchain application scenarios is placing higher demands on the performance and scalability of blockchain systems. For example, large-scale commercial applications require processing massive amounts of transaction data and demanding rapid transaction confirmation and processing. Existing sharding technologies struggle to meet the demands of these complex scenarios. Therefore, researching a more efficient and effective load balancing approach for blockchain shards is of great practical significance.

[0005] In related technical research, some scholars and researchers have proposed various improved sharding strategies. For example, some approaches improve sharding efficiency by optimizing consensus algorithms, adopting more efficient consensus mechanisms to reduce consensus time between nodes, thereby accelerating transaction confirmation. However, these approaches fail to address the rationality of sharding and load balancing, potentially leading to further disparity in load between shards. Other approaches use sharding based on geography or node attributes, assigning nodes with similar locations or attributes to the same shard. However, this approach may not accurately reflect the actual transaction relationships and load conditions between nodes. For example, geographically close nodes do not necessarily have frequent business transactions, and assigning them to the same shard may not fully utilize the benefits of sharding.

[0006] In summary, the current blockchain sharding technology still has certain limitations in load balancing (nodes are randomly assigned when joining the blockchain system, and frequent cross-shard transactions lead to load imbalance) and cross-shard transaction processing. A new method is urgently needed to optimize the sharding strategy and improve the performance and scalability of the blockchain system. Summary of the Invention

[0007] In view of this, the present invention provides a blockchain multi-level sharding load balancing method and system based on prediction subgraph to solve the problems of load imbalance and frequent cross-shard transactions in existing blockchain sharding technology.

[0008] To achieve the above object, the technical solution of the present invention includes the following steps:

[0009] Step 1: Build a transaction relationship graph in the blockchain system.

[0010] Step 2: Sub-graph the constructed transaction relationship graph within each sub-graph division cycle; the division goal is to obtain N sub-graphs so that the sum of the edge weights of each sub-graph is maximized, and the number of nodes in the sub-graph meets the pre-set threshold.

[0011] Step 3: Execute the sharding process for the divided subgraphs, and adopt a multi-level sharding strategy for hierarchical management.

[0012] Step 4: Execute the prediction subgraph affiliation process before the next subgraph partitioning cycle begins; use the time series prediction method to predict the subgraph affiliation of the node, and perform sampling correction on the edge based on the prediction results.

[0013] The next subgraph partitioning cycle begins, and the process returns to step 2.

[0014] Furthermore, a transaction relationship diagram is constructed in the blockchain system, specifically:

[0015] When the blockchain system starts, each node newly added to the graph is assigned a unique identifier ID and its edge weights with other nodes are initialized to zero.

[0016] At the same time, the system records each node's transaction history, including counterparty, transaction amount, and timestamp. Whenever a transaction occurs between two nodes, the system automatically records the transaction information and checks whether an existing edge exists. If an edge already exists, the edge's weight is increased; otherwise, a new edge is created and its weight is initialized to 1. The counterparty's information is also added to the node's transaction history for subsequent subgraph attribution prediction and edge correction. Each node maintains its own transaction history table, which only records counterparty information.

[0017] Furthermore, the constructed transaction relationship graph is divided into subgraphs in each subgraph division cycle. The specific division process is as follows:

[0018] First, the node with the largest edge weight in the graph is selected as the seed node and added to a new subgraph.

[0019] Then, we continue to search for nodes with the largest weight of edges connecting to nodes in the subgraph and that have not been partitioned, and add them to the subgraph until the number of nodes in the subgraph reaches the threshold or there are no nodes that meet the conditions.

[0020] Repeat the above process until N subgraphs are divided.

[0021] Furthermore, the sharding process is performed on the divided subgraphs, and a multi-level sharding strategy is adopted for hierarchical management:

[0022] Multi-level sharding includes two levels: basic shard i and upper management shard b. The specific definitions are as follows:

[0023] i-shard is specifically: the basic sharding layer of the blockchain network, which directly carries the daily transaction processing tasks of the nodes.

[0024] Specifically, the b-shard aggregates the active nodes of the i-shard with high-frequency interactions to form a cross-i-shard coordination management unit. The b-shard does not directly process terminal transactions, but is responsible for the pre-processing and hierarchical coordination of cross-i-shard transactions, optimizing the processing efficiency of cross-shard transactions through a hierarchical recursive mechanism.

[0025] Furthermore, i-shards are divided in the following way: according to the subgraphs divided in step 2, the blockchain network is divided into i-shards for the first time; each subgraph corresponds to an i-shard.

[0026] Furthermore, the b-shard is divided in the following way: the subgraphs are regarded as new nodes, and clustered according to the transaction frequency between the subgraphs to obtain multiple categories. For each category, k nodes are taken from the subgraphs it contains according to the edge weights to form the b-shard.

[0027] The transaction frequency between subgraphs is the sum of the weights of the edges connecting the subgraphs.

[0028] If the number of i shards is n, the value of k is selected as

[0029] Furthermore, in step 4, a multi-feature time series prediction model is used to dynamically predict the subgraph to which the node belongs, as follows:

[0030] S401: Collect the historical transaction data of the nodes recorded in step 1 and construct a node-level time series feature set, which includes a time series sample of each node.

[0031] The time series sample of each node contains basic transaction features, relationship features, and environmental features: basic transaction features include the number of transactions per hour, the average amount of a single transaction, and the transaction time distribution; relationship features are the time series of edge weights with other nodes; and environmental features are the load indicators of the i-shard.

[0032] Discretize the above features by time window to form a multidimensional time series input matrix X∈R T×D

[0033] S402: Use the CATS model to predict the subgraph to which the node belongs.

[0034] S403: Based on the prediction results, dynamically adjust the subgraph affiliation of the node. The specific process is as follows:

[0035] Set the confidence threshold according to the system characteristics. If a node belongs to subgraph S j The probability P j If it is greater than the threshold, it is marked as S j Otherwise, the nodes are assigned to the nearest subgraph according to the probability distribution through fuzzy clustering.

[0036] In the next subgraph partitioning cycle, only the edge weights of the nodes whose predicted ownership changes are adjusted. The adjustment method is: for the nodes from subgraph S a Transfer to S b Node u; node u and S a The edge weight of the middle node decays to w ua ×(1-α×(1-p a )); nodes u and S b The edge weight of the middle node is enhanced to w ub ×(1+β×p b ).

[0037] where w ua For this node and subgraph S a The edge weight of the middle node, α is the attenuation coefficient, p a The node belongs to S a The probability w ub For this node and subgraph S b The edge weight of the middle node, β is the enhancement coefficient, p b The node belongs to S b probability.

[0038] Another embodiment of the present invention further provides a blockchain multi-level sharding load balancing system based on a prediction subgraph, comprising the following modules:

[0039] Graph construction module, used to build transaction relationship graphs in blockchain systems.

[0040] The subgraph partitioning module is used to partition the constructed transaction relationship graph into subgraphs within each subgraph partitioning cycle. The partitioning goal is to obtain N subgraphs such that the sum of the edge weights of each subgraph is maximized, and the number of nodes in the subgraph meets a pre-set threshold.

[0041] The sharding module is used to execute the sharding process for the divided subgraphs and adopt a multi-level sharding strategy for hierarchical management.

[0042] The prediction module is used to perform the prediction subgraph affiliation process before the subgraph partitioning cycle begins; it uses the time series prediction method to predict the subgraph affiliation of the node, and samples and corrects the edges based on the prediction results.

[0043] In each subgraph partitioning cycle, the subgraph partitioning module, the slice partitioning module and the prediction module are executed sequentially.

[0044] Furthermore, a transaction relationship diagram is constructed in the blockchain system, specifically:

[0045] When the blockchain system starts, each node newly added to the graph is assigned a unique identifier ID and its edge weights with other nodes are initialized to zero.

[0046] At the same time, the system records each node's transaction history, including counterparty, transaction amount, and timestamp. Whenever a transaction occurs between two nodes, the system automatically records the transaction information and checks whether an existing edge exists. If an edge already exists, the edge's weight is increased; otherwise, a new edge is created and its weight is initialized to 1. The counterparty's information is also added to the node's transaction history for subsequent subgraph attribution prediction and edge correction. Each node maintains its own transaction history table, which only records counterparty information.

[0047] The constructed transaction relationship graph is divided into subgraphs in each subgraph division cycle. The specific division process is as follows:

[0048] First, the node with the largest edge weight in the graph is selected as the seed node and added to a new subgraph.

[0049] Then, we continue to search for nodes with the largest weight of edges connecting to nodes in the subgraph and that have not been partitioned, and add them to the subgraph until the number of nodes in the subgraph reaches the threshold or there are no nodes that meet the conditions.

[0050] Repeat the above process until N subgraphs are divided.

[0051] The sharding process is performed on the divided subgraphs, and a multi-level sharding strategy is adopted for hierarchical management:

[0052] Multi-level sharding includes two levels: basic shard i and upper management shard b. The specific definitions are as follows:

[0053] i-shard is specifically: the basic sharding layer of the blockchain network, which directly carries the daily transaction processing tasks of the nodes.

[0054] Specifically, the b-shard aggregates the active nodes of the i-shard with high-frequency interactions to form a cross-i-shard coordination management unit. The b-shard does not directly process terminal transactions, but is responsible for the pre-processing and hierarchical coordination of cross-i-shard transactions, optimizing the processing efficiency of cross-shard transactions through a hierarchical recursive mechanism.

[0055] The i-shard is divided as follows: according to the subgraph divided in step 2, the blockchain network is divided into i-shards for the first time; each subgraph corresponds to an i-shard.

[0056] The b-shard is divided as follows: the subgraphs are regarded as new nodes, and clustered according to the transaction frequency between the subgraphs to obtain multiple categories. For each category, k nodes are taken from the subgraphs contained in it according to the edge weights to form a b-shard.

[0057] The transaction frequency between subgraphs is the sum of the weights of the edges connecting the subgraphs.

[0058] If the number of i shards is n, the value of k is selected as

[0059] Furthermore, in the prediction module, a multi-feature time series prediction model is used to dynamically predict the subgraph to which the node belongs, as follows:

[0060] S401: Collect the historical transaction data of the nodes recorded in step 1 and construct a node-level time series feature set, which includes a time series sample of each node.

[0061] Each node's time series sample contains basic transaction features, relationship features, and environmental features. Basic transaction features include the number of transactions per hour, the average transaction amount, and the transaction time distribution. Relationship features are the time series of edge weights with other nodes. Environmental features are the load indicators of the i-shard.

[0062] Discretize the above features by time window to form a multidimensional time series input matrix X∈R T×D

[0063] S402: Use the CATS model to predict the subgraph to which the node belongs.

[0064] S403: Based on the prediction results, dynamically adjust the subgraph affiliation of the node. The specific process is as follows:

[0065] Set the confidence threshold according to the system characteristics. If a node belongs to subgraph S j The probability P j If it is greater than the threshold, it is marked as S j Otherwise, the nodes are assigned to the nearest subgraph according to the probability distribution through fuzzy clustering.

[0066] In the next subgraph partitioning cycle, only the edge weights of the nodes whose predicted ownership changes are adjusted. The adjustment method is: for the nodes from subgraph S a Transfer to S b Node u; node u and S a The edge weight of the middle node decays to w ua ×(1-α×(1-p a )); nodes u and S bThe edge weight of the middle node is enhanced to w ub ×(1+β×p b ).

[0067] where w ua For this node and subgraph S a The edge weight of the middle node, α is the attenuation coefficient, p a The node belongs to S a The probability w ub For this node and subgraph S b The edge weight of the middle node, β is the enhancement coefficient, p b The node belongs to S b probability.

[0068] Beneficial effects:

[0069] 1: The present invention provides a blockchain multi-level sharding load balancing method and system based on predicted subgraphs. Through a series of operations, including constructing a transaction relationship graph, rationally dividing subgraphs, multi-level sharding, and predicting subgraph attribution, the method optimizes the blockchain sharding strategy and improves the overall performance and scalability of the system. By constructing a transaction relationship graph and assigning edge weights based on transaction frequency, the closeness of transaction relationships between nodes can be accurately reflected, providing a reliable basis for subsequent subgraph division and sharding. In practical applications, this approach can better divide nodes with frequent transactions into the same subgraph or shard, reducing cross-shard transactions and improving transaction processing efficiency. The multi-level sharding strategy, including the division of i-shards and b-shards and the hierarchical management of b-shards, effectively reduces the number of cross-shard and cross-combination transactions and improves the system's load balancing capabilities. This strategy can rationally allocate transaction processing tasks based on the characteristics and functions of shards at different levels, making the system more efficient and stable when processing large-scale transactions and enhancing load balancing.

[0070] 2. This invention provides a blockchain multi-level sharding load balancing method and system based on predictive subgraphs. This method uses a periodic subgraph partitioning method to ensure that the sum of the subgraph's edge weights is as large as possible and the number of nodes meets a threshold. This optimizes the subgraph structure, further reduces the possibility of cross-subgraph transactions, and improves the overall system performance. This rational subgraph partitioning can fully utilize node resources, improve the system's parallel processing capabilities, and thus process more transactions.

[0071] 3. This invention provides a blockchain multi-level sharding load balancing method and system based on predicted subgraphs. This method uses a time series prediction method to predict the subgraph affiliation of nodes and performs sampling and correction of edges based on the predicted results. This avoids the high computational complexity and time overhead of completely rebuilding the subgraph. Edge weights are only corrected for nodes whose predicted affiliation has changed, improving the efficiency and accuracy of subgraph partitioning and further optimizing the blockchain sharding strategy. This prediction and correction method can better adapt to changes in node transaction behavior and maintain good system performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Figure 1 Schematic diagram of sharding optimization for traditional blockchain systems;

[0073] Figure 2 This is a schematic diagram of blockchain sharding optimization after optimization by the present invention. DETAILED DESCRIPTION

[0074] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0075] Example 1:

[0076] This embodiment provides a blockchain multi-level sharding load balancing method based on a prediction subgraph, which specifically includes the following steps:

[0077] Step 1: When the blockchain system starts, each newly added node is assigned a unique identifier (ID) and its edge weights with other nodes are initialized to zero. Simultaneously, each node's transaction history is recorded, including the counterparty, transaction amount, and timestamp. Whenever a transaction occurs between two nodes, the system automatically records the transaction details and checks whether an existing edge exists. If an edge already exists, its weight is increased, for example, by 1 for each transaction. Otherwise, a new edge is created and its weight is initialized to 1. The counterparty's information is also added to the node's transaction history for subsequent subgraph attribution prediction and edge correction. Each node maintains its own transaction history table, which only records counterparty information.

[0078] At the same time, in order to maintain the real-time and accuracy of the graph, at fixed time intervals, for new transactions, only the weights of the involved edges and their related nodes are updated to avoid the computational overhead caused by large-scale reconstruction.

[0079] Step 2: After a fixed period of time, the constructed transaction relationship graph is partitioned into subgraphs. The goal is to obtain N subgraphs, such that the sum of the edge weights in each subgraph is as large as possible, while also ensuring that the number of nodes in the subgraph meets a pre-set threshold. A heuristic approach based on a greedy algorithm is employed during the partitioning process. First, the node with the largest edge weight in the graph is selected as the seed node and added to a new subgraph. Next, nodes with the largest edge weights connected to nodes in the subgraph that have not been partitioned are continuously searched for and added to the subgraph until the number of nodes in the subgraph reaches the threshold or no nodes meet the criteria. This process is repeated until N subgraphs have been partitioned. For example, if the node count threshold is set to 100, in one partition, node A with the largest edge weight is first found and used as the seed node to create subgraph S1. Next, among the nodes connected to node A, node B with the largest edge weight that has not been partitioned is found and added to S1. Nodes are added in this manner until the number of nodes in S1 reaches 100 or no nodes meet the criteria. After that, another node with a larger edge weight that has not been divided is selected as a new seed node to continue dividing the next subgraph. In this way, the divided subgraph can be guaranteed to have a high internal connection density and reduce cross-subgraph transactions.

[0080] Step 3: During this sharding process, a multi-level sharding strategy is adopted to reduce cross-shard transaction overhead through hierarchical management. Multi-level sharding includes two core levels: basic shards (i-shards) and upper management shards (b-shards), which are specifically defined as follows:

[0081] i-shard (Initial Shard): The foundational sharding layer of a blockchain network, directly handling daily transaction processing tasks for nodes. i-shards are divided based on the transaction density between nodes (quantified by edge weights in the transaction graph), ensuring that intra-shard transactions account for the largest proportion and minimizing initial losses from cross-shard transactions.

[0082] Bridging Shard: The b-shard manages the shard hierarchy, aggregating active nodes from the i-shard with high-frequency interactions to form a cross-i-shard coordination management unit. The b-shard does not directly process terminal transactions, but is responsible for pre-processing and hierarchical coordination of cross-i-shard transactions, optimizing cross-shard transaction processing efficiency through a layered recursive mechanism.

[0083] The specific implementation of multi-level sharding is divided into the following three steps:

[0084] i-sharding: Based on the subgraphs created in step 2, the blockchain network is sharded for the first time, i-sharding. Each subgraph is assigned to an i-shard, ensuring that transactions between nodes within the same i-shard are relatively frequent, while cross-shard transactions are relatively rare. This reduces the performance loss associated with cross-shard transactions and improves transaction processing efficiency. For example, in a blockchain network with 1,000 nodes, 10 subgraphs are created, each corresponding to an i-shard, with each i-shard containing 100 nodes. In practice, the majority of transactions occur between nodes within the same i-shard, thus reducing the number of cross-shard transactions.

[0085] b-shard division: treat the subgraphs as new "nodes" and classify the subgraphs with the most frequent transactions into one category according to the frequency of transactions between the subgraphs. Then, take the top k nodes from these subgraphs to form b-shards. If the number of i-shards is n, then the value of k is For example, a clustering result contains 100 subgraphs. By counting the number of transactions between the subgraphs, the 10 nodes with the most transactions in each subgraph are found. These nodes together constitute the parent b-shard of the 100 i-shards.

[0086] b-shard hierarchical management: The b-shard obtained in the above process is defined as b-shard, and the different b-shards are divided into Clustering results are generated, and based on the number of transactions per node under the classification results, nodes in the upper quartile are selected as b-middle shards, where m is the number of b-lower shards currently required. Similarly, the above steps are continued for all the divided b-middle shards, until a b-upper shard is obtained from each of the several b-middle shard clustering results. At this point, the parameter m is set to the number of b-middle shards required. Through the above series of steps, b-shards at three levels, b-upper, b-middle, and b-lower, can be obtained.

[0087] Shard b directly manages shard i, is responsible for receiving cross-shard i transaction requests and attempts to coordinate and process them at its own level;

[0088] Shard b manages several shards under b and is responsible for handling cross-group transactions that cannot be handled by shards under b;

[0089] The b-top shard manages several b-middle shards and, as the highest coordination level, is responsible for complex transaction processing across b-middle shards.

[0090] When a node in shard b encounters a cross-shard i transaction, it first submits the transaction upward to shard b. Shard b determines whether it can be converted into an intra-shard transaction by coordinating the resources of its subordinate shards (for example, if the i shards where both parties to the transaction are located belong to shard b under the current b-middle shard, verification is completed within shard b). Otherwise, the transaction continues upward to shard b. If shard b still identifies the transaction as a cross-level transaction, traditional cross-shard transaction methods are executed (such as breaking the transaction into multiple sub-transactions, verifying each in the relevant shards, and then merging the results). This multi-level sharding system reduces the overhead of cross-shard transactions, improves the overall processing capacity of the system, and meets load balancing requirements.

[0091] Step 4: Based on the subgraph division, before the next subgraph division cycle begins, a multi-feature time series prediction model is used to dynamically predict the subgraph to which the node belongs, in order to adapt to the temporal variation characteristics of the node's transaction behavior. The specific implementation is as follows:

[0092] (1) Collect the historical transaction data of the nodes recorded in step 1 and construct a node-level time series feature set. The time series sample of each node contains the following dimensions:

[0093] a. Basic transaction characteristics: number of transactions per hour, average transaction amount, and transaction time distribution;

[0094] b. Relationship features: time series of edge weights with other nodes;

[0095] c. Environmental characteristics: load indicators of the i-shard.

[0096] Discretize the above features by time window to form a multidimensional time series input matrix X∈R T×D

[0097] (2) The CATS (Cross-Attention-only Time Series transformer) model is used as the prediction core. This model is based on the decoder part of the Transformer model. With the help of the cross-attention mechanism, the parameters of future horizon nodes are used as queries in a feature channel-independent manner through the Patching Layer, and the historical node data are used as key-value to be input into the multi-head attention mechanism. The Embedding Layer is uniformly parameterized to predict the basic transaction features of the relevant nodes after the relevant time nodes with low overhead.

[0098] (3) Based on the prediction results, dynamically adjust the subgraph belonging of the node. Set the confidence threshold according to the system characteristics. If a node belongs to subgraph S j The probability P j If it is greater than the threshold, it is marked as Sj Otherwise, the nodes are assigned to the nearest subgraph according to the probability distribution through fuzzy clustering (such as FCM algorithm). In the next subgraph reconstruction cycle, only the edge weights of the nodes whose predicted ownership changes are adjusted. a Transfer to S b Node u, which is connected to S a The edge weight decay of the midpoint is:

[0099] w ua ×(1-α×(1-p a ))(w ua For this node and subgraph S a The edge weight of the middle node, α is the attenuation coefficient, p a The node belongs to S a probability), and S b The edge weight of the middle node is enhanced to w ub ×(1+β×p b )(w ub For this node and subgraph S b The edge weight of the middle node, β is the enhancement coefficient, p b The node belongs to S b probability of ).

[0100] Through the above prediction and correction mechanism, the high computational overhead of completely reconstructing the subgraph is avoided (only about 10%-15% of the edge weights need to be adjusted), while maintaining the adaptability of the subgraph partitioning to changes in node transaction behavior.

[0101] Then, the next subgraph partitioning cycle begins and the process returns to step 2.

[0102] Example 2:

[0103] Take a blockchain network with 100,000 nodes as an example. The results of the traditional sharding method are as follows: Figure 1 As transactions between nodes continue to occur, operations are performed according to the method of the present invention:

[0104] Step 1: Construct a transaction relationship graph: During a specific time period, transactions between nodes in the blockchain network are monitored and recorded. For example, on the first day of trading, Node A completed five transactions with Node B and three transactions with Node C. Meanwhile, Node B and Node D conducted four transactions. Based on this transaction information, a graph structure is constructed that reflects the transaction relationships between nodes. In this graph, the edge weight connecting Node A and Node B is set to 5, the edge weight connecting Node A and Node C is set to 3, the edge weight connecting Node B and Node D is set to 4, and so on. During subsequent transactions, transaction information is continuously updated and edge weights are dynamically adjusted, so that the transaction relationship graph accurately reflects the closeness of transactions between nodes.

[0105] Step 2: Set the subgraph partitioning operation to occur every 24 hours. At the beginning of the second day, subgraph partitioning is performed based on the transaction relationship graph constructed and updated the previous day. Assume that the number of subgraphs N is pre-set to 100, and the node number threshold for each subgraph is 1000. First, find the node with the largest edge weight in the transaction relationship graph, assuming it is node A, and use it as the seed node to create subgraph S1. Then, among the remaining unpartitioned nodes, continuously search for the node with the largest edge weight connecting to the node in S1 and add it to S1 until the number of nodes in S1 reaches 1000, or no nodes meet the conditions. Using the same method, 100 subgraphs S2, S3, S4 to S100 are partitioned in sequence. During the partitioning process, the sum of the edge weights and the number of nodes of each subgraph are recorded in detail to ensure that the partitioning results meet the preset requirements.

[0106] Step 3: Each of the 100 subgraphs is mapped to 100 i-shards, i.e., i-shard 1 corresponds to subgraph S1, i-shard 2 corresponds to subgraph S2, and so on. In subsequent transaction processing, we strive to ensure that most transactions are completed within the same i-shard, thereby reducing the number of cross-i-shard transactions and the complexity of transaction processing.

[0107] Treat the divided subgraphs as new "nodes" and count the transaction frequency between each subgraph. For example, if it is found that the transactions between subgraphs S1, S2 to S10 are the most frequent, then these three subgraphs are grouped together. Select the top-ranked nodes in terms of transaction activity from subgraphs S1, S2, and S10. In this way, the sharding strategy is further optimized, making transactions within the b-shard more concentrated and improving transaction processing efficiency.

[0108] The b shard is divided into three levels: b-upper, b-middle, and b-lower, to build a hierarchical management system. Among them, the b-upper shard is responsible for managing the b-middle shard, the b-middle shard is responsible for managing the b-lower shard, and the b-lower shard directly manages the i shard. When a node in the b-lower shard encounters a cross-i shard transaction, it first attempts to process it within the b-lower shard. If it exceeds the processing capacity of the b-lower shard, the transaction will be submitted upward to the b-middle shard; if the b-middle shard still cannot process it, it will continue to be submitted upward to the b-upper shard. Figure 2 As shown in the figure, when processing a transaction across shards i1 and i4, the nodes in shard b1 (under b1) responsible for managing shard i1 and shard b3 (under b4) responsible for managing shard i4 will first attempt to process the transaction. If these nodes are unable to complete the task, the transaction information is passed to shards b1 and b2. Shard b2 processes the transaction based on its own resources and processing capabilities. If this still fails, it is passed to shard b1. Shard b1 coordinates the resources of multiple shards b1 and b2 to jointly complete the transaction and ensure smooth transaction execution. Ultimately, the cross-shard transaction is converted into an intra-shard transaction.

[0109] Step 4: Collect the node's historical transaction data, such as the complete transaction data from the first to the third day, and use the CATS model to predict the node's ownership of the subgraph. Taking node E as an example, assume that in the past 7 days of transaction data, the frequency of node E's transactions with nodes in subgraph S4 peaks every Wednesday from 6:00 PM to 8:00 PM (an average of 8 transactions per hour), while the frequency of its transactions with nodes in the current subgraph S5 gradually decreases (only 2 transactions per hour in the past 3 days). Using the CATS model to predict its trading behavior over the next 24 hours, the probability of belonging to S4 is 0.85 (with a threshold of 0.8), and the probability of belonging to S5 is 0.12.

[0110] Based on the predicted node subgraph assignment results, when constructing the subgraph on the fourth day, the edge weight between node E and nodes in S5 is reduced to original weight × (1 - 0.2 × (1 - 0.12)) = original weight × 0.824; the edge weight between node E and nodes in S4 is increased to original weight × (1 + 0.3 × 0.85) = original weight × 1.255. With these adjustments, node E is more likely to be assigned to S4 during the next subgraph split (step 2), thereby matching the actual changes in its transaction behavior and reducing cross-shard transactions.

[0111] The above examples demonstrate that the present invention's predictive subgraph-based blockchain multi-level sharding load balancing method can effectively optimize blockchain sharding strategies and improve system performance and scalability. In practical applications, relevant parameters, such as the number of subgraphs, node count threshold, and k value, can be flexibly adjusted to achieve optimal results based on the scale and transaction characteristics of different blockchain networks.

[0112] Example 3:

[0113] This embodiment provides a blockchain multi-level sharding load balancing system based on prediction subgraphs, including the following modules:

[0114] Graph construction module, used to build transaction relationship graphs in the blockchain system;

[0115] The subgraph partitioning module is used to partition the constructed transaction relationship graph into subgraphs within each subgraph partitioning cycle. The partitioning goal is to obtain N subgraphs such that the sum of the edge weights of each subgraph is maximized, and the number of nodes in the subgraph meets a pre-set threshold.

[0116] The sharding module is used to execute the sharding process for the divided subgraphs and adopt a multi-level sharding strategy for hierarchical management;

[0117] The prediction module is used to predict the subgraph affiliation process before the subgraph partitioning cycle begins. It uses the time series prediction method to predict the subgraph affiliation of the node and performs sampling correction on the edge based on the prediction results.

[0118] In each subgraph partitioning cycle, the subgraph partitioning module, the slice partitioning module and the prediction module are executed sequentially.

[0119] In the embodiment of the present invention, a transaction relationship graph is constructed in the blockchain system, specifically:

[0120] When the blockchain system starts, each newly added node is assigned a unique identifier ID and its edge weights with other nodes are initialized to zero;

[0121] At the same time, the system records the transaction history of each node, including the counterparty, transaction amount, and timestamp. Whenever a transaction occurs between two nodes, the system automatically records the transaction information and checks whether there is an existing edge. If the edge already exists, the edge weight is increased; otherwise, a new edge is created and its weight is initialized to 1. At the same time, the counterparty information is added to the node's transaction history for subsequent subgraph attribution prediction and edge correction. Each node maintains its own transaction history table, which only records the counterparty information.

[0122] The constructed transaction relationship graph is divided into subgraphs in each subgraph division cycle. The specific division process is as follows:

[0123] First, select the node with the largest edge weight in the graph as the seed node and add it to a new subgraph;

[0124] Then, it continuously searches for nodes with the largest weight of edges connected to nodes in the subgraph that have not been partitioned, and adds them to the subgraph until the number of nodes in the subgraph reaches the threshold or there are no nodes that meet the conditions;

[0125] Repeat the above process until N subgraphs are divided;

[0126] The sharding process is performed on the divided subgraphs, and a multi-level sharding strategy is adopted for hierarchical management:

[0127] Multi-level sharding includes two levels: basic shard i and upper management shard b. The specific definitions are as follows:

[0128] i-shard is specifically: the basic sharding layer of the blockchain network, which directly carries the daily transaction processing tasks of the nodes;

[0129] Shard b specifically aggregates the active nodes of shard i with high frequency interactions to form a cross-i-shard coordination management unit. Shard b does not directly process terminal transactions, but is responsible for pre-processing and hierarchical coordination of cross-i-shard transactions, optimizing the processing efficiency of cross-shard transactions through a layered recursive mechanism.

[0130] i-sharding is divided as follows: Based on the subgraphs divided in step 2, the blockchain network is divided into i-shards for the first time; each subgraph corresponds to an i-shard;

[0131] The b-shard is divided as follows: the subgraphs are treated as new nodes, and clustered according to the transaction frequency between the subgraphs to obtain multiple categories. For each category, k nodes are extracted from the subgraphs contained in it according to the edge weight to form a b-shard;

[0132] The transaction frequency between subgraphs is the sum of the weights of the edges connecting the subgraphs;

[0133] If the number of i shards is n, the value of k is selected as

[0134] In the prediction module, a multi-feature time series prediction model is used to dynamically predict the subgraph to which a node belongs, as follows:

[0135] S401: Collect the historical transaction data of the nodes recorded in step 1 and construct a node-level time series feature set, which includes a time series sample of each node;

[0136] The time series sample of each node contains basic transaction features, relationship features, and environmental features. Basic transaction features include the number of transactions per hour, the average amount of a single transaction, and the transaction time distribution. Relationship features are the time series of edge weights with other nodes. Environmental features are the load indicators of the i-shard.

[0137] Discretize the above features by time window to form a multidimensional time series input matrix X∈R T×D

[0138] S402: Using the CATS model to predict the subgraph to which the node belongs;

[0139] S403: Based on the prediction results, dynamically adjust the subgraph affiliation of the node. The specific process is as follows:

[0140] Set the confidence threshold according to the system characteristics. If a node belongs to subgraph S j The probability P j If it is greater than the threshold, it is marked as S j candidate nodes; otherwise, the nodes are assigned to the nearest subgraph according to the probability distribution through fuzzy clustering;

[0141] In the next subgraph partitioning cycle, only the edge weights of the nodes whose predicted ownership changes are adjusted. The adjustment method is: for the nodes from subgraph S a Transfer to S b Node u; node u and S a The edge weight of the middle node decays to w ua ×(1-α×(1-p a ));;Node u and S b The edge weight of the middle node is enhanced to w ub ×(1+β×p b );

[0142] where w ua For this node and subgraph S a The edge weight of the middle node, α is the attenuation coefficient, p a The node belongs to S a The probability w ub For this node and subgraph S b The edge weight of the middle node, β is the enhancement coefficient, p b The node belongs to S b probability.

[0143] In summary, the above are only preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A blockchain multi-level sharding load balancing method based on prediction subgraph, characterized in that: The steps include: Step 1: Build a transaction relationship graph in the blockchain system; Step 2: Sub-divide the constructed transaction relationship graph into sub-graphs within each sub-graph division cycle. The division goal is to obtain N sub-graphs such that the sum of the edge weights of each sub-graph is maximized, and the number of nodes in the sub-graph meets a pre-set threshold. Step 3: Execute the sharding process for the divided subgraphs, and adopt a multi-level sharding strategy for hierarchical management; Step 4: Before the next subgraph partitioning cycle begins, perform the prediction subgraph affiliation process; use the time series prediction method to predict the subgraph affiliation of the node, and perform sampling correction on the edge based on the prediction result; The next subgraph partitioning cycle begins, and the process returns to step 2.

2. The blockchain multi-level sharding load balancing method based on prediction subgraph according to claim 1 is characterized in that: The transaction relationship diagram is constructed in the blockchain system as follows: When the blockchain system starts, each newly added node is assigned a unique identifier ID and its edge weights with other nodes are initialized to zero; At the same time, the system records each node's transaction history, including counterparty, transaction amount, and timestamp. Whenever a transaction occurs between two nodes, the system automatically records the transaction information and checks whether an existing edge exists. If an edge already exists, the edge's weight is increased; otherwise, a new edge is created and its weight is initialized to 1. The counterparty's information is also added to the node's transaction history for subsequent subgraph attribution prediction and edge correction. Each node maintains its own transaction history table, which only records counterparty information.

3. The blockchain multi-level sharding load balancing method based on prediction subgraph according to claim 1 is characterized in that: The constructed transaction relationship graph is divided into subgraphs in each subgraph division cycle. The specific division process is as follows: First, select the node with the largest edge weight in the graph as the seed node and add it to a new subgraph; Then, it continuously searches for nodes with the largest weight of edges connected to nodes in the subgraph that have not been partitioned, and adds them to the subgraph until the number of nodes in the subgraph reaches the threshold or there are no nodes that meet the conditions; Repeat the above process until N subgraphs are divided.

4. The blockchain multi-level sharding load balancing method based on prediction subgraph according to claim 1 is characterized in that: The sharding process is performed on the divided subgraphs, and a multi-level sharding strategy is used for hierarchical management: Multi-level sharding includes two levels: basic shard i and upper management shard b. The specific definitions are as follows: i-shard is specifically: the basic sharding layer of the blockchain network, which directly carries the daily transaction processing tasks of the nodes; Specifically, the b-shard aggregates the active nodes of the i-shard with high-frequency interactions to form a cross-i-shard coordination management unit. The b-shard does not directly process terminal transactions, but is responsible for the pre-processing and hierarchical coordination of cross-i-shard transactions, optimizing the processing efficiency of cross-shard transactions through a hierarchical recursive mechanism.

5. The blockchain multi-level sharding load balancing method based on prediction subgraph according to claim 4 is characterized in that: The i-shards are divided as follows: according to the subgraphs divided in step 2, the blockchain network is divided into i-shards for the first time; each subgraph corresponds to an i-shard.

6. The blockchain multi-level sharding load balancing method based on prediction subgraph according to claim 4 is characterized in that: The b-shard is divided as follows: the subgraphs are regarded as new nodes, and clustered according to the transaction frequency between the subgraphs to obtain multiple categories. For each category, k nodes are extracted from the subgraphs contained in it according to the edge weight to form a b-shard; The transaction frequency between the subgraphs is the sum of the weights of the edges connecting the subgraphs; If the number of i shards is n, the value of k is selected as 7. The blockchain multi-level sharding load balancing method based on prediction subgraph according to any one of claims 1 to 6, characterized in that: In step 4, a multi-feature time series prediction model is used to dynamically predict the subgraph to which the node belongs, as follows: S401: Collect the historical transaction data of the nodes recorded in step 1 and construct a node-level time series feature set, which includes a time series sample of each node; The time series samples of each node include basic transaction features, relationship features, and environmental features: the basic transaction features include the number of transactions per hour, the average amount of a single transaction, and the transaction time distribution; the relationship features are the time series of edge weights with other nodes; and the environmental features are the load indicators of the i-shard. Discretize the above features by time window to form a multidimensional time series input matrix X∈R T×D S402: Using the CATS model to predict the subgraph to which the node belongs; S403: Based on the prediction results, dynamically adjust the subgraph affiliation of the node. The specific process is as follows: Set the confidence threshold according to the system characteristics. If a node belongs to subgraph S j The probability P j If it is greater than the threshold, it is marked as S j candidate nodes; otherwise, the nodes are assigned to the nearest subgraph according to the probability distribution through fuzzy clustering; In the next subgraph partitioning cycle, only the edge weights of the nodes whose predicted ownership changes are adjusted. The adjustment method is: for the nodes from subgraph S a Transfer to S b Node u; node u and S a The edge weight of the middle node decays to w ua ×(1-α×(1-p a ));;Node u and S b The edge weight of the middle node is enhanced to w ub ×(1+β×p b ); where w ua For this node and subgraph S a The edge weight of the middle node, α is the attenuation coefficient, p a The node belongs to S a The probability w ub For this node and subgraph S b The edge weight of the middle node, β is the enhancement coefficient, p b The node belongs to S b probability.

8. The blockchain multi-level sharding load balancing system based on prediction subgraph is characterized by: Includes the following modules: Graph construction module, used to build transaction relationship graphs in the blockchain system; The subgraph partitioning module is used to partition the constructed transaction relationship graph into subgraphs within each subgraph partitioning cycle. The partitioning goal is to obtain N subgraphs such that the sum of the edge weights of each subgraph is maximized, and the number of nodes in the subgraph meets a pre-set threshold. The sharding module is used to execute the sharding process for the divided subgraphs and adopt a multi-level sharding strategy for hierarchical management; The prediction module is used to predict the subgraph affiliation process before the subgraph partitioning cycle begins. It uses the time series prediction method to predict the subgraph affiliation of the node and performs sampling correction on the edge based on the prediction results. In each subgraph partitioning cycle, the subgraph partitioning module, the slice partitioning module and the prediction module are executed sequentially.

9. The blockchain multi-level sharding load balancing system based on prediction subgraph according to claim 8 is characterized in that: The transaction relationship diagram is constructed in the blockchain system as follows: When the blockchain system starts, each newly added node is assigned a unique identifier ID and its edge weights with other nodes are initialized to zero; At the same time, the system records the transaction history of each node, including the counterparty, transaction amount, and timestamp. Whenever a transaction occurs between two nodes, the system automatically records the transaction information and checks whether there is an existing edge. If the edge already exists, the edge weight is increased; otherwise, a new edge is created and its weight is initialized to 1. At the same time, the counterparty information is added to the node's transaction history for subsequent subgraph attribution prediction and edge correction. Each node maintains its own transaction history table, which only records the counterparty information. The constructed transaction relationship graph is divided into subgraphs in each subgraph division cycle. The specific division process is as follows: First, select the node with the largest edge weight in the graph as the seed node and add it to a new subgraph; Then, it continuously searches for nodes with the largest weight of edges connected to nodes in the subgraph that have not been partitioned, and adds them to the subgraph until the number of nodes in the subgraph reaches the threshold or there are no nodes that meet the conditions; Repeat the above process until N subgraphs are divided; The sharding process is performed on the divided subgraphs, and a multi-level sharding strategy is used for hierarchical management: Multi-level sharding includes two levels: basic shard i and upper management shard b. The specific definitions are as follows: i-shard is specifically: the basic sharding layer of the blockchain network, which directly carries the daily transaction processing tasks of the nodes; Shard b specifically aggregates the active nodes of shard i with high frequency interactions to form a cross-i-shard coordination management unit. Shard b does not directly process terminal transactions, but is responsible for pre-processing and hierarchical coordination of cross-i-shard transactions, optimizing the processing efficiency of cross-shard transactions through a layered recursive mechanism. The i-shards are divided as follows: according to the subgraphs divided in step 2, the blockchain network is divided into i-shards for the first time; each subgraph corresponds to an i-shard; The b-shard is divided as follows: the subgraphs are regarded as new nodes, and clustered according to the transaction frequency between the subgraphs to obtain multiple categories. For each category, k nodes are extracted from the subgraphs contained in it according to the edge weight to form a b-shard; The transaction frequency between the subgraphs is the sum of the weights of the edges connecting the subgraphs; If the number of i shards is n, the value of k is selected as 10. The blockchain multi-level sharding load balancing system based on prediction subgraph according to claim 8, characterized in that: In the prediction module, a multi-feature time series prediction model is used to dynamically predict the subgraph to which a node belongs, as follows: S401: Collect the historical transaction data of the nodes recorded in step 1 and construct a node-level time series feature set, which includes a time series sample of each node; The time series samples of each node include basic transaction features, relationship features, and environmental features: the basic transaction features include the number of transactions per hour, the average amount of a single transaction, and the transaction time distribution; the relationship features are the time series of edge weights with other nodes; and the environmental features are the load indicators of the i-shard. Discretize the above features by time window to form a multidimensional time series input matrix X∈R T×D S402: Using the CATS model to predict the subgraph to which the node belongs; S403: Based on the prediction results, dynamically adjust the subgraph affiliation of the node. The specific process is as follows: Set the confidence threshold according to the system characteristics. If a node belongs to subgraph S j The probability P j If it is greater than the threshold, it is marked as S j candidate nodes; otherwise, the nodes are assigned to the nearest subgraph according to the probability distribution through fuzzy clustering; In the next subgraph partitioning cycle, only the edge weights of the nodes whose predicted ownership changes are adjusted. The adjustment method is: for the nodes from subgraph S a Transfer to S b Node u; node u and S a The edge weight of the middle node decays to w ua ×(1-α×(1-p a ));;Node u and S b The edge weight of the middle node is enhanced to w ub ×(1+β×p b ); where w ua For this node and subgraph S a The edge weight of the middle node, α is the attenuation coefficient, p a The node belongs to S a The probability w ub For this node and subgraph S b The edge weight of the middle node, β is the enhancement coefficient, p b The node belongs to S b probability.

Images