A shard-oriented blockchain pool optimization propagation account partitioning method

Abstract

The present application relates to the technical field of blockchain sharding, and discloses a pool optimization propagation account division method for a sharded blockchain. The method comprises: obtaining a set of blockchain accounts and transaction data, and constructing an account transaction undirected graph using a five-tuple edge structure; establishing a multi-objective optimization function that simultaneously optimizes cross-shard transaction frequency, load balancing, and fund pool balance; constructing a mobile candidate shard list for each account, and expanding highly connected accounts to all shards; using multi-thread parallel computing to evaluate the mobile score, executing the mobile according to the greedy strategy, and updating the shard state; iteratively optimizing to obtain an optimal division scheme, and deploying it to a sharded blockchain system to realize dynamic account allocation. The present application solves the problems of existing algorithms being prone to local optimum and low fund pool management efficiency, realizes low cross-shard rate and fund flow optimization while ensuring load balancing, and improves the transaction processing success rate and overall performance of the sharded blockchain system.

Description

Technical Field

[0001] This invention relates to the field of blockchain sharding technology, and in particular to a pool-optimized propagation account partitioning method for sharded blockchains. Background Technology

[0002] In recent years, with the rapid development of the digital economy, blockchain technology, with its decentralized, immutable, transparent, and trustworthy characteristics, has demonstrated enormous application potential in numerous fields such as finance, healthcare, transportation, and the Internet of Things. Based on a P2P underlying architecture, blockchain networks offer a revolutionary solution for building trusted distributed systems, driving a significant shift from traditional centralized to decentralized models. With its immense innovative potential and broad application prospects, blockchain technology is gradually moving from theoretical concepts to large-scale commercial applications.

[0003] However, current blockchain architectures still face significant challenges in terms of scalability, falling far short of the performance requirements for supporting large-scale applications. In traditional blockchain systems, each node needs to maintain and synchronize all information on the blockchain, verifying and storing every transaction across the network. This incurs enormous computational and storage overhead to maintain the consistency and security of the entire network. Therefore, existing blockchain systems are severely inadequate in handling massive transaction demands.

[0004] To address this issue, blockchain sharding technology emerged, which improves the overall system's processing power and scalability by breaking down a massive blockchain network into multiple relatively independent sub-networks. The core objective of sharding is to divide the blockchain state, which originally required maintenance by all nodes in the network, into different shards, allowing each node to process only the data and transactions within its own shard. By optimizing sharding strategies, the system can effectively reduce the proportion of cross-shard transactions, lower synchronization latency and communication costs during system operation, and lay the foundation for efficient, low-latency, large-scale blockchain applications.

[0005] With the development of sharding technology, some representative solutions have introduced relay account models to handle cross-shard transactions. In this model, when the sender and receiver belong to different shards, a relay account needs to be selected to assist in completing the transaction. To overcome the problem of relay account balance limitations, a liquidity pool mechanism has been proposed and applied to sharding systems as an innovative solution. The core idea of ​​a liquidity pool is to maintain a shared reserve of funds in each shard. When the balance of a single relay account is insufficient to meet the needs of large cross-shard transactions, the system can provide additional liquidity support through the liquidity pool. This mechanism can not only significantly alleviate the problem of transaction failures caused by insufficient funds in relay accounts, but also improve the overall sharding system's ability to handle large transactions and sudden fund flows.

[0006] Account partitioning algorithms, as a core component of sharding systems, directly impact the frequency of cross-shard transactions and the efficiency of the liquidity pool. Existing account partitioning algorithms typically model this problem as a graph partitioning problem, treating accounts as vertices and transaction relationships as edges, aiming to reduce the number of cross-shard transactions by optimizing partitioning strategies. However, traditional partitioning algorithms primarily focus on transaction frequency, neglecting the crucial impact of transaction amount and fund flow on sharding performance. Under a fixed number of shards, these algorithms are prone to getting trapped in local optima, failing to adequately consider the fund balance and liquidity needs among shards, thus affecting the efficiency of the liquidity pool and the overall system performance.

[0007] Therefore, there is an urgent need for a new account partitioning method that can comprehensively consider transaction amount, fund flow, and load balancing to further improve the success rate of cross-shard transactions and the overall performance of the system. The new account partitioning algorithm should optimize the sharding structure and fund distribution in real time, reducing transaction failures due to insufficient funds, thereby achieving a more efficient and reliable large-scale blockchain sharding system. Summary of the Invention

[0008] To address the aforementioned shortcomings of existing technologies, this invention provides a pool-optimized propagation account partitioning method for sharded blockchains. This invention uses a special undirected graph edge structure to store transaction quantity, amount, and flow information, thereby ensuring system load balancing while achieving a balance between fund inflows and outflows within each shard.

[0009] The specific technical solution of the present invention is as follows:

[0010] This invention provides a pool-optimized propagation account partitioning method for sharded blockchains, comprising the following steps:

[0011] Step S1: Obtain a set of blockchain accounts and their transaction data, and construct an undirected graph of account transactions; the blockchain accounts include digital currency accounts or device identity accounts in the fields of finance, healthcare, transportation, and the Internet of Things; establish a multi-objective optimization function that simultaneously optimizes the number of cross-shard transactions, load balancing between shards, and the balance of fund inflows and outflows in the fund pool; randomly assign an initial shard to each account, and calculate the overall score of the current sharding scheme based on the undirected graph and the sharding scheme using the multi-objective optimization function;

[0012] Step S2: Based on the connection relationships of the accounts in the undirected graph, construct a list of potential move shards for each account;

[0013] Step S3: Use multi-threading to calculate the overall score change when each account moves to each shard in its candidate shard list, thereby evaluating the score improvement after the move and selecting the optimal target shard for each account.

[0014] Step S4: Based on the score improvement of all accounts obtained in Step S3, sort all accounts to be moved in descending order and perform the move operation in sequence, while updating the global shard status.

[0015] Step S5: Repeat steps S2 to S4 iteratively until the preset convergence condition is met, indicating that no more beneficial moves are made by any account. The algorithm converges to the optimal account partitioning scheme and outputs the result.

