A transaction prediction-based dynamic allocation method and system for a sharded blockchain account

Abstract

The present application relates to the technical field of blockchain sharding, and particularly relates to a sharding blockchain account dynamic allocation method and system based on transaction prediction. The present application firstly constructs a historical weighted transaction relationship graph sequence, and generates a predicted transaction relationship graph of the next time slice by using a prediction model; secondly, core accounts are identified and sharding anchor points are initialized based on predicted activity, and non-core accounts are allocated to the sharding in which the anchor points are located according to affinity; then, isolated subgraphs are constructed for unallocated accounts and community discovery is performed, and overall allocation is performed based on the connection strength of communities and sharding; finally, normalized load is calculated in combination with sharding processing capacity, and completely isolated communities are allocated to the sharding with the lowest load and state migration is performed. By predicting future transaction structure, combining core anchor point adsorption, community overall migration and heterogeneous load compensation mechanism, the present application effectively reduces the number of cross-sharding transactions, and solves the problems of load imbalance and group structure being scattered in a heterogeneous environment.

Description

Technical Field

[0001] This invention relates to the field of blockchain sharding technology, and in particular to a method and system for dynamic allocation of sharded blockchain accounts based on transaction prediction. Background Technology

[0002] With the development of blockchain technology, sharded blockchain technology has gradually become an important development direction to improve the overall throughput of the system and reduce the storage and computing pressure on a single chain. Sharded blockchains divide the entire network's accounts and transactions into multiple parallel shards for processing, enabling each shard to execute transactions in parallel, thereby improving the system's parallel processing capabilities. However, in a sharded blockchain system, when the participating accounts of a transaction belong to different shards, a cross-shard transaction is formed. Cross-shard transactions usually require cross-shard consistency coordination and state synchronization, and introduce additional cross-shard message interaction, verification, and submission processes, with communication rounds and processing overhead typically higher than intra-shard transactions. Therefore, how to reduce the number of cross-shard transactions while maintaining load balancing across shards has become one of the key technical issues in the design of sharded blockchain systems.

[0003] In existing sharded blockchain systems, a mapping relationship typically needs to be established between accounts and shards. This means that each account is assigned to a specific shard at any given time, and the transactions initiated or participated in by that account are primarily processed by that shard. Regarding the account shard allocation problem, existing technologies mainly offer the following implementation schemes:

[0004] The first type of scheme is the static account allocation scheme. During system initialization, this scheme statically maps accounts to different shards based on the hash value of the account identifier or preset rules. This method is simple to implement and has low maintenance costs, but its allocation results are unrelated to account transaction behavior and cannot reflect the interaction relationships between accounts. In actual operation, high-frequency interaction accounts are easily distributed across different shards, resulting in a high proportion of cross-shard transactions, which in turn introduces significant cross-shard coordination overhead and reduces the system's effective throughput.

[0005] The second type of solution is a periodic adjustment scheme based on historical statistical information. This type of scheme summarizes information such as the trading frequency and volume of accounts within a historical time window, and then periodically adjusts the allocation of account shards accordingly, aiming to reduce the proportion of cross-shard transactions. However, this type of scheme usually only uses account-level summary statistics, lacking a fine-grained characterization of "account-to-account" interactions, and is slow to respond to the dynamic characteristics of trading behavior changing over time. When trading patterns change, the allocation strategy often lags behind actual needs and is difficult to adapt to the new trading structure in a timely manner.

[0006] The third type of solution is a passive adjustment solution based on real-time transactions. This type of solution migrates or reallocates some accounts during system operation based on real-time or recent cross-shard transaction data. This method can alleviate local cross-shard pressure to some extent, but its adjustment behavior usually occurs after cross-shard transactions have already occurred, making it a post-event compensation mechanism and unable to fundamentally reduce the probability of cross-shard transactions. Furthermore, frequent account migrations may introduce additional state migration overhead and system instability.

[0007] The fourth type of solution is the account allocation scheme based on transaction graph partitioning. This type of solution constructs a historical transaction relationship graph, treating accounts as graph nodes and transaction relationships between accounts as graph edges. It then uses graph partitioning or community detection methods to group strongly related accounts into the same shard as much as possible, thereby reducing the number of cross-shard edges. This type of solution can reduce cross-shard transactions to some extent by utilizing account interaction relationships, but it usually relies on static or historical transaction graphs for partitioning and lacks the ability to predict future transaction relationships. As transaction relationships evolve over time, the historical partitioning results are prone to becoming invalid, leading to a rebound in the proportion of cross-shard transactions and requiring another large-scale account migration.

[0008] Furthermore, in real-world deployment environments, sharded blockchain systems often operate in heterogeneous computing environments, meaning that nodes corresponding to different shards differ in terms of computing power, storage resources, and the scale of transactions they can handle. However, most existing account allocation technologies are designed based on the assumption of homogeneous sharding, assuming that each shard has the same processing power and load limit. In heterogeneous environments, if a uniform allocation or adjustment strategy is still adopted, some shards may become overloaded due to carrying highly active accounts, while other shards may underutilize their resources, thereby reducing the overall system throughput and affecting operational stability.

[0009] Meanwhile, existing technologies often use individual accounts as the basic adjustment unit when allocating or migrating accounts, lacking a holistic consideration of the account group structure. In real-world trading networks, accounts typically exhibit high-frequency group interactions, with some accounts forming stable interaction sets over extended periods. Ignoring this group structure and dispersing closely related accounts across different shards will lead to continuous cross-shard transactions, and single-account-level migration strategies will struggle to reliably converge such groups to the same shard.

[0010] In summary, existing sharded blockchain account allocation technologies generally suffer from the following shortcomings:

[0011] First, the account allocation strategy lacks the ability to predict future transaction relationships, making it difficult to proactively optimize before transactions occur;

[0012] Secondly, it is difficult to simultaneously achieve the goals of reducing the number of cross-shard transactions and maintaining shard load balance, especially in heterogeneous environments with uneven shard processing capabilities, where it is not adaptable enough.

[0013] Third, insufficient consideration was given to the temporal evolution characteristics and group structure of account transaction relationships, resulting in poor stability and adaptability of the allocation results.

[0014] Therefore, there is an urgent need for a technical solution that can predict future transaction structures based on the evolutionary characteristics of account transaction relationships and, taking into account the differences in sharding processing capabilities, achieve a reasonable allocation of accounts among shards, in order to overcome the aforementioned problems of existing technologies. Summary of the Invention