[0016] Preferably, the edges in the undirected graph described in step S1 are defined using a quintuple data structure, in the form of:

[0017] ;

[0018] in, It is by the side Connecting two different endpoint accounts; It is the unique index of the edge; It refers to the number of transactions between two accounts; This represents the net transaction amount between the two accounts.

[0019] Preferably, the net transaction amount mentioned in step S1 The calculation rule is as follows: net cash flow is determined based on string sorting and comparison of account addresses. ,but , indicating account to account The net transfer amount; if ,but , indicating account to account The net transfer amount; by aggregating multiple transactions between the same pair within one epoch, the number of transactions is increased. The net transaction amount continues to accumulate. It comprehensively reflects the fund flow and net transfer value of the two accounts.

[0020] Preferably, the multi-objective optimization function in step S1 is the overall score function Score, which is derived from the cross-fragmentation rate score function Score. cross Load balancing scoring function Score load Score function for evaluating changes in the funding pool pool The weighted geometric mean is composed of:

[0021] ;

[0022] Where α, β, and γ are weighting factors; the higher the value, the more important the corresponding target is in the score, and the following conditions must be met. When the three optimization objectives of cross-sharding rate, load balancing, and liquidity pool are of equal importance, the weighting factors are set to be equal. .

[0023] Preferably, the calculation formula for the cross-fragmentation rate scoring function is as follows:

[0024] ;

[0025] in, Indicates fragmentation The number of transactions within, Representation and fragmentation The number of cross-shard transactions, where k is the shard number used to identify which shard is currently being traded, and p is the total number of shards.

[0026] The formula for calculating the load balancing score function is as follows:

[0027] ;

[0028] in, express Load within the fragment and These are the penalty factors for underload and overload, respectively. For ideal load balancing;

[0029] The scoring function for changes in the capital pool adopts the L∞ norm form, and the calculation formula is as follows:

[0030] ;

[0031] in, The attenuation coefficient is... express The value of the sharded capital pool, It is an adjustment factor set up to adapt to different currency issuance scales.

[0032] Furthermore, in step S1, the sharding scheme is defined as a mapping. ,in, Indicates account Assigned to a shard ,Right now , , indicating the first Each shard contains a subset of accounts;

[0033] Furthermore, in step S1, when calculating the cross-fragmentation rate scoring function, the fragmentation is defined. The set of internal edges:

[0034] ;

[0035] Define fragments The set of related cross-part edges:

[0036] ;

[0037] Then, we can obtain the information on all sharding edges under the current sharding scheme:

[0038] ;

[0039] The set of edges can be used to derive the partitioning. Number of internal transactions:

[0040] ;

[0041] It can also be divided into pieces. The number of related cross-shard transactions:

[0042] .

[0043] Furthermore, in step S1, when calculating the cross-shard rate scoring function, in the sharded blockchain, a cross-shard transaction is converted into two transactions, which are placed in the transaction pools of the two shards respectively. Therefore, the result is... The number of fragmented loads is:

[0044] ;

[0045] Fragments The internal fund pool has two flow directions: one is the transfer from the fund pool to the receiving account, and the other is the receipt of funds from the sending account. This defines the inflow and outflow of funds into the fund pool.

[0046] ;

[0047] Because of regulations It is a value that can be positive or negative; when the transaction is... Transfer to hour, It is positive at this time. The funding pool of the segment will receive The funds, and The funding pool of the segment needs to make expenditures. Funds are given to the recipient. Conversely, when... When it is negative, it is Transfer to At this time, the corresponding capital pool changes. Amount. And at the end of one epoch, the change in the funding pool is as follows:

[0048] ;

[0049] Furthermore, in step S1, the fund pool change scoring function is calculated based on the maximum fluctuation value of each segment of the fund pool.

[0050] Preferably, the specific method for constructing the mobile candidate shard list in step S2 is as follows: for accounts with normal connectivity, their mobile candidate shard set is composed of the union of the current shard and the shards of all neighboring nodes; for highly connected accounts, their candidate shard range is expanded to all shards to broaden the solution space search range; the highly connected account refers to an account whose neighboring accounts cover more than half of the total number of shards.

[0051] Preferably, the specific method of using multi-threaded parallel computing in step S3 is as follows: start several worker threads and evenly distribute all account nodes to each thread for concurrent processing; each worker thread is responsible for calculating the optimal target shard of its assigned account in the candidate shards; the move evaluation adopts an incremental calculation method, only calculating the edge weight changes directly affected by the change of the account's position; all threads use atomic operations to add their calculation results to the shared move candidate list.

[0052] Preferably, the specific method for performing the move operation in step S4 is as follows: sort all move candidate schemes generated in the parallel computing stage in descending order according to the score improvement value; adopt a greedy strategy to prioritize the account move operation that can bring the greatest benefit; verify again before actually executing the move whether the operation can still improve the global score; for the move operation that passes the verification, update the shard mapping relationship of the corresponding account, and maintain the account list of each shard.

[0053] Preferably, in step S5:

[0054] Before executing step S2 in each iteration, the list of account nodes is randomly shuffled to avoid the impact of the order of account node processing on the final result.

[0055] Continuously monitor the changing trend of the overall score;

[0056] The preset convergence conditions include at least one of the following:

[0057] ① When no account moves during a certain iteration, it indicates that the current sharding scheme has reached a local optimum, and the algorithm terminates naturally.

[0058] ② Set the maximum number of iterations as a forced termination condition to prevent the algorithm from running for too long in complex network topologies;

[0059] ③ When the score improvement in multiple consecutive iterations is less than a preset threshold, terminate the process early to save computing resources;

[0060] Through the aforementioned random shuffling process, continuous monitoring, and multi-level convergence control mechanism, efficient account partitioning optimization is achieved while ensuring solution quality.

[0061] This invention also provides a method for dynamic account allocation in a sharded blockchain system. Applying the account allocation method to the operation of the sharded blockchain system includes the following steps:

[0062] When the blockchain network completes a predefined epoch cycle or reaches a preset block height threshold, the account partitioning method is automatically triggered. The preset block height threshold can be pre-configured by the sharded blockchain system according to business needs, for example, set to a fixed number of block heights such as every 1000 blocks or 5000 blocks generated. The specific value can be flexibly adjusted according to the system transaction frequency and sharding scale.

[0063] The optimized account partitioning scheme is deployed to each physical shard node of the blockchain network;

[0064] Each shard node updates its maintained account list in local storage based on the received account partitioning scheme;

[0065] Based on the updated account partitioning scheme, control the routing of subsequent transactions between the corresponding physical shard nodes;

[0066] The blockchain network includes digital currency accounts or device identity accounts in the fields of finance, healthcare, transportation, and the Internet of Things.

[0067] The beneficial technical effects of this invention are as follows:

[0068] (1) This invention fundamentally solves the key technical problem of fund pool management in sharding systems. By constructing a special undirected graph edge structure to store transaction quantity, amount and flow information, a multi-objective optimization model that comprehensively considers cross-shard transaction frequency, load balancing between shards and fund pool balance is established, which effectively solves the problem of cross-shard transaction stability being affected by drastic changes in fund pool balance in the prior art;

[0069] (2) This invention significantly improves the global optimization capability of the account partitioning algorithm. By expanding the search range of the solution space, it breaks through the limitation of the fixed number of fragments, expands the candidate fragments of highly connected accounts to all fragments, and uses an improved label propagation algorithm to solve the problem, effectively avoiding the problem that the existing account partitioning algorithm is prone to getting stuck in local optima;

[0070] (3) This invention achieves a comprehensive improvement in the overall performance of the sharded blockchain system. By optimizing the account partitioning scheme, the dynamic redistribution of accounts is realized. Under the condition of satisfying the sharding load balancing constraint, low cross-sharding rate and optimal fund flow are achieved at the same time, providing a reliable technical guarantee for building an efficient and stable large-scale blockchain sharding system. Attached Figure Description

[0071] Figure 1 This is a basic flowchart of the pool-optimized propagation account partitioning method for sharded blockchains provided in this embodiment of the invention;

[0072] Figure 2 This is a schematic diagram of the construction of an undirected graph of account relationships with a special edge structure provided in an embodiment of the present invention;

[0073] Figure 3 This is a schematic diagram illustrating the key indicators in each iteration provided by an embodiment of the present invention;

[0074] Figure 4 This is the score of each indicator in the 64-slice case provided in the embodiment of the present invention, where "Monoxide", "Metis" and "CLPA" are three benchmark algorithms used for comparison, and "Ours" is the method of this invention;

[0075] Figure 5 This is the score of various indicators in the case of 1024 fragments provided in the embodiment of the present invention. Among them, "Monoxide", "Metis" and "CLPA" are three benchmark algorithms used for comparison, and "Ours" is the method of this invention.

[0076] Figure 6 This is a schematic diagram of the score under the condition of considering only single-objective optimization provided by an embodiment of the present invention. Detailed Implementation

[0077] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. Obviously, the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0078] Example 1: Method Example

[0079] This embodiment provides a pool-optimized propagation account partitioning method for sharded blockchains. The basic process is as follows: Figure 1 As shown, it includes the following steps:

[0080] Step S1: Obtain the current blockchain account status, randomly assign an initial shard to each account, and calculate the overall score of the current sharding scheme;

[0081] This method uses Ethereum, a mature application of blockchain in the financial field, as the verification platform. The transaction data originates from real on-chain transaction records within the Ethereum network. This transaction data is generated globally by users through client software such as digital wallets and decentralized applications (DApps), specifically including actual transfers and smart contract calls—financial business operations. These transactions are verified by miner nodes in the network and packaged onto the blockchain to form immutable transaction credentials. The data used in the test is valid inter-account transfer transaction data extracted from all blocks within a specified time window. The test data in this embodiment comes from the collection and analysis of real-time transaction data streams on the Ethereum mainnet.

[0082] During the initialization phase of this invention, the program reads transaction data from all active accounts within the current epoch and constructs a transaction array. Each element of the transaction array stores the sender, receiver, and transfer amount of that transaction. The epoch is a pre-defined processing period, which can be a fixed time period, a period containing a fixed number of blocks, or a periodic event triggered by the system to re-divide accounts. Within an epoch, the system collects and aggregates all occurring transactions as the foundational data for subsequently constructing the account transaction graph and executing the account partitioning algorithm.

[0083] Define the set of all account addresses as ,in, The total number of accounts. Indicates the first Individual accounts;

[0084] Define a set of fragments ,in , indicating the first Each shard contains a subset of accounts. This mapping must satisfy the following constraints: , Account mutual exclusion: an account can only be assigned to one shard; account completeness: all accounts are assigned shards. The sharding scheme is defined as a mapping. ,in Indicates account Assigned to a shard ,Right now ;

[0085] Then, each transaction element is traversed to construct a complete undirected graph of account transactions. The vertices of the graph represent the account addresses participating in the transaction, and the edges represent the transaction relationships between accounts. In other words, every transaction in the blockchain can be represented as an edge of the graph, and the set of edges is defined as follows: Since each edge also needs to store the flow information of transaction amounts, and directed graphs are typically used to store directional data, but transactions between accounts are bidirectional, using directed graphs would lead to inaccurate representation of transaction data. Therefore, a new edge structure is proposed to represent changes in amounts using undirected graphs. The construction process of the undirected graph of account relationships with this special edge structure is as follows: Figure 2 As shown, each edge It takes the form of a quintuple:

[0086] ;

[0087] in, It is by the side Connecting two different endpoint accounts, out of order and requiring ; It is the unique index of the edge; It refers to the number of transactions between two accounts; This represents the net transaction amount between the two accounts.

[0088] When processing transactions, the program updates the weights of corresponding edges in the undirected graph using atomic operations: for frequency dimensions, the weights are incremented by 1; for amount dimensions, the lexicographical order of the addresses of the transacting parties is compared. If the sender's address is smaller, the transaction amount is incremented; otherwise, it is decremented, thus realizing the net transaction amount. The calculation rule is to determine the direction of net cash flow based on a string comparison of account addresses. If... ,but , indicating account to account The net transfer, and This indicates the account to account The net transfer. Here, str() is a string format function that extracts the string attributes of the account address, for example... Indicates account The string attribute is less than the account in the sorting. The string attribute. Within an epoch, by aggregating multiple transactions between the same pair of accounts, the net transfer value is increased. Continuously accumulate, thus This reflects the flow of funds and net transfer figures between the two accounts.