[0015] To address the common problems in existing sharded blockchain systems during account allocation, such as high cross-shard transaction ratios, easy load imbalance, and insufficient adaptation to the dynamic evolution of transaction relationships, this invention provides a dynamic account allocation method for sharded blockchains based on transaction prediction. This method can predict future transaction structures before transactions occur and, considering differences in shard processing capabilities, achieve a reasonable allocation of accounts across shards, thereby reducing the number of cross-shard transactions and maintaining shard load balance. The method includes the following steps:

[0016] S1. Obtain historical transaction data of the target blockchain account, divide it into continuous time slice sequences according to preset time windows, and construct a historical weighted transaction relationship graph sequence;

[0017] S2. Based on the historical weighted transaction relationship graph sequence, predict the transaction relationship using a time series transaction prediction model to generate a predicted transaction relationship graph;

[0018] S3. Based on the predicted transaction relationship graph, calculate the transaction activity of each account node and sort the account nodes from high to low according to the transaction activity. Select the account nodes of the preset number of shards as core account nodes, and the remaining account nodes in the predicted transaction relationship graph as non-core account nodes. Use each core account node as the initial anchor point to construct the first shard set.

[0019] S4. Based on the predicted transaction relationship graph and the first shard set, calculate the affinity between non-core account nodes and each initial anchor point, and based on the calculated affinity, assign non-core account nodes to the shards where each initial anchor point is located to obtain the second shard set. Record the remaining unassigned non-core account nodes as isolated account nodes and construct the isolated account node set.

[0020] S5. Based on the second shard set and the isolated account node set, induce the generation of isolated subgraphs for each isolated account node. Through the community detection algorithm, cluster the isolated subgraphs to obtain multiple isolated communities. Calculate the affinity between each isolated community and each shard in the second shard set. Based on the calculated affinity, assign each isolated community to each shard in the second shard set to obtain the third shard set. Record the remaining unassigned isolated communities as completely isolated communities.

[0021] S6. Calculate the current predicted load of each shard in the third shard set, normalize the predicted load based on the shard processing capacity parameter to obtain the normalized predicted load, and assign each completely isolated community to the shard with the smallest normalized predicted load to obtain the complete shard set of the target blockchain account.

[0022] S7. Based on the complete set of shards, construct a mapping function between each account node and its corresponding shard, generate an allocation table that corresponds one-to-one between account identifiers and target shard numbers, and perform account state migration based on the allocation table.

[0023] This invention also provides a sharded blockchain account dynamic allocation system based on transaction prediction. The system is implemented based on any of the above-described sharded blockchain account dynamic allocation methods based on transaction prediction. It includes a data acquisition and weighted transaction relationship graph construction module, which is used to acquire historical transaction data of the target blockchain account, divide it into continuous time slice sequences according to a preset time window, and construct a historical weighted transaction relationship graph sequence.

[0024] The time-series transaction relationship prediction module is used to predict transaction relationships based on the historical weighted transaction relationship graph sequence and a time-series transaction prediction model, and generate a predicted transaction relationship graph.

[0025] The core account identification module calculates the transaction activity of each account node according to the predicted transaction relationship graph and sorts the account nodes from high to low transaction activity. It selects a preset number of account nodes as core account nodes, and the remaining account nodes in the predicted transaction relationship graph are non-core account nodes. It then uses each core account node as an initial anchor point to construct the first shard set.

[0026] The affinity allocation module is used to calculate the affinity between non-core account nodes and each initial anchor point according to the predicted transaction relationship graph and the first shard set. Based on the calculated affinity, the non-core account nodes are allocated to the shards where each initial anchor point is located to obtain the second shard set. The remaining unallocated non-core account nodes are recorded as isolated account nodes to construct the isolated account node set.

[0027] The isolated subgraph processing module is used to induce the generation of isolated subgraphs for each isolated account node based on the second shard set and the isolated account node set. Through the community detection algorithm, the isolated subgraphs are clustered to obtain multiple isolated communities. The affinity between each isolated community and each shard in the second shard set is calculated. Based on the calculated affinity, each isolated community is assigned to each shard in the second shard set to obtain the third shard set. The remaining unassigned isolated communities are recorded as completely isolated communities.

[0028] The load assessment and compensation allocation module is used to calculate the current predicted load of each shard in the third shard set, normalize the predicted load based on the shard processing capacity parameters to obtain the normalized predicted load, and allocate each completely isolated community to the shard with the smallest normalized predicted load to obtain the complete shard set of the target blockchain account.

[0029] The mapping publishing and state migration module is used to construct the mapping relationship function between each account node and the corresponding shard based on the complete shard set, generate an allocation table that corresponds one-to-one between account identifiers and target shard numbers, and perform account state migration based on the allocation table.

[0030] A computer-readable storage medium for storing a computer program that, when run on a computer, causes the computer to execute any of the above-mentioned methods for dynamic allocation of sharded blockchain accounts based on transaction prediction.

[0031] An electronic device includes: a memory for storing a computer program; and a processor for executing the computer program to implement a transaction prediction-based sharded blockchain account dynamic allocation method as described above.

[0032] The beneficial effects of this invention are that by modeling and predicting the evolution characteristics of account transaction relationships, transaction structure information for future time periods can be obtained in advance during the account allocation stage, thereby completing the reasonable allocation of accounts before transactions occur, effectively reducing the number of cross-shard transactions, increasing the proportion of transactions within shards, and reducing cross-shard coordination overhead.

[0033] Meanwhile, the account sharding allocation process takes into account the account transaction activity level and shard load status, and combines the differences in shard processing capabilities to impose allocation constraints or compensations, so that the account distribution can adapt to the heterogeneous sharding environment, alleviate local overload and resource idleness, improve the overall system throughput and resource utilization efficiency, and enhance the system's operational stability.

[0034] By identifying the interaction structure characteristics between accounts, the integrity of high-frequency interactive accounts or account groups can be maintained during the account allocation process, reducing continuous cross-shard transactions caused by the splitting of groups, thereby improving the stability and continuous optimization effect of account allocation results.

[0035] When account interactions are sparse or lack effective interaction information, this invention can reasonably allocate relevant accounts or account sets according to the current system load status, ensuring the overall balance of account distribution, so that the system still has good operational stability and robustness under extreme or special transaction structures.

[0036] In summary, by introducing a predictive mechanism for the evolution of account transaction relationships and comprehensively considering the differences in account interaction structure and sharding processing capabilities during the account sharding allocation process, this invention can effectively reduce the number of cross-shard transactions, improve system throughput, improve sharding load balancing in heterogeneous sharded blockchain environments, and enhance the stability and adaptability of account allocation strategies, thus possessing significant engineering application value. Attached Figure Description

[0037] Figure 1 This is a flowchart of a sharded blockchain account dynamic allocation method based on transaction prediction proposed in an embodiment of the present invention.

[0038] Figure 2 This is a schematic diagram of the structure of a sharded blockchain account dynamic allocation system based on transaction prediction proposed in an embodiment of the present invention.

[0039] Figure 3 This is a schematic diagram of the terminal device structure of a sharded blockchain account dynamic allocation method based on transaction prediction proposed in an embodiment of the present invention.

[0040] Figure 4 This is a computer-readable storage medium structure diagram of a sharded blockchain account dynamic allocation method based on transaction prediction proposed in an embodiment of the present invention.

[0041] In the diagram, 200 is the terminal device, 210 is the memory, 211 is the RAM, 212 is the cache memory, 213 is the ROM, 214 is the program / utility, 215 is the program module, 220 is the processor, 230 is the bus, 240 is the external device, 250 is the I / O interface, 260 is the network adapter, and 300 is the program product. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention; that is, the described embodiments are only a part of the embodiments of the invention, and not all of them. The components of the embodiments of the invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0043] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0044] Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or machine that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or machine. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or machine that includes said element.

[0045] The features and performance of the present invention will be further described in detail below with reference to embodiments.

[0046] Example 1:

[0047] like Figure 1 As shown, this embodiment provides a method for dynamic allocation of sharded blockchain accounts based on transaction prediction, including the following steps:

[0048] S1. Obtain historical transaction data of the target blockchain account, divide it into continuous time slice sequences according to preset time windows, and construct a historical weighted transaction relationship graph sequence;

[0049] S2. Based on the historical weighted transaction relationship graph sequence, predict the transaction relationship using a time series transaction prediction model to generate a predicted transaction relationship graph;

[0050] S3. Based on the predicted transaction relationship graph, calculate the transaction activity of each account node and sort the account nodes from high to low according to the transaction activity. Select the account nodes of the preset number of shards as core account nodes, and the remaining account nodes in the predicted transaction relationship graph as non-core account nodes. Use each core account node as the initial anchor point to construct the first shard set.

[0051] S4. Based on the predicted transaction relationship graph and the first shard set, calculate the affinity between non-core account nodes and each initial anchor point, and based on the calculated affinity, assign non-core account nodes to the shards where each initial anchor point is located to obtain the second shard set. Record the remaining unassigned non-core account nodes as isolated account nodes and construct the isolated account node set.

[0052] S5. Based on the second shard set and the isolated account node set, induce the generation of isolated subgraphs for each isolated account node. Through the community detection algorithm, cluster the isolated subgraphs to obtain multiple isolated communities. Calculate the affinity between each isolated community and each shard in the second shard set. Based on the calculated affinity, assign each isolated community to each shard in the second shard set to obtain the third shard set. Record the remaining unassigned isolated communities as completely isolated communities.

[0053] S6. Calculate the current predicted load of each shard in the third shard set, normalize the predicted load based on the shard processing capacity parameter to obtain the normalized predicted load, and assign each completely isolated community to the shard with the smallest normalized predicted load to obtain the complete shard set of the target blockchain account.

[0054] S7. Based on the complete set of shards, construct a mapping function between each account node and its corresponding shard, generate an allocation table that corresponds one-to-one between account identifiers and target shard numbers, and perform account state migration based on the allocation table.

[0055] Furthermore, step S1 includes the following sub-steps:

[0056] S101. Obtain historical transaction data of the target blockchain account in chronological order of transaction time, divide the historical transaction data according to the preset time window, and obtain multiple time slice sequences that advance in time.

[0057] S102. Using accounts as nodes, inter-account transaction behavior as edges, and inter-account transaction count as edge weights, the transaction data within each time slice is abstracted into multiple static weighted transaction relationship graphs and arranged in chronological order to obtain a sequence of historical weighted transaction relationship graphs that can reflect the changes in the historical transaction intensity of blockchain accounts over time.

[0058] Specifically, the implementation principles of the above embodiments and their respective sub-steps are as follows:

[0059] In step S1, transaction records within a specified time range or block height range are retrieved from the blockchain ledger. The transaction sequence is divided into multiple consecutive time slices according to a preset time window, providing an input sequence for subsequent time series modeling. Based on each time slice in step S1, accounts are treated as nodes, and transactions between accounts are treated as edges. The edges are weighted according to the number of transactions to form a weighted transaction relationship graph. The historical weighted transaction relationship graph sequence is obtained in chronological order. Specifically:

[0060] First, transaction records are extracted from the ledger of the target blockchain account in chronological order. The continuous transaction sequence is then divided according to a preset "time slice": the entire data is divided into N discrete time periods, each time period corresponds to a fixed-length interval, and continuous blocks are grouped at fixed intervals (e.g., every 10,000 blocks as a group), thus obtaining a continuous sequence of transaction segments that progresses over time, laying the foundation for the next step of constructing a transaction relationship graph sequence.

[0061] Then, based on the obtained consecutive time slices, each time slice is... The transaction data within is abstracted into a static weighted transaction relationship graph. ), and form a sequence of graphs in chronological order. Each of them Corresponding to the A set of transactions that occur within a single time slice. ,definition ,in, This represents the set of transaction account nodes that appeared within that time slice. This represents the set of transaction edges between account nodes that have appeared within this time slice. This represents the transaction edge weight function between account nodes that have appeared within this time slice. If the transaction account... With trading account If at least one transaction occurs within that time slice, then... China establishes border The transaction edge weight function is then expressed as: Used to characterize the intensity of interaction between accounts, among which Let represent a real number greater than 0, and denote the edge weight as . , From that time frame and The number of transactions between them was obtained;

[0062] The final result is a weighted transaction relationship sequence that reflects the evolution of historical interaction intensity over time.

[0063] Furthermore, step S2 includes the following sub-steps:

[0064] S201. Using the historical weighted transaction relationship diagram sequence as input, establish alignment matrices for the historical weighted transaction relationship diagrams corresponding to adjacent time slices, and identify the status information of the same account in different time slices;

[0065] S202. Based on the time series transaction prediction model, perform structural aggregation on the nodes in each time slice, and use normalized message passing to obtain the node feature representation after structural aggregation;

[0066] S203. Based on the gated cyclic unit and the alignment matrix, the node feature representation across time slices is updated temporally to obtain the temporal embedded representation of the node;