[0089] To better describe the state of a shard, the following set is defined. (Define shards) The set of internal edges:

[0090] ;

[0091] Define fragments The set of related cross-partition edges:

[0092] ;

[0093] Then, we can obtain the information on all sharding edges under the current sharding scheme:

[0094] ;

[0095] The set of edges can be used to derive the partitioning. Number of internal transactions:

[0096] ;

[0097] It can also be divided into segments. The number of related cross-shard transactions:

[0098] ;

[0099] To simplify, this invention will segment... The load is defined as the number of transactions it needs to process. The number of transactions in a shard consists of two parts: the number of transactions within the shard and the number of transactions associated with it. The number of related cross-shard transactions. In a sharded blockchain, a cross-shard transaction is split into two transactions, each placed in a transaction pool in one of the two shards. Therefore, the number of cross-shard transactions can be calculated. The number of fragmented loads is:

[0100] ;

[0101] Fragments The internal funds pool has two flow directions: one is the transfer from the funds pool to the receiving account, and the other is the receipt of funds from the sending account. Fund inflows and outflows are defined as follows:

[0102] ;

[0103] Because of regulations It is a value that can be positive or negative; when the transaction is... Transfer to hour, It is positive at this time. The funding pool of the segment will receive The funds, and The funding pool of the segment needs to make expenditures. Funds are given to the recipient. Conversely, when... When it is negative, it means Transfer to At this time, the corresponding capital pool changes as follows: Amount. At the end of an epoch, shards The changes in the capital pool are as follows:

[0104] ;

[0105] After constructing the complete undirected graph of account transactions, the program uses a random allocation strategy to assign an initial shard identifier to each account to achieve load balancing among shards. Subsequently, a mapping dictionary (HashMap) is constructed with the account address as the key and the shard number as the value. Based on this data structure, the time complexity of querying the shard number of any account is O(1), thus significantly improving query efficiency.

[0106] Subsequently, the system performs an overall evaluation of the current sharding scheme based on three predefined scoring functions and one overall score function. Because there are three optimization objectives, three scoring functions and one overall score function are required.

[0107] Cross-shard ratio is a commonly used metric for evaluating cross-shard behavior, and its value is a ratio within the interval [0,1]. A higher value indicates fewer cross-shard instances. The specific definition is as follows:

[0108] ;

[0109] The load balancing score indicates whether the load across shards in the current sharding scheme is the same, and is defined as follows:

[0110] ;

[0111] in, express Load within the fragment This is a penalty factor when the load is insufficient. These are the penalty factors for overload conditions; these two penalty factors, acting as power exponents, together influence the distribution range of the scoring function. It is recommended to set them between 1 and 3. Too large a value will lead to an overly concentrated score distribution, while too small a value will lead to an overly dispersed distribution; the ratio of the two... / This determines the relative penalty for overload and underload in the system; a ratio greater than 1 indicates greater sensitivity to overload. The optimal parameter setting is... =1.5, =2, this configuration imposes a relatively stricter penalty on the system for overload; if equal penalties are required, it can be set to 2. and Simultaneously set to 1. The load balancing scoring function is designed as a piecewise function, allowing for flexible adjustment of tolerance to different load conditions based on actual system operating requirements. When When the load is high, it indicates that the current system is more tolerant of underload conditions; conversely, it is more tolerant of overload conditions. The ideal load balancing is defined as follows:

[0112] ;

[0113] The ideal scenario here considers the increased load caused by cross-shard transactions under the current sharding scheme, while the ultimate goal of a perfect account partitioning algorithm is to completely eliminate cross-shard transactions. Therefore, the truly ideal load should be that the total transaction volume within this epoch is evenly distributed across the number of shards p, i.e. However, due to the existence of cross-shard transactions, the actual load will deviate from this ideal situation, and the deviation will continue to increase as the number of cross-shard transactions increases.

[0114] The existence of cross-shard transactions can lead to an increase in the liquidity pool within one shard and a decrease in the liquidity pool within another shard. When there are no cross-shard transactions, the liquidity pools in each shard remain stable; however, large cross-shard transactions can cause the liquidity pools to become either overflowing or scarce, thus affecting the stability of the blockchain sharding system. Ideally, the change in the liquidity pools of each shard should be zero. However, when assessing the difference between this change and the zero distribution, KL divergence or JS divergence should not be used. This is because if only one or two pool changes reach a maximum value in the current sharding scenario, while the remaining values ​​are small, a divergence score might still be obtained. However, this contradicts the design goal of sharded blockchains, which ideally maintain low pool flows across all shards. Therefore, the evaluation should focus on controlling the maximum value, rather than the distribution pattern of the entire numerical sequence. Thus, using... Norms are used to represent fractions:

[0115] ;

[0116] in, To control The norm decay coefficient, the larger the value, the steeper the scoring function curve and the faster the decay rate; this coefficient is used to adjust the system's sensitivity to the maximum fluctuation of the fund pool, and its recommended range is [1, 10]. A larger value makes it easier to obtain a higher score; a smaller value results in a more stringent scoring standard. Experimental comparisons are conducted. The results under different parameters such as 3, 5, and 10 showed that their impact on the final partitioning scheme was relatively small, but... When the score is 5, the score distribution is the most moderate, so this is the preferred value;

[0117] This is an adjustment factor set up to accommodate different currency issuance scales, and its main function is to normalize the scale of changes in the liquidity pool. Because the value units of different cryptocurrencies differ greatly (for example, 1 BTC and 1 ETH have different actual values), setting this factor is necessary. The amounts for different currencies can be adjusted to similar orders of magnitude for fair evaluation. For Ethereum (ETH), the preferred value is set to... ;

[0118] The rating ranges from [0,1]. A larger value indicates that the fund pool changes less and the fund pool is more stable.