[0067] S204. Based on the temporal embedding representation of the nodes, the embedding distance between nodes is calculated by an adaptive embedding aggregation algorithm, and the weights of the predicted transaction edges are generated according to the embedding distance to construct a predicted transaction relationship graph containing the predicted edge weights.

[0068] Specifically, the implementation principles of the above embodiments and their respective sub-steps are as follows:

[0069] In step S2, the historical weighted transaction relationship graph sequence is input into the time series transaction prediction model, and the predicted transaction relationship graph for the next time slice is output, obtaining the predicted account interaction edges and their corresponding weights. Specifically:

[0070] First, based on the weighted transaction relationship graph sequence, a time series transaction prediction model is used to infer the transaction relationships for the next time slice, assuming the historical observation window length is... For any time ( Take the nearest one. Weighted transaction relationship diagram As input, the time series transaction prediction model outputs the predicted weighted adjacency matrix for the next time slice. Based on this, a predictive transaction relationship diagram is constructed. ,in, For predicting the set of accounts, For the set of predicted edges, Let be the edge weight function for prediction, for any predicted edge The predicted edge weights satisfy: Where i and j represent any account within the prediction account set, This represents the prediction edge weight function. Indicates the predicted edge weights;

[0071] To address the inconsistency of nodes caused by changes in account sets across different time slices, an alignment matrix for the adjacent weighted transaction relationship graph is first established. ,in Represents the alignment matrix. This represents the total number of accounts within time slice t. This indicates the total number of accounts within the next time frame. With account If they are the same address, then let Otherwise .

[0072] Then, the time series transaction prediction model alternates between spatial aggregation and temporal updates within each time slice, based on a weighted adjacency matrix. Nodes are structurally aggregated and obtained using normalized message passing:

[0073] ; ;in This represents the result of spatial feature aggregation at the k-th layer. Represents the self-loop adjacency matrix. Represents the identity matrix. This is the degree matrix. For the first Hidden representation of nodes in the layer, Indicates the first The layer's weight parameter matrix, Represents a non-linear activation function. Represents a graph neural network;

[0074] Next, cross-temporal dependencies are modeled using gated recurrent units, and combined with the aligned historical state update temporal hidden representation: ; ;in, This represents the spacetime hiding representation at the k-th layer. This represents the k-th layer of the spacetime hidden representation of the previous time slice. Indicates a gated loop unit. This indicates the hidden state of the previous time slice after alignment. This represents the alignment matrix of the previous time slice. Indicates time slice The node attribute characteristics, This represents the node attribute characteristics of the previous time slice. For attention-based auxiliary alignment matrix, As a weighting factor, This represents the matrix transpose operation, used to convert the alignment mapping direction from the previous time slice node to the current time slice node into a weighted aggregation form of the current node's hidden state of historical nodes.

[0075] Then, the aforementioned spacetime units are stacked. The final timing embedding is obtained after the layer. , is represented as: Based on this, an adaptive embedding aggregation mechanism is used to restore the node embeddings to the predicted adjacency matrix, let: , ; ;in, This represents the source node embedding matrix, used to represent the potential representation of a node as a transaction initiator. This represents the target node embedding matrix, used to represent the potential representation of a node as a transaction receiver. The source role represents the mapping network. The target role represents the mapping network. Let represent the inner product of node i and node j in the source embedding space, used to control the "distance sensitivity" between different node pairs. Then, the predicted edge weight is generated by the embedding distance between nodes, expressed as: ;in, Represents an exponential function. This represents the target embedding vector of node i in time slice t. This represents the target embedding vector of node j in time slice t, thus obtaining an estimate of the strength of transactions for any account pair in the next time slice. Specifically, "adaptive" means that the embedding vector and mapping network parameters are automatically learned through model training, rather than by manually setting fixed rules. Regarding the specific implementation of the "adaptive embedding aggregation algorithm," after completing spatial structure aggregation and time updates, the final temporal embedding representation of the node is obtained. And through mapping network , The embeddings are transformed, and then predicted edge weights are generated based on the Euclidean distance between the embedding vectors of the nodes.

[0076] Specifically, the embedding vectors are obtained by: performing structural aggregation through a graph neural network and updating the time through a gated recurrent unit; the distance between the embedding vectors is calculated by: squared Euclidean distance; the mapping function from distance to predicted edge weights is in the form of an exponential decay function.

[0077] Finally, according to Construct the set of predicted edges ,like Then it is believed that the next time in the film and There exists a predictive transaction relationship, in which, This represents a pre-set threshold for predicting edge weights, used to sparsify the predicted adjacency matrix. The value range is (0,1), and its value is determined based on the statistical distribution of historical data of the target blockchain account or through cross-validation to control the structural sparsity and noise level of the predicted transaction relationship graph. As a predictor of interaction strength, a predictive transaction relationship graph is ultimately formed. This serves as the input for subsequent modules.

[0078] Furthermore, step S3 includes the following sub-steps:

[0079] S301. Based on the predicted transaction relationship graph, calculate the sum of the predicted edge weights of all adjacent edges of each account node, and use this as the transaction activity of the account;

[0080] S302. Sort all account nodes from high to low according to transaction activity, select the corresponding number of account nodes according to the preset number of shards, and construct a core account node set;

[0081] S303. Take each account node in the core account node set as an initial anchor point, and perform sharding initialization on each initial anchor point to obtain the first shard set.

[0082] Specifically, the implementation principles of the above embodiments and their respective sub-steps are as follows:

[0083] In the obtained predictive transaction relationship diagram Core account identification was carried out. For a set of accounts (nodes), To predict the set of interaction edges, is the edge weight function, used to characterize the strength of predicted interactions between accounts. To depict the trading activity of an account in the next time slice, for any account... Define its trading activity It is the sum of the weights of its adjacent edges: ;in for The set of neighboring accounts For predicted transaction weights. Calculate the weights for all accounts. Then, sort by trading activity from highest to lowest, and select the top [number] with the highest trading activity. These accounts constitute the core account set. ,in This represents the total number of system fragments.

[0084] Then, the sharding anchor initialization operation is performed, which involves each core account... Specify an initial anchor point for a different shard to form an initial set of shards. and order This yields the initial set of fragments upon which subsequent affinity assignments depend.

[0085] Furthermore, step S4 includes the following sub-steps:

[0086] S401. Based on the predicted transaction relationship graph and the first shard set, determine whether there are direct predicted edges between each non-core account node and each initial anchor point;

[0087] S402. If they exist, calculate the predicted connection weights between each non-core account node and each initial anchor point, and use them as the affinity between each non-core account node and each initial anchor point; if they do not exist, mark the current non-core account node as an isolated account node and construct a set of isolated account nodes.

[0088] S403. Based on the calculated affinity, using the highest affinity as the basis, assign each non-core account node to the shard containing the initial anchor point with the highest affinity, and update the first shard set to obtain the second shard set.

[0089] Specifically, the implementation principles of the above embodiments and their respective sub-steps are as follows:

[0090] Based on predictive transaction relationship graph With core account set (each of which) It is a fragment. (anchor point) for all non-core accounts The allocation will be carried out one by one.

[0091] First, calculate the non-core accounts. Predicted connection weights between each anchor account If account There is no directly predicted edge with any anchor point (i.e., for all...) All have If so, it will be temporarily stored in the orphanage collection. This will be processed in step 6. Otherwise, following the maximum affinity principle, it will be assigned to the shard containing the anchor point with the highest prediction weight. The specific allocation logic determines the shard index using the following formula. , is represented as: ;

[0092] Determine the index Then, perform a shard set update. This prioritizes aggregating ordinary accounts into the core areas where they interact most frequently, thereby improving the locality of transactions within a shard and reducing cross-shard dependencies.

[0093] Furthermore, step S5 includes the following sub-steps:

[0094] S501. Based on the set of isolated account nodes, induce the generation of isolated subgraphs for each isolated account node, and cluster each isolated subgraph according to the community detection algorithm to obtain multiple isolated communities;

[0095] S502. Determine whether each isolated community and each segment within the second segment set have predicted edges;

[0096] S503. If it exists, calculate the total connection strength between each isolated community and each fragment in the second fragment set; if it does not exist, mark the current sub-community set as a completely isolated community.

[0097] S504. Based on the total connection strength, each isolated community is assigned to the shard with the largest total connection strength, and the second shard set is updated to obtain the third shard set.

[0098] Specifically, the implementation principles of the above embodiments and their respective sub-steps are as follows:

[0099] After the maximum affinity assignment is completed, accounts that do not have a direct predictive link to any anchor account are grouped into the orphan account set. .

[0100] To avoid random allocation disrupting the cohesive structure between accounts, this step employs a holistic allocation strategy. First, in the predicted transaction relationship graph... Above, targeting Induced generation of solitary subgraphs ,in For the original edge set Both endpoints belong to The set of edges. Then in The algorithm performs a community detection process to cluster isolated accounts with close internal transaction relationships into several sub-communities. and each sub-community This will be used as the smallest unit of allocation for shard selection. For each sub-community... Calculate its relationship with the currently formed fragments. Total connection strength between : ;in To predict edge weights.

[0101] Then, the target fragment is selected according to the principle of maximizing intensity. : ; and the target is fragmented Perform a full merge update: .

[0102] For a very small number of pieces that have no connection to any fragment ( The sub-communities of ) are marked as completely isolated communities in this step.

[0103] Furthermore, step S6 includes the following sub-steps:

[0104] S601. Based on the third shard set, calculate the transaction activity of all accounts in each shard and sum them to obtain the current predicted load of each shard;

[0105] S602. Based on the sharding processing capability parameters, normalize the current predicted load of each shard to obtain the current normalized load of each shard;

[0106] S603. Select the shard with the minimum normalized load as the target shard, assign each completely isolated community to the target shard, and update the third shard set to obtain the complete shard set of the target blockchain account.

[0107] Furthermore, when the sharding processing capacity parameters of each shard are the same, the shard with the lowest absolute predictive load is selected as the target shard, each completely isolated community is assigned to the target shard, and the third shard set is updated to obtain the complete shard set of the target blockchain account.

[0108] Specifically, the implementation principles of the above embodiments and their respective sub-steps are as follows:

[0109] For communities marked as "completely isolated" in step 6 A load balancing compensation strategy is used for allocation: first, the predicted load of each shard is calculated. It is defined as the sum of the predicted activity of all accounts within a shard: ;in, For account Predicted activity To predict edge weights in the transaction graph, and to adapt to heterogeneous sharding environments, pre-set sharding processing capability parameters based on the data processing capabilities of each shard are introduced. Define the normalized load for the shards. : Then, the fragment with the minimum normalized load is selected as the target fragment: And perform the update: Specifically, the parameters for fragmentation processing capability. This parameter reflects the differences in computing and transaction processing capabilities among different shards in a real-world operating environment. It is determined based on the number of nodes within the shard, hardware performance configuration, and the historical maximum number of transactions processed per unit time. In simulation environments, this parameter can be used as input for system initialization configuration to simulate the heterogeneous resource distribution in real-world blockchain networks.

[0110] When each partition has the same processing capacity (i.e.) When taking the same constant, and Since the ordering is completely consistent, the above rule naturally degenerates into "selecting the shard with the smallest absolute load" for compensation. This ensures that a unified allocation criterion is used in both homogeneous and heterogeneous scenarios, suppressing load imbalance and improving system stability.

[0111] Furthermore, in step S7, the final shard set is obtained. Then, the allocation results are solidified into an account-shard mapping function. For any account ,like Then record This generates an allocation table of "Account Identifier - Target Shard Number" as a guiding strategy for the next runtime segment. The new mapping will then be... With current network mapping By comparing data, accounts that need to be moved across regions are identified, and a migration list is generated. The status migration is performed on the accounts in the list, that is, the data such as their account balance and contract status are transferred from the source shard to the target shard.

[0112] Example 2

[0113] like Figure 2 As shown, as a preferred embodiment of the above embodiments, a sharded blockchain account dynamic allocation system based on transaction prediction is provided. This system is implemented based on any of the transaction prediction-based sharded blockchain account dynamic allocation methods described above, including...

[0114] The data acquisition and weighted transaction relationship graph construction module is used to acquire historical transaction data of the target blockchain account, divide it into continuous time slice sequences according to preset time windows, and construct a historical weighted transaction relationship graph sequence.

[0115] The time-series transaction relationship prediction module is used to predict transaction relationships based on the historical weighted transaction relationship graph sequence and a time-series transaction prediction model, and generate a predicted transaction relationship graph.

[0116] The core account identification module calculates the transaction activity of each account node according to the predicted transaction relationship graph and sorts the account nodes from high to low transaction activity. It selects a preset number of account nodes as core account nodes, and the remaining account nodes in the predicted transaction relationship graph are non-core account nodes. It then uses each core account node as an initial anchor point to construct the first shard set.

[0117] The affinity allocation module is used to calculate the affinity between non-core account nodes and each initial anchor point according to the predicted transaction relationship graph and the first shard set. Based on the calculated affinity, the non-core account nodes are allocated to the shards where each initial anchor point is located to obtain the second shard set. The remaining unallocated non-core account nodes are recorded as isolated account nodes to construct the isolated account node set.

[0118] The isolated subgraph processing module is used to induce the generation of isolated subgraphs for each isolated account node based on the second shard set and the isolated account node set. Through the community detection algorithm, the isolated subgraphs are clustered to obtain multiple isolated communities. The affinity between each isolated community and each shard in the second shard set is calculated. Based on the calculated affinity, each isolated community is assigned to each shard in the second shard set to obtain the third shard set. The remaining unassigned isolated communities are recorded as completely isolated communities.

[0119] The load assessment and compensation allocation module is used to calculate the current predicted load of each shard in the third shard set, normalize the predicted load based on the shard processing capacity parameters to obtain the normalized predicted load, and allocate each completely isolated community to the shard with the smallest normalized predicted load to obtain the complete shard set of the target blockchain account.

[0120] The mapping publishing and state migration module is used to construct the mapping relationship function between each account node and the corresponding shard based on the complete shard set, generate an allocation table that corresponds one-to-one between account identifiers and target shard numbers, and perform account state migration based on the allocation table.

[0121] Specifically, the system's workflow is as follows:

[0122] First, the system retrieves historical transaction records from the target blockchain ledger using a data acquisition and weighted transaction graph construction module, and then divides this continuous transaction data into a series of time slices according to a preset time window. For each time slice, the system abstracts accounts as nodes and transaction behaviors as edges, and uses transaction frequency as edge weights to construct a series of weighted transaction graph sequences that reflect historical interaction states.

[0123] Then, the time-series transaction relationship prediction module receives the above graph sequence as input. This module utilizes a built-in time-series transaction prediction model (such as a spatiotemporal graph neural network) to deeply analyze the spatiotemporal evolution characteristics of account interactions in historical data, inferring possible transaction behaviors within the next time slice. The output is a "predicted transaction relationship graph" containing predicted edges and their weights, thus achieving a forward-looking prediction of future transaction structures.

[0124] Next, the core account identification module performs analysis based on the predicted transaction relationship graph. The system calculates the predicted transaction activity (i.e., the sum of predicted edge weights) of each account node in the graph and sorts them from high to low activity. Several top-ranked accounts (the number equal to the total number of shards) are selected as "core accounts" and initialized as "initial anchors" for different shards, thereby constructing a first set of shards containing only anchors.

[0125] Next, the affinity allocation module begins processing the remaining non-core accounts. The system calculates the affinity (i.e., predicted connection strength) between each non-core account and each initial anchor point. Based on the "maximum affinity principle," these accounts are assigned to the shard containing the anchor point with the highest affinity, forming a second set of shards containing the assigned accounts. For accounts that have no direct predicted connection to any anchor point, the system marks them as orphaned accounts and adds them to the orphaned account node set.

[0126] Subsequently, the isolated subgraph processing module intervenes to handle these difficult-to-assign "scattered accounts." The module extracts the subgraph structure induced by the set of isolated account nodes and runs a community detection algorithm to cluster closely connected isolated accounts into several "isolated communities." Then, the system calculates the total affinity of each isolated community as a whole with all partitions in the second partition set, and assigns the community as a whole to the target partition with the highest affinity, thus updating the third partition set. At this point, communities whose affiliation remains uncertain are marked as "completely isolated communities."

[0127] Next, the load assessment and compensation allocation module performs the final fallback allocation. The system calculates the current predicted total load for each shard in the third shard set and normalizes it based on the hardware processing capability parameters of each shard to obtain a "normalized predicted load" that reflects the actual pressure. To balance system pressure, the system forcibly allocates the remaining completely isolated communities to the shard with the lowest current normalized load, thereby generating a complete shard set covering all accounts.

[0128] Finally, the mapping publication and state transition module solidifies the final sharding result into a mapping function, generates an allocation table containing "account identifier - target shard number", and publishes it externally. Simultaneously, the system compares the old and new allocation tables, identifies accounts that have changed their shard affiliation, and performs cross-shard state transition operations to ensure the blockchain system operates according to the optimized strategy in the new time period.

[0129] Example 3

[0130] Based on Example 1, there is a practical application scenario for dynamically allocating target blockchain accounts in shards. This scenario employs a sharded blockchain account dynamic allocation method based on transaction prediction as described in the above examples, specifically including the following steps:

[0131] First, initialize the implementation environment and set the parameters:

[0132] Total number of fragments: The fragmented set is ;

[0133] Time slice division method: grouped by fixed intervals between consecutive blocks (e.g., every 10,000 blocks as a group);

[0134] Edge weight definition: The edge weight of a transaction graph is defined as the number of transactions.

[0135] Fragmentation processing capability parameters: Historical observation window length: This means using the three most recent time slices to predict the next time slice.

[0136] Then, data acquisition and historical graph sequence construction are performed:

[0137] The transaction record fields (sender account, receiver account, block height / time, transaction strength index) are extracted from the blockchain ledger and deduplicated and formatted; the time slice segmentation module divides the transaction sequence into 3 consecutive time slices. The weighted transaction relationship graph construction module constructs a graph for each time slice. Construct a weighted transaction relationship diagram In this embodiment, edge weights Take the time slice and The number of transactions between them;

[0138] The following is a summary of sample transactions:

[0139] Time slice ( ): ;

[0140] Time slice ( ): ;

[0141] Time slice ( ): ;

[0142] Based on this, a historical weighted transaction relationship sequence is obtained. .

[0143] Next, a predictive transaction relationship graph is generated:

[0144] The time-based transaction relationship prediction module will Input the model, output the predicted weighted adjacency matrix for the next time slice. And construct a predictive transaction relationship diagram. ;

[0145] Let the predicted edges and edge weights be:

[0146] ;in edge set The above is the set of predicted edges;

[0147] Next, core account identification and sharding anchor initialization are performed:

[0148] The core account identification module in the prediction graph Calculate the predicted activity of the account ; ; ; ; ;(the remaining: Select from highest to lowest activity level Individual accounts form the core account set: ;

[0149] Perform anchor point initialization: .

[0150] Then, affinity allocation is performed:

[0151] For non-core accounts Distribute:

[0152] : with anchor point Side weight 2, and Edge weight 1, based on maximum affinity ;

[0153] : with anchor point Side weight 3 ;

[0154] : with anchor point Side weight 2 ;

[0155] : with anchor point Side weight 2 ;

[0156] , There is no directly predicted edge with any anchor point. Into ;

[0157] Current preliminary sharding: .

[0158] Next, isolated subgraph community discovery and overall allocation are performed:

[0159] The isolated subgraph processing module in Upper construction inducible graph Due to the existence of prediction edges Execute community discovery to obtain community ;

[0160] Calculate connection strength :because Since there are no predicted edges between the existing sharded accounts and all have a strength of 0, it is marked as a "completely isolated community".

[0161] Next, heterogeneous load balancing compensation and allocation are performed:

[0162] The load assessment and heterogeneous compensation module calculates the predicted load for each shard. :

[0163] ;

[0164] ;

[0165] ;

[0166] ;

[0167] Calculate normalized load :

[0168] ;

[0169] ;

[0170] (Minimum);

[0171] ;

[0172] Will Compensation is allocated to the area with the smallest normalized load. ,renew: .

[0173] Finally, perform the mapping output:

[0174] The mapping publication and state transition control module outputs the final account-fragment mapping function. :

[0175] Fragment 1 ( ): ;

[0176] Fragment 2 ( ): ;

[0177] Part 3 ( ): ;

[0178] Part 4 ( ): ;

[0179] Furthermore, the new mapping With current network mapping Compare and generate a migration list. : ;

[0180] Assuming the mapping state at the current moment for: ; ;

[0181] A migration list was derived through comparison. The system generates migration tasks based on this, and ultimately... The balance, contract status, and other status data of each account are migrated from their source shard to the target shard, and the routing mapping is updated synchronously to complete the shard reconfiguration.

[0182] Example 4

[0183] like Figure 3 As shown, this embodiment proposes a terminal device 200 for a sharded blockchain account dynamic allocation method based on transaction prediction. The terminal device 200 includes at least one memory 210, at least one processor 220, and a bus 230 connecting different platform systems.

[0184] The memory 210 may include a readable medium in the form of volatile memory, such as RAM 211 and / or cache memory 212, and may further include ROM 213.

[0185] The memory 210 also stores a computer program that can be executed by the processor 220, causing the processor 220 to execute any of the above-described transaction prediction-based sharded blockchain account dynamic allocation methods in this application embodiment. The specific implementation and technical effects are consistent with those described in the embodiments of the above methods, and some details will not be repeated here. The memory 210 may also include a program / utility 214 having a set (at least one) of program modules 215. Such program modules 215 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment.

[0186] Accordingly, processor 220 can execute the aforementioned computer program, as well as executable program / utility 214.

[0187] Bus 230 can represent one or more of several types of bus structures, including a memory bus or memory controller, peripheral bus, graphics acceleration port, processor, or a local bus using any of the various bus structures.

[0188] Terminal device 200 can also communicate with one or more external devices 240, such as keyboards, pointing devices, Bluetooth devices, etc., and with one or more devices capable of interacting with it, and / or with any device that enables it to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be performed via I / O interface 250. Furthermore, terminal device 200 can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapter 260. Network adapter 260 can communicate with other modules of terminal device 200 via bus 230. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with terminal device 200, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0189] Example 5

[0190] like Figure 4 As shown, based on Embodiment 1, this embodiment proposes a computer-readable storage medium for a transaction-prediction-based dynamic allocation method for sharded blockchain accounts. The computer-readable storage medium stores instructions that, when executed by a processor, implement any of the aforementioned transaction-prediction-based dynamic allocation methods for sharded blockchain accounts. Its specific implementation method and the achieved technical effects are consistent with those described in the embodiments of the above methods, and some details will not be repeated.

[0191] This embodiment provides a program product 300 for implementing the above-described method, which may employ a portable compact disc read-only memory (CD-ROM) and include program code, and can run on a terminal device, such as a personal computer. However, the program product 300 of the present invention is not limited thereto. In this embodiment, the readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. The program product 300 may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0192] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on a user computing device, partially on a user device, as a standalone software package, partially on a user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing devices can be connected to user computing devices via any type of network, including local area networks (LANs) or wide area networks (WANs), or they can be connected to external computing devices (e.g., via the Internet through an Internet service provider).

[0193] This invention is described from the perspectives of its intended use, effectiveness, progress, and novelty. Its practical and progressive features meet the functional enhancement and use requirements emphasized by the Patent Law. The above description and drawings are merely preferred embodiments of this application and are not intended to limit this application. Therefore, all structures, devices, features, etc., that are similar to or identical to those of this application, i.e., all equivalent substitutions or modifications made in accordance with the scope of this patent application, shall fall within the scope of protection of this patent application.

[0194] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for dynamic allocation of sharded blockchain accounts based on transaction prediction, characterized in that, Includes the following steps: S1. Obtain historical transaction data of the target blockchain account, divide it into continuous time slice sequences according to preset time windows, and construct a historical weighted transaction relationship graph sequence; S2. Based on the historical weighted transaction relationship graph sequence, predict the transaction relationship using a time series transaction prediction model to generate a predicted transaction relationship graph; S3. Based on the predicted transaction relationship graph, calculate the transaction activity of each account node and sort the account nodes from high to low according to the transaction activity. Select the account nodes of the preset number of shards as core account nodes, and the remaining account nodes in the predicted transaction relationship graph as non-core account nodes. Use each core account node as the initial anchor point to construct the first shard set. S4. Based on the predicted transaction relationship graph and the first shard set, calculate the affinity between non-core account nodes and each initial anchor point, and based on the calculated affinity, assign non-core account nodes to the shards where each initial anchor point is located to obtain the second shard set. Record the remaining unassigned non-core account nodes as isolated account nodes and construct the isolated account node set. S5. Based on the second shard set and the isolated account node set, induce the generation of isolated subgraphs for each isolated account node. Through the community detection algorithm, cluster the isolated subgraphs to obtain multiple isolated communities. Calculate the affinity between each isolated community and each shard in the second shard set. Based on the calculated affinity, assign each isolated community to each shard in the second shard set to obtain the third shard set. Record the remaining unassigned isolated communities as completely isolated communities. S6. Calculate the current predicted load of each shard in the third shard set, normalize the predicted load based on the shard processing capacity parameter to obtain the normalized predicted load, and assign each completely isolated community to the shard with the smallest normalized predicted load to obtain the complete shard set of the target blockchain account. S7. Based on the complete set of shards, construct a mapping function between each account node and its corresponding shard, generate an allocation table that corresponds one-to-one between account identifiers and target shard numbers, and perform account state migration based on the allocation table; Step S2 includes the following sub-steps: S201. Using the historical weighted transaction relationship diagram sequence as input, establish alignment matrices for the historical weighted transaction relationship diagrams corresponding to adjacent time slices, and identify the status information of the same account in different time slices; S202. Based on the time series transaction prediction model, perform structural aggregation on the nodes in each time slice, and use normalized message passing to obtain the node feature representation after structural aggregation; S203. Based on the gated cyclic unit and the alignment matrix, the node feature representation across time slices is updated temporally to obtain the temporal embedded representation of the node; S204. Based on the temporal embedding representation of the nodes, the embedding distance between nodes is calculated by an adaptive embedding aggregation algorithm, and the weights of the predicted transaction edges are generated according to the embedding distance to construct a predicted transaction relationship graph containing the predicted edge weights.