[0119] Account partitioning needs to simultaneously consider three objectives: cross-sharding rate, load balancing between shards, and changes in shard liquidity pools. Therefore, a comprehensive evaluation function is required to provide a unified overall performance assessment. This comprehensive evaluation function is defined as follows:

[0120] ;

[0121] Where α, β, and γ are weighting factors, requiring The reason for using a weighted geometric mean score instead of an arithmetic mean is that the geometric mean is more sensitive to smaller values, effectively avoiding the problem of a lower score being masked or ignored by other higher scores in the arithmetic mean. This is especially important when the sharding scheme only focuses on the processing score of cross-shard transactions and ignores the score of changes in the liquidity pool; relying solely on the former's higher score may obscure the latter's importance.

[0122] This scoring function aggregates multiple key performance indicators such as cross-shard transaction costs, load balancing between shards, and liquidity pool utilization efficiency to calculate a comprehensive score, which serves as a benchmark reference value for subsequent optimization iterations.

[0123] Step S2: Based on the connection relationships in the account transaction graph, construct a mobile candidate shard list for each account, and expand the candidate range to all shards for highly connected accounts;

[0124] In the candidate shard construction stage of this invention, a personalized list of mobile candidate shards is generated for each account node based on the topology of the account transaction graph. Based on the undirected account transaction graph initially input to the algorithm, the neighboring account nodes of the account node in the graph are calculated, their shard IDs are retrieved using a HashMap, and stored in a HashSet. The program calls the Sizeof() function to calculate the size of the candidate shard set, and based on this, nodes are divided into account nodes with normal connectivity and account nodes with high connectivity. The size of the candidate shard set is then compared with a preset threshold. The data is compared to a set of 1 / 2 of the total number of shards. If the set size exceeds the threshold, a reset operation is performed, replacing its list with the set of all shards, and setting the height connectivity flag (is_hub_account) of that account node to True; otherwise, it is set to False and marked as a normal connectivity account node. In the program, accounts with the height connectivity flag (is_hub_account) set to True are usually key transaction hubs or frequently trading accounts in the system, possessing stronger global influence. Their position changes can affect the state of a large number of related edges, thus significantly impacting the overall sharding performance. Furthermore, providing these accounts with a larger exploration space can prevent the algorithm from prematurely converging to a local optimum, allowing them to explore the solution space more effectively using their influence and increasing the likelihood of global optimization.

[0125] Step S3: Use multi-threading to compute the optimal target shard for each account in its candidate shards in parallel, and evaluate the score improvement after the move;

[0126] In the parallel computing phase of this invention, the algorithm starts several worker threads. The main thread divides the task into sublists based on the account nodes and assigns them to multiple worker threads for parallel computation. Atomic operations are used between threads to avoid concurrency issues. Each worker thread is responsible for calculating the optimal target shard for its assigned account node in its candidate shard set. Specifically, for each account node to be processed, the thread first obtains its current shard identifier and candidate shard list, creates a copy of the sharding scheme in local memory, and only traverses the edges directly connected to the moving account, attempting to move the account to its candidate shard, and recalculates the impact of these edge state changes on the scoring function score. The move evaluation adopts an incremental calculation method, only calculating the edge weight changes directly affected by the change in the account's position, avoiding recalculating the score of the entire graph, thereby significantly improving computational efficiency. Single account node move evaluation reduces the computational cost from O(|E|) to O(deg(v)), enabling the algorithm to handle ultra-large-scale account graphs. When a candidate shard can bring a positive score improvement, the move scheme is recorded as a candidate move operation. All threads use atomic operations to add their computation results to a shared list of move candidates, ensuring data consistency and thread safety for concurrent access.

[0127] Step S4: Sort all accounts to be moved from highest to lowest score improvement, perform the move operation in sequence, and update the global shard status.

[0128] In the move execution phase of this invention, all move candidate schemes generated in the parallel computing phase are first sorted in descending order of their score improvement value. A greedy strategy is adopted to prioritize the account move operation that brings the greatest benefit. After sorting, the algorithm processes each move candidate scheme sequentially and one by one, verifying again whether the operation can still improve the global score before actually executing the move. For each verified move operation, the system immediately updates the global shard state and score to ensure that subsequent move decisions are based on the latest system state. Since the global function considers three objective optimizations, the optimal solution at this time takes into account cross-shard rate, load balancing, and fund pool optimization. This step aims to prevent suboptimal solutions caused by interference from multiple accounts moving simultaneously. For verified move operations, the algorithm updates the shard mapping relationship of the corresponding account in the mapping dictionary table, and uses a two-dimensional array to maintain the account list of each shard, while updating the global score in real time. Each successful move operation is accumulated in a counter as an important basis for judging the algorithm's convergence. This serialized move execution strategy maximizes the optimization effect of each iteration while ensuring the convergence of the algorithm.

[0129] Step S5: Repeat the above process until all accounts no longer generate beneficial moves, and the algorithm converges to the optimal solution;

[0130] Steps S2 to S4 constitute a complete optimization iteration. Through multiple iterations, the algorithm can gradually correct the sharding scheme, continuously improving the overall system score and eventually converging to a stable, high-quality solution. The algorithm employs multiple termination conditions to ensure convergence to a stable optimal solution. The main convergence judgment is based on a counter: when no account moves during a certain iteration, it indicates that the current sharding scheme has reached a local optimum, and the algorithm terminates naturally, exiting the loop and outputting the optimal mapping dictionary. To prevent the algorithm from running for too long in complex network topologies, the system sets a maximum number of iterations as a forced termination condition. When the counter accumulates to more than the maximum number of iterations, the loop exits and the result is output. Before each iteration, the algorithm randomly shuffles the account node list. This randomization strategy avoids the influence of the order of account node processing on the final result, improving the robustness of the algorithm. In addition, the algorithm continuously monitors the changing trend of the global score during the iteration process. When the score improvement in multiple consecutive iterations is less than a preset threshold, it can terminate early to save computational resources. Through this multi-level convergence control mechanism, this invention can achieve efficient account partitioning optimization while ensuring solution quality.

[0131] Example 2: Experimental Verification