2. The method for dynamic allocation of sharded blockchain accounts based on transaction prediction according to claim 1, characterized in that, Step S1 includes the following sub-steps: S101. Obtain historical transaction data of the target blockchain account in chronological order of transaction time, divide the historical transaction data according to the preset time window, and obtain multiple time slice sequences that advance in time. S102. Using accounts as nodes, inter-account transaction behavior as edges, and inter-account transaction count as edge weights, the transaction data within each time slice is abstracted into multiple static weighted transaction relationship graphs and arranged in chronological order to obtain a sequence of historical weighted transaction relationship graphs that can reflect the changes in the historical transaction intensity of blockchain accounts over time.

3. The method for dynamic allocation of sharded blockchain accounts based on transaction prediction according to claim 1, characterized in that, Step S3 includes the following sub-steps: S301. Based on the predicted transaction relationship graph, calculate the sum of the predicted edge weights of all adjacent edges of each account node, and use this as the transaction activity of the account; S302. Sort all account nodes from high to low according to transaction activity, select the corresponding number of account nodes according to the preset number of shards, and construct a core account node set; S303. Take each account node in the core account node set as an initial anchor point, and perform sharding initialization on each initial anchor point to obtain the first shard set.

4. The method for dynamic allocation of sharded blockchain accounts based on transaction prediction according to claim 1, characterized in that, Step S4 includes the following sub-steps: S401. Based on the predicted transaction relationship graph and the first shard set, determine whether there are direct predicted edges between each non-core account node and each initial anchor point; S402. If it exists, calculate the predicted connection weight between each non-core account node and each initial anchor point, and use it as the affinity between each non-core account node and each initial anchor point. If it does not exist, mark the current non-core account node as an orphan account node and construct a set of orphan account nodes; S403. Based on the calculated affinity, using the highest affinity as the basis, assign each non-core account node to the shard containing the initial anchor point with the highest affinity, and update the first shard set to obtain the second shard set.

5. The method for dynamic allocation of sharded blockchain accounts based on transaction prediction according to claim 1, characterized in that, Step S5 includes the following sub-steps: S501. Based on the set of isolated account nodes, induce the generation of isolated subgraphs for each isolated account node, and cluster each isolated subgraph according to the community detection algorithm to obtain multiple isolated communities; S502. Determine whether each isolated community and each segment within the second segment set have predicted edges; S503. If it exists, calculate the total connection strength between each isolated community and each fragment in the second fragment set; If it does not exist, mark the current set of sub-communities as a completely isolated community; S504. Based on the total connection strength, each isolated community is assigned to the shard with the largest total connection strength, and the second shard set is updated to obtain the third shard set.

6. The method for dynamic allocation of sharded blockchain accounts based on transaction prediction according to claim 1, characterized in that, Step S6 includes the following sub-steps: S601. Based on the third shard set, calculate the transaction activity of all accounts in each shard and sum them to obtain the current predicted load of each shard; S602. Based on the sharding processing capability parameters, normalize the current predicted load of each shard to obtain the current normalized load of each shard; S603. Select the shard with the minimum normalized load as the target shard, assign each completely isolated community to the target shard, and update the third shard set to obtain the complete shard set of the target blockchain account.

7. The method for dynamic allocation of sharded blockchain accounts based on transaction prediction according to claim 6, characterized in that, When the sharding processing capacity parameters of each shard are the same, the shard with the lowest absolute predictive load is selected as the target shard. Each completely isolated community is assigned to the target shard, and the third shard set is updated to obtain the complete shard set of the target blockchain account.