[0132] The test case of this invention uses a hardware test environment that simulates a sharded blockchain. The core is an Intel Xeon Platinum 8352Y server equipped with 219 GB of RAM and a high-speed SSD storage array for persistent storage of blockchain data.

[0133] It is important to note that this experiment is a simulated environment; no real distributed physical nodes were deployed or hardware network impairment devices were used to introduce real network disturbances such as network latency and packet loss. However, the proposed method is applicable to real sharded blockchain systems, particularly in blockchain environments in fields such as finance, healthcare, transportation, or the Internet of Things. The method will run in a real distributed system composed of multiple physical shard nodes. Each shard is typically hosted by one or more physical server nodes, which are interconnected through high-speed network devices (such as switches and routers) to form the physical foundation of the sharded blockchain network. Each node is equipped with a high-performance processor, a large-capacity storage array, and a hardware security module (HSM) to ensure transaction processing performance, persistent data storage, and secure key management. The account partitioning method of this invention runs by integrating into the client software or consensus protocol of each shard node. Based on transaction data of real digital currency accounts or device identity accounts collected from the blockchain in the aforementioned fields, it periodically performs optimization calculations and synchronizes the generated partitioning scheme to all physical shard nodes in the network, thereby guiding transaction routing and processing in a real network environment. In this embodiment, the algorithm uses multi-threaded concurrency and memory variable isolation technology to simulate the parallel processing and state synchronization behavior of multiple shard nodes on a single high-performance server in order to evaluate the performance of the account partitioning algorithm in a sharded blockchain.

[0134] The experimental platform software environment was Ubuntu 22.04 and Python 3.12. To verify the effectiveness of the pool optimization propagation multi-objective optimization method proposed in this invention, real transaction data from Ethereum (ETH) derived from the open-source academic dataset XBlock-ETH was used. In real sharded blockchain systems, the data used comes from real digital currency accounts or device identity accounts and their transaction data in blockchains in fields such as finance, healthcare, transportation, or the Internet of Things.

[0135] This embodiment uses real transaction data from the Ethereum mainnet, covering various on-chain business types such as ordinary transfers, smart contract calls, and contract creation. It realistically reflects financial activities such as asset transfers between users and decentralized application (DApp) interactions within the blockchain network. The data was obtained from an academic dataset derived from the historical block parsing of Ethereum full nodes, containing complete transaction records from block numbers 21000000 to 21249999. Each transaction record includes detailed fields such as transaction hash, timestamp, addresses of both parties, transfer amount, gas consumption parameters, smart contract function call information, transaction type, and transaction execution status, fully preserving the real business characteristics of transactions on the Ethereum network and ensuring the authenticity and representativeness of the test data. Block heights range from 21000001 to 21249998, totaling 150,000 transactions involving 183,986 account addresses, which, after merging, form 139,671 transaction edges.

[0136] In the load balancing scoring function, Set to 1.5. Setting it to 2 indicates greater tolerance for underload conditions and the use of a scoring function under non-ideal conditions. The funding pool assessment uses... Norm, Set to 5, adjustment factor In Ethereum (Eth) set to .

[0137] This invention compares three metrics under a sharded blockchain architecture using a liquidity pool, applying different account partitioning methods. The cross-shard rate and the maximum liquidity pool fluctuation are negatively correlated with the score; that is, the lower the cross-shard rate and the smaller the maximum liquidity pool fluctuation, the higher the score. The load balancing metric assesses the uniformity of load distribution across shards based on the coefficient of variation (CV). Since cross-shard transactions need to be decomposed into intra-shard transactions, and the load calculation incorporates transaction decomposition factors, the CV value and the score are generally negatively correlated (although within local optimization intervals, the CV value may fluctuate slightly due to the need to consider other objectives). In summary, this metric effectively reflects the load balancing effect of different account partitioning methods.

[0138] To comprehensively evaluate the performance of the proposed method, three typical account partitioning algorithms were selected for comparative experiments to cover different technical paths from no optimization, static optimization to dynamic optimization. These included: Monoxide (which does not employ a specific account partitioning strategy but randomly assigns transactions to each shard), Metis (a static allocation method based on graph partitioning), and CLPA (a constraint label propagation account partitioning algorithm). All comparative methods used the same Ethereum transaction dataset and sharding architecture configuration, and uniformly used a random allocation strategy during the account initialization phase. Regarding the algorithm execution flow, Monoxide does not perform account reallocation during the transaction processing phase; Metis maintains a fixed allocation after completing a one-time graph partition during the preprocessing phase and does not adjust it further; CLPA and this invention both employ iterative optimization mechanisms. The difference lies in that CLPA only optimizes the cross-shard rate and load balancing objectives, while this invention further introduces a liquidity pool constraint objective, achieving coordinated optimization of the three objectives through multi-objective fitness evaluation during label propagation. To ensure fairness in the comparison, the same scoring function and parameter settings were used for the load balancing evaluation of each method. Detailed evaluation results are shown in Table 1.

[0139] Table 1 Comparison of partitioning results under different numbers of fragments

[0140]

[0141] (1) Iteration effect

[0142] The iterative results of this invention are as follows Figure 3 As shown in the figure, the data from the first 8 iterations is presented, with the first iteration representing the initial state. It should be noted that under the initial random sharding scheme, as shown in Table 1 "Initial State," the cross-sharding rate increases with the number of shards. This aligns with theoretical expectations: since accounts are randomly assigned, the more shards there are, the smaller the chance that any two accounts with trading relationships will be assigned to the same shard. This leads to most transactions becoming cross-sharding transactions, pushing up the cross-sharding rate. This phenomenon verifies the rationality of the initial experimental setup. From... Figure 3 As can be seen, this method converges rapidly in the first few rounds, with the cross-sharding rate quickly dropping below 8%. Since random sharding is used in the initialization phase, the load on each shard is relatively balanced at this time. As the account address allocation is adjusted, the coefficient of variation (CV) of the load changes, but remains relatively stable. The maximum fluctuation of the inflow and outflow of the liquidity pool in each shard also gradually decreases as the method is executed. According to the initial state data shown in Table 1, the maximum fluctuation of the liquidity pool is in the range of 25688 Eth to 38059 Eth, with a typical case exceeding 35000 Eth (see Table 1). Figure 3(c) Vertical axis); After optimization by this invention, the peak value is reduced to below 15000 Eth, with an optimization rate of over 57.1%. This optimization greatly alleviates the problem of decreased success rate in cross-shard transaction processing caused by large-scale fund flows;