8. A sharded blockchain account dynamic allocation system based on transaction prediction, the system being implemented based on the sharded blockchain account dynamic allocation method based on transaction prediction as described in any one of claims 1-7, characterized in that, include: The data acquisition and weighted transaction relationship graph construction module is used to acquire historical transaction data of the target blockchain account, divide it into continuous time slice sequences according to preset time windows, and construct a historical weighted transaction relationship graph sequence. The time-series transaction relationship prediction module is used to predict transaction relationships based on the historical weighted transaction relationship graph sequence and a time-series transaction prediction model, and generate a predicted transaction relationship graph. The core account identification module calculates the transaction activity of each account node according to the predicted transaction relationship graph and sorts the account nodes from high to low transaction activity. It selects a preset number of account nodes as core account nodes, and the remaining account nodes in the predicted transaction relationship graph are non-core account nodes. It then uses each core account node as an initial anchor point to construct the first shard set. The affinity allocation module is used to calculate the affinity between non-core account nodes and each initial anchor point according to the predicted transaction relationship graph and the first shard set. Based on the calculated affinity, the non-core account nodes are allocated to the shards where each initial anchor point is located to obtain the second shard set. The remaining unallocated non-core account nodes are recorded as isolated account nodes to construct the isolated account node set. The isolated subgraph processing module is used to induce the generation of isolated subgraphs for each isolated account node based on the second shard set and the isolated account node set. Through the community detection algorithm, the isolated subgraphs are clustered to obtain multiple isolated communities. The affinity between each isolated community and each shard in the second shard set is calculated. Based on the calculated affinity, each isolated community is assigned to each shard in the second shard set to obtain the third shard set. The remaining unassigned isolated communities are recorded as completely isolated communities. The load assessment and compensation allocation module is used to calculate the current predicted load of each shard in the third shard set, normalize the predicted load based on the shard processing capacity parameters to obtain the normalized predicted load, and allocate each completely isolated community to the shard with the smallest normalized predicted load to obtain the complete shard set of the target blockchain account. The mapping publishing and state migration module is used to construct the mapping relationship function between each account node and the corresponding shard based on the complete shard set, generate an allocation table that corresponds one-to-one between account identifiers and target shard numbers, and perform account state migration based on the allocation table.

Images