[0143] Experiments with different shard sizes show that the first three rounds involve large-scale account partitioning adjustments, while subsequent rounds involve small-scale fine-tuning of the optimal solution. This helps shorten the convergence time of the method. For blockchain systems requiring high throughput, an early stopping mechanism can be adopted in a timely manner, which can still demonstrate good performance even with a better solution obtained in fewer iterations.

[0144] (2) Cross-fragment performance

[0145] like Figure 4 As shown, with 64 shards, this invention was compared with other account partitioning algorithms. It can be seen that in handling cross-shard transactions, our invention (Ours) has a cross-shard rate of 4%, while Monoxide, which does not use an account partitioning algorithm, has a cross-shard rate as high as 98%, and Metis and CLPA both have 9%. Our invention's (Ours) cross-shard rate is lower than all the compared algorithms, demonstrating its superiority in handling cross-shard transactions.

[0146] In terms of load handling, neither Monoxide nor Metis considered load balancing; their load performance depended on the actual transaction distribution of the current transaction pool, with scores of 0.788 and 0.916, respectively. CLPA and our invention both optimized the load, scoring 0.79 and 0.916, respectively. Our invention scored the highest, indicating that it has good load balancing capabilities.

[0147] Regarding pool optimization, only this invention (Ours) considers this objective. In the comparative algorithm, Metis's maximum pool fluctuation reached 28262 Eth, while this invention, while achieving better results in cross-shard rate and load balancing, optimizes this value to 11204 Eth (11203.549 in Table 1 is rounded off), a reduction of approximately 60.4%. This optimization design directly solves the technical problem described in the background art of cross-shard transaction processing failure caused by drastic fluctuations in the pool.

[0148] (3) Performance of large-scale fragmentation scenarios

[0149] Figure 5The experimental results of this invention are presented in a large-scale sharding scenario with 1024 partitions. Under large-scale sharding, Monoxide, which does not use an account partitioning algorithm, has a cross-sharding rate as high as 99%, while Metis has a rate of 36%. The high cross-sharding rate severely affects the transaction processing performance of the sharded blockchain. CLPA has a rate of 6%, while our invention (Ours) has a rate of 5%, the lowest among all algorithms, indicating that even under the three-objective constraint, our invention still exhibits superior performance.

[0150] Regarding load balancing in large-scale sharding, Monoxide and Metis do not consider load balancing, and their actual effectiveness depends on the specific transaction. CLPA scores 0.59, while our invention scores 0.70, significantly higher than CLPA, demonstrating our invention's superiority in load balancing.

[0151] Regarding the optimization of the funding pool in large-scale sharding, only our invention has optimized this objective. In the comparison algorithm, Monoxide's maximum funding pool fluctuation reached 36109 Eth, while our invention, while performing excellently in both cross-sharding rate and load balancing, optimized this value to 13232 Eth (13231.627 in Table 1, rounded), a reduction of approximately 63.4%. This indicates that our invention can maintain good performance in large-scale sharding scenarios while considering multiple objectives.

[0152] (4) Focus on the performance of different optimization objectives

[0153] To analyze the contributions and interactions of each optimization objective within the framework of this invention, ablation experiments were conducted by controlling the weighting factors. Specifically, in the overall scoring function, independent optimization of the objective was achieved by setting the weights (α, β, γ) of a single objective to 1 and the rest to 0.

[0154] Figure 6 The table visually demonstrates the scores achievable when focusing on different single objectives at six different partition sizes. To further provide a precise performance comparison, Table 2 lists the final performance data achieved by single-objective optimization at different partition sizes. As a benchmark, the complete result set of the three-objective co-optimization (in this invention) is uniformly presented in Table 1, which fully demonstrates the stability and reliability of the method of this invention at different partition sizes.

[0155] Table 2 Performance results of single-objective optimization and three-objective optimization

[0156]

[0157] comprehensive Figure 6 Based on the experimental data in Tables 1 and 2, the following conclusions can be drawn:

[0158] ① Under single-objective optimization, this invention can achieve significant results on that objective. For example, when optimizing only the cross-shard rate, it can be reduced to below 4.5%; when optimizing only the fund pool, its maximum fluctuation can be reduced to about 4 Eth, which verifies the effectiveness of each optimization sub-function;

[0159] ② The three-objective collaborative optimization method described in this invention achieves a significant improvement in overall performance. Compared with the initial random sharding scheme (whose maximum fluctuation value in the capital pool is typically higher than 35,000 Eth, specifically ranging from 25,688 Eth to 38,059 Eth according to Table 1), after optimization by this invention, the peak value is reduced to below 15,000 Eth, with an optimization margin of over 57.1%, greatly alleviating the problem of decreased transaction processing success rate caused by large capital flows;

[0160] ③ There are inherent trade-offs and couplings among the optimization objectives. For example, optimizing only the cross-sharding rate significantly worsens the maximum volatility of the liquidity pool; conversely, optimizing only the volatility of the liquidity pool leads to a persistently high cross-sharding rate. This phenomenon confirms that collaborative optimization of multiple objectives, rather than isolated optimization, is crucial for achieving optimal overall performance of sharded blockchains. The core value of this invention lies precisely in this multi-objective collaborative optimization framework.

[0161] In summary, the experimental results fully validate the effectiveness of the proposed method. Under different shard sizes, this invention achieves optimal cross-shard rate (maintained at 4%-6%) and load balancing (low CV value), while reducing the maximum fluctuation of the liquidity pool by over 60%, effectively mitigating cross-shard transaction failures. Its core technical advantages are: the account partitioning mechanism based on tag propagation effectively reduces the cross-shard rate; the multi-objective optimization framework facilitates load balancing; and the innovative liquidity pool constraint mechanism improves transaction processing success rate at the system level. The overall solution possesses high practical value.

[0162] Although the embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, and for those of ordinary skill in the art, various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention. Therefore, the present invention is not limited to the specific details without departing from the general concept defined by the claims and their equivalents.

Claims

1. A pool-optimized propagation account partitioning method for sharded blockchains, characterized in that, Includes the following steps: Step S1: Obtain the blockchain account set and its transaction data, and construct an undirected graph of account transactions; the blockchain accounts include digital currency accounts or device identity accounts in the fields of finance, healthcare, transportation, and the Internet of Things; establish a multi-objective optimization function that simultaneously optimizes the number of cross-shard transactions, load balancing between shards, and the balance of fund inflows and outflows in the fund pool; Each account is randomly assigned an initial shard, and based on the undirected graph and sharding scheme, the overall score of the current sharding scheme is calculated using the multi-objective optimization function; Step S2: Based on the connectivity of the accounts in the undirected graph, construct a list of candidate shards for each account. The specific method for constructing the list of candidate shards is as follows: For accounts with normal connectivity, their candidate shard set is the union of the current shard and the shards of all neighboring nodes; for highly connected accounts, their candidate shard range is expanded to all shards to broaden the solution space search range; the highly connected accounts refer to accounts whose neighboring accounts cover more than half of the total number of shards. Step S3: Use multi-threading to calculate the overall score change when each account moves to each shard in its candidate shard list, thereby evaluating the score improvement after the move and selecting the optimal target shard for each account. Step S4: Based on the score improvement of all accounts obtained in Step S3, sort all accounts to be moved in descending order and perform the move operation in sequence, while updating the global shard status. Step S5: Repeat steps S2 to S4 iteratively until the preset convergence condition is met, indicating that no more beneficial moves are made by any account. The algorithm converges to the optimal account partitioning scheme and outputs the result.

2. The method according to claim 1, characterized in that, The edges in the undirected graph described in step S1 are defined using a quintuple data structure, in the form of: in, It is by the side Connecting two different endpoint accounts; It is the unique index of the edge; It refers to the number of transactions between two accounts; This represents the net transaction amount between the two accounts.

3. The method according to claim 2, characterized in that, The net transaction amount mentioned in step S1 The calculation rule is as follows: Net cash flow is determined based on a string comparison of the account address; if... ,but , indicating account to account The net transfer amount; if ,but , indicating account to account The net transfer amount; by aggregating multiple transactions between the same pair within one epoch, the number of transactions is increased. The net transaction amount continues to accumulate. It comprehensively reflects the fund flow and net transfer value of the two accounts.

4. The method according to claim 1, characterized in that, The multi-objective optimization function mentioned in step S1 is the overall score function Score, which is derived from the cross-fragmentation rate score function Score. cross Load balancing scoring function Score load Score function for evaluating changes in the funding pool pool The weighted geometric mean is composed of: Where α, β, and γ are weighting factors; the higher the value, the more important the corresponding target is in the score, and the following conditions must be met. When the three optimization objectives of cross-sharding rate, load balancing, and liquidity pool are of equal importance, the weighting factors are set to be equal. .

5. The method according to claim 4, characterized in that, The calculation formula for the cross-segmentation rate scoring function is as follows: in, Indicates fragmentation The number of transactions within, Representation and fragmentation The number of cross-shard transactions, where k is the shard number used to identify which shard is currently being traded, and p is the total number of shards. The formula for calculating the load balancing score function is as follows: in, express Load within the fragment and These are the penalty factors for underload and overload, respectively. For ideal load balancing; The scoring function for changes in the capital pool adopts the L∞ norm form, and the calculation formula is as follows: in, The attenuation coefficient is... express The value of the sharded capital pool, It is an adjustment factor set up to adapt to different currency issuance scales.

6. The method according to claim 1, characterized in that, The specific method of using multi-threaded parallel computing in step S3 is as follows: start several worker threads and evenly distribute all account nodes to each thread for concurrent processing; each worker thread is responsible for calculating the optimal target shard of its assigned account in the candidate shards; the move evaluation adopts an incremental calculation method, only calculating the edge weight changes directly affected by the change of the account's position; all threads use atomic operations to add their calculation results to the shared move candidate list.

7. The method according to claim 1, characterized in that, The specific method for performing the move operation in step S4 is as follows: sort all move candidate schemes generated in the parallel computing stage in descending order according to the score improvement value; adopt a greedy strategy to prioritize the account move operation that can bring the greatest benefit; verify again before actually executing the move whether the operation can still improve the global score; for the move operation that passes the verification, update the shard mapping relationship of the corresponding account, and maintain the account list of each shard.

8. The method according to claim 1, characterized in that, In step S5: Before executing step S2 in each iteration, the list of account nodes is randomly shuffled to avoid the impact of the order of account node processing on the final result. Continuously monitor the changing trend of the overall score; The preset convergence conditions include at least one of the following: ① When no account moves during a certain iteration, it indicates that the current sharding scheme has reached a local optimum, and the algorithm terminates naturally. ② Set the maximum number of iterations as a forced termination condition to prevent the algorithm from running for too long in complex network topologies; ③ When the score improvement in multiple consecutive iterations is less than a preset threshold, terminate the process early to save computing resources; Through the aforementioned random shuffling process, continuous monitoring, and multi-level convergence control mechanism, efficient account partitioning optimization is achieved while ensuring solution quality.

9. A method for dynamic account allocation in a sharded blockchain system, characterized in that, Applying the account partitioning method according to any one of claims 1-8 to the operation of a sharded blockchain system includes the following steps: When the blockchain network completes a predefined epoch cycle or reaches a preset block height threshold, the method described in any one of claims 1-8 is automatically triggered. The optimized account partitioning scheme is deployed to each physical shard node of the blockchain network; Each shard node updates its maintained account list in local storage based on the received account partitioning scheme; Based on the updated account partitioning scheme, control the routing of subsequent transactions between the corresponding physical shard nodes; The blockchain network includes digital currency accounts or device identity accounts in the fields of finance, healthcare, transportation, and the Internet of Things.

Images