Account partitioning method and device for block chain

Abstract

The invention provides an account partitioning method and device for a block chain, and the method and device can achieve the dynamic partitioning based on the historical data of an account, so as to improve the partitioning reasonability and accuracy. The account partitioning method of the block chain comprises the following steps: constructing a weighted undirected graph of a block chain transaction based on a snapshot graph and a time sequence graph of the block chain transaction; based on the weighted undirected graph, exporting an account partition result for each snapshot graph; identifying a stable account and an unstable account based on the account partitioning result; acquiring historical transaction data of the stable account and the unstable account; determining a stable partition based on historical transaction data of the stable account; establishing a partition prediction model of the unstable account based on the historical transaction data of the unstable account and the stable partition; and based on the partition prediction model of the unstable account and the transaction data of the unstable account, obtaining the partition affiliation of the unstable account in the future time period.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain account partitioning method and device. Background Art

[0002] Blockchains ensure data security and consistency through full replication and consensus protocols without relying on trusted third parties. However, their design significantly constrains the system's scalability. Therefore, state partitioning has been proposed in blockchain technology. This approach aims to divide a complete blockchain network into multiple independent partitions, each of which maintains only a subset of accounts and their associated state, enabling parallel transaction processing and improving overall throughput. However, state partitioning also introduces the problem of cross-partition transactions. Because each partition only maintains a subset of accounts, transactions involving accounts in different partitions require cross-partition transactions, significantly increasing transaction processing complexity, incurring additional communication overhead and verification costs, and reducing system throughput. To alleviate the performance bottlenecks caused by cross-partition transactions, existing research has proposed account allocation methods based on graph theory. The basic idea is to construct historical transaction data as a blockchain account graph. Using a graph partitioning algorithm, accounts with frequent interactions are clustered into the same partition, thereby reducing cross-partition transactions. However, these methods uniformly construct historical transaction data as a static graph. By applying the graph partitioning method to historical data and directly applying the partitioning results to future phases of the system, they ignore the changes in transaction relationships between system accounts, resulting in significant discrepancies between the actual results and the intended results. Summary of the Invention

[0003] To address the above technical issues, the present invention is proposed. Embodiments of the present invention provide a blockchain account partitioning method and apparatus that can dynamically partition accounts based on historical account data to improve partitioning rationality and accuracy.

[0004] According to one aspect of the present invention, a method for account partitioning of a blockchain is provided, comprising: constructing a weighted undirected graph of blockchain transactions based on a snapshot graph and a time sequence graph of blockchain transactions; wherein the snapshot graph represents an account transaction relationship within a specified time period; deriving an account partitioning result for each snapshot graph based on the weighted undirected graph; identifying stable accounts and unstable accounts based on the account partitioning result; obtaining historical transaction data of stable accounts and unstable accounts; determining a stable partition based on the historical transaction data of the stable account, and using the stable partition as the partition affiliation of the stable account in a future time period; establishing a partition prediction model for the unstable account based on the historical transaction data of the unstable account and the stable partition; obtaining the partition affiliation of the unstable account in a future time period based on the partition prediction model and the transaction data of the unstable account, so as to determine the partition affiliation of the unstable account in the future time period.

[0005] In one embodiment, based on the account partitioning result, stable accounts and unstable accounts are identified, including: calculating the partition stability of each account based on the account partitioning result; when the partition stability of the account is greater than or equal to a preset stability threshold, determining that the account is a stable account; when the partition stability of the account is less than the preset stability threshold, determining that the account is an unstable account.

[0006] In one embodiment, based on the account partitioning result, the partition stability of each account is calculated, including: traversing the partitions to which the account belongs at different times, and calculating the number of times the account appears in each partition; determining the partition in which the account appears the most times as the belonging partition; based on the number of times the account is assigned to the partition and the number of times the account is assigned to the belonging partition, calculating the belonging ratio of the account assigned to the belonging partition; and using the belonging ratio as the partition stability of the account.

[0007] In one embodiment, a partition prediction model for unstable accounts is established based on historical transaction data of unstable accounts, including: constructing a label tensor for the partition prediction model for unstable accounts based on the category of stable partitions described by the accounts; dividing the historical transaction data of unstable accounts into multiple subsequences through a sliding window technology; wherein each subsequence represents the transaction behavior of the unstable account within a time window, each time window consists of multiple time steps, and each time step includes multidimensional data features of the unstable account; and constructing an input tensor for the partition prediction model for unstable accounts based on the number of unstable accounts and the subsequences of the unstable accounts.

[0008] In one embodiment, a partition prediction model for unstable accounts is established based on historical transaction data of unstable accounts, and the method further includes: constructing a feature matrix based on the input tensor of the partition prediction model; constructing key features based on the relationship between unstable accounts and stable partitions; merging the key features into the feature matrix to construct a multi-dimensional matrix; and using the multi-dimensional matrix as a test data set and a training data set for the partition prediction model to train the partition prediction model for unstable accounts.

[0009] In one embodiment, based on the relationship between unstable accounts and stable partitions, key features are constructed, including: calculating partition connectivity based on the connection strength between the unstable account and other accounts in the stable partition; wherein the connection strength represents the sum of the weights of the connection edges between the unstable account and other accounts in the partition; calculating partition stability based on the proportion of unstable accounts belonging to stable partitions; wherein the partition stability represents the degree of stability of the unstable account in the corresponding stable partition; calculating account coreness based on the coreness of the unstable account in the stable partition; wherein the account coreness represents the connectivity of the unstable account in the stable partition; using the partition connectivity, the partition stability and the account coreness as the key features to construct a multi-dimensional matrix.

[0010] In one embodiment, a weighted undirected graph of blockchain transactions is constructed based on a snapshot graph and a time sequence graph of blockchain transactions, including: associating each snapshot graph with a unique timestamp; extracting transaction data within a specified time period based on the snapshot graph and the time sequence graph; and constructing a weighted undirected graph by aggregating the transaction data within the specified time period; wherein the weighted undirected graph represents the transaction relationship of the system within the current time period, the weighted undirected graph includes a node set, an edge set, and a weight function, the node set represents a set of accounts that have had at least one transaction within the specified time period, the edge set represents account pairs that have a direct transaction relationship within the specified time period, the weight function includes a node weight and an edge weight, the node weight represents the number of transactions of the account within the specified time period, and the edge weight represents the transaction frequency of the account pair within the specified time period.

[0011] In one embodiment, based on the weighted undirected graph, an account partition result is derived for each snapshot graph, including: based on the snapshot graph, recording the partition to which each account belongs at different time points to form an account partition record; integrating all account partition records into a global partition record set; wherein the global partition record set records the partition affiliation of the account at all time points.

[0012] In one embodiment, the blockchain account partitioning method further includes: when there is newly generated transaction data, incorporating the newly generated transaction data into a weighted undirected graph of updated transactions, and periodically updating the partition prediction model of unstable accounts.

[0013] According to another aspect of the present invention, a blockchain account partitioning device is provided, comprising: a construction module, configured to construct a weighted undirected graph of blockchain transactions based on a snapshot graph and a time sequence graph of blockchain transactions; wherein the snapshot graph represents account transaction relationships within a specified time period; an export module, configured to export an account partitioning result for each snapshot graph based on the weighted undirected graph; an identification module, configured to identify stable accounts and unstable accounts based on the account partitioning result; wherein the stable accounts represent accounts that are divided into the same partition within a preset time period, and the unstable accounts represent accounts that are divided into multiple partitions within a preset time period; an acquisition module, configured to acquire historical transaction data of stable and unstable accounts; a first partitioning module, configured to determine a stable partition based on the historical transaction data of the stable accounts, and to use the stable partition as the partition affiliation of the stable accounts in a future time period; a model building module, configured to establish a partition prediction model for the unstable accounts based on the historical transaction data of the unstable accounts and the stable partitions; and a second partitioning module, configured to obtain the partition affiliation of the unstable accounts in a future time period based on the partition prediction model and the transaction data of the unstable accounts, to determine the partition affiliation of the unstable accounts in the future time period.

[0014] The blockchain account partitioning method and device provided by the present invention, based on a weighted undirected graph, captures the dynamic changes in account transaction relationships, thereby obtaining account partitioning results in past transactions. Based on the account partitioning results, partitions that exist stably across multiple time series are identified. Stable partitions and stable accounts are used as the infrastructure for long-term maintenance. For unstable accounts, a partition prediction model is constructed to predict the future partition affiliation of unstable accounts, thereby dynamically adjusting the account allocation plan, improving partition accuracy, optimizing partition load balancing, and reducing cross-partition transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above and other objects, features, and advantages of the present invention will become more apparent through a more detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. The accompanying drawings are provided to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and are not intended to limit the present invention. In the drawings, the same reference numerals generally represent the same components or steps.

[0016] Figure 1 This is a flowchart of a blockchain account partitioning method provided by an exemplary embodiment of the present invention.

[0017] Figure 2 It is a structural diagram of a blockchain transaction sequence diagram provided by an exemplary embodiment of the invention.

[0018] Figure 3 It is a single snapshot diagram in a transaction sequence provided by an exemplary embodiment of the invention.

[0019] Figure 4 It is a schematic diagram of the structure of a stable partition provided by an exemplary embodiment of the present invention.

[0020] Figure 5 It is a structural diagram of an account partitioning device of a blockchain provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0021] Below, the exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0022] In a blockchain state partitioning architecture, the network is divided into multiple shards, each of which maintains only a portion of the account state and processes transactions associated with it. While this design improves parallel processing capabilities, it also introduces cross-shard transaction (CRT) issues, manifested in high communication overhead. Cross-shard transactions require collaborative verification across multiple shards, resulting in additional messaging and consensus costs. Low throughput and significantly higher latency for cross-shard transactions compared to intra-shard transactions create performance bottlenecks. Increased complexity necessitates the introduction of atomic protocols (such as two-phase commit) to ensure cross-shard transaction consistency, further reducing efficiency. To reduce cross-shard transactions, existing research has proposed account allocation methods based on graph theory. Their core process involves constructing a static account graph, modeling historical transaction data as a graph structure where nodes represent accounts, edges represent transaction relationships, and weights reflect interaction frequency or amount. A graph partitioning algorithm is then applied, using community detection (such as the Louvain algorithm) or spectral clustering to assign frequently interacting accounts to the same shard.

[0023] However, the aforementioned graph-based account allocation method has significant limitations. Specifically, this method constructs historical transaction data as a static graph, assuming that transaction relationships between accounts are fixed and unchanging. It then applies a graph partitioning algorithm to the historical data, and the resulting partitioning is directly applied to future stages of the system. This static graph partitioning approach ignores the dynamic nature of account transaction relationships in blockchain systems. In practice, transaction relationships between accounts evolve over time, with new transaction patterns emerging and old ones disappearing. Therefore, static graph-based partitioning methods struggle to adapt to these dynamic changes, resulting in significant discrepancies between the method's actual performance and intended outcomes. Directly applying the static partitioning scheme to future transaction stages results in a decrease in the actual interaction frequency between accounts within a partition, while the proportion of cross-partition transactions remains high. New accounts, lacking historical data, are difficult to allocate appropriately, exacerbating partition imbalances.

[0024] To solve the problem that partitioning ignores the dynamic evolution of transaction relationships, Figure 1 This is a flowchart of a blockchain account partitioning method provided by an exemplary embodiment of the present invention. Figure 1 For example, first, based on the snapshot graph and time sequence graph of blockchain transactions, a weighted undirected graph of blockchain transactions is constructed (see Figure 1 S110); wherein the snapshot graph represents the account transaction relationship within a specified time period. Secondly, based on the weighted undirected graph, the account partition result is derived for each snapshot graph (see Figure 1 Then, based on the account partitioning result, stable accounts and unstable accounts are identified (see Figure 1 Next, obtain the historical transaction data of the stable account and the unstable account (see Figure 1 On this basis, based on the historical transaction data of the stable account, the stable partition is determined, and the stable partition is used as the partition of the stable account in the future period (see Figure 1 Then, based on the historical transaction data of the unstable account and the stable partition, a partition prediction model for the unstable account is established (see Figure 1 Finally, based on the partition prediction model of the unstable account and the transaction data of the unstable account, the partition belonging of the unstable account in the future period is obtained to determine the partition belonging of the unstable account in the future period (see Figure 1 S170).

[0025] Therefore, as a possible implementation method, we can first perform data processing. Historical transactions, construct a time series diagram, extract partition results, identify stable partitions, and obtain stable partitions and unstable accounts. Next, perform feature extraction, obtain the feature matrix, and generate test and training datasets. Then, perform model training using the LSTM initial model, as well as the feature matrix, test and training datasets, to train the final LSTM model and finally obtain Y. pred , Y pred Each row represents the predicted probability of the account in each partition category. After model training and construction, when new data is available, predictions are made based on the partition labels. The blockchain sharding system obtains partition prediction results, which is the state partitioning, shard consensus, and finally synchronization of transaction data. Transaction data can then become historical transaction data, providing reference data for subsequent partitions.

[0026] Combined with the following Figure 1 , a more detailed introduction to the blockchain account partitioning method provided in the embodiment of this application is given.

[0027] In S110 , a weighted undirected graph of blockchain transactions is constructed based on the snapshot graph and the time sequence graph of the blockchain transactions.

[0028] A snapshot graph represents account transaction relationships within a specified time period. It records the global state of the blockchain (e.g., account balances) at a specific block height. The essence of a blockchain is a continuously updated sequence of snapshots (each block corresponds to a snapshot). Snapshot graphs can also be used to back up, restore, or analyze a specific historical state of the blockchain, making them a valuable tool for data management. Sequence graphs depict the dynamic process of blockchain transactions. Weighted undirected graphs transform abstract blockchain transaction data into a visual network of relationships. Weighted undirected graphs consist of nodes, edges, and weights. Weights (e.g., transaction amount, number of transactions) can be used to measure the closeness of connections between accounts. This helps reduce cross-partition transactions by using weight-guided partitioning algorithms.

[0029] In some embodiments, a unique timestamp is associated with each snapshot graph; transaction data within a specified time period is extracted based on the snapshot graph and the time series graph; and a weighted undirected graph is constructed by aggregating the transaction data within the specified time period; wherein the weighted undirected graph represents the transaction relationship of the system within the current time period, and the weighted undirected graph includes a node set, an edge set, and a weight function, the node set represents a set of accounts that have had at least one transaction within the specified time period, the edge set represents account pairs that have a direct transaction relationship within the specified time period, the weight function includes a node weight and an edge weight, the node weight represents the number of transactions of the account within the specified time period, and the edge weight represents the transaction frequency of the account pair within the specified time period.

[0030] As a possible implementation method, the blockchain transaction sequence diagram It consists of a set of transaction snapshot graphs arranged in time series. Figure 2 This is a schematic diagram of the structure of a blockchain transaction sequence diagram provided by an exemplary embodiment of the invention. Figure 2 For example, each snapshot graph G (t) Associated with a unique timestamp t, by aggregating the transaction data set within the specified time interval [t-Δt,t] Constructed as a weighted undirected graph G (t) (V (t) ,E (t) ,W (t) ), which represents the transaction relationship of the system within a specified time period.

[0031] As a possible implementation, in a single snapshot graph G (t) In the node set V (t) ={v1,v2,…,v n} represents the set of accounts that have at least one transaction in the specified time period [t-Δt,t], where each node v i Represents a unique blockchain account. Edge set E (t) ={eij |v i ,v j ∈V (t) ,e ij =(v i ,v j )} represents an account pair that has a direct transaction relationship within a specified time period. Specifically, if account v i and v j If there is at least one transaction within the specified time period, then Figure G (t) There is an undirected edge e in ij ∈E (t) . Weight function W (t) Including node weights and edge weights They represent the number of transactions of account v in the specified time period [t-Δt,t] and the number of transactions of account pair (v i ,v j ) is the frequency of transactions during the specified time period. Figure 3 A single snapshot diagram of a transaction sequence provided by an exemplary embodiment of the invention is shown in FIG. Figure 3 For example, the transaction set There are seven transactions in total. Transaction 1 is A→B, A and B are account pairs. Transaction 2 is A→C, A and C are account pairs. Transaction 3 is A→D, A and D are account pairs. Transaction 4 is B→D, B and D are account pairs. Transaction 5 is B→C, B and C are account pairs. Transaction 6 is C→D, C and D are account pairs. Transaction 7 is A→C, a secondary transaction. After building the snapshot graph, the node weight W(v i ) is A:4, B:3, C:4, D:3, and the numbers on the undirected edges connecting the letters represent W(e ij ): edge weight, for example, the edge weight of A→B is 1, the edge weight of A→C is 2, the edge weight of A→D is 1, the edge weight of B→D is 1, the edge weight of B→C is 1, the edge weight of C→D is 1, and the edge weight of A→C is 1.

[0032] In S120 , based on the weighted undirected graph, an account partition result is derived for each snapshot graph.

[0033] In some embodiments, based on the snapshot graph, the partition to which each account belongs at different time points is recorded to form an account partition record; all account partition records are integrated into a global partition record set; wherein the global partition record set records the partition affiliation of the account at all time points.

[0034] As a possible implementation method, based on the constructed blockchain transaction sequence diagram Using graph partitioning method For each snapshot graph G (t)Export account partition results. For example, when the system presets the number of partitions to k, for each snapshot graph G in the blockchain transaction sequence graph (t) Execution graph partitioning algorithm Get the account partition results of k partitions Among them, P i (t) represents the set of accounts belonging to the i-th partition in time period t. Then, for each account v∈V, find the partition to which it belongs Update the global partition record set:

[0035]

[0036] Record the account partition affiliation for all time periods t to provide a data basis for subsequent stable partition identification.

[0037] In S130 , based on the account partitioning result, stable accounts and unstable accounts are identified.

[0038] Among them, a stable account refers to an account that is always assigned to the same partition within a preset time period, or an account that is assigned to the same partition frequently within a preset time period. An unstable account refers to an account that is assigned to multiple partitions within a preset time period, and its partition changes frequently. For example, based on the account partitioning results, the partition stability of each account is calculated; when the account partition stability is greater than or equal to the preset stability threshold, the account is determined to be a stable account; when the account partition stability is less than the preset stability threshold, the account is determined to be an unstable account. The partition stability value is used to quantify the stability of the account partition, so that subsequent stable partitions can be defined and provide a reference standard for partitioning.

[0039] In some embodiments, the partition stability of each account can be calculated using the following method: traversing the partitions to which the account belongs at different times and counting the number of times the account appears in each partition; determining the partition in which the account appears the most times as the belonging partition; calculating the proportion of the account assigned to the belonging partition based on the number of times the account is assigned to the partition and the number of times the account is assigned to the belonging partition; and using the proportion as the partition stability of the account. In other words, the partition stability is further quantified by the proportion.

[0040] As a possible implementation method for calculating partition stability, based on the global partition record set Statistics on the partition affiliation of accounts in different time periods, and based on the stability threshold θ s Calculate the partition stability of each account, that is, whether the account remains in the same partition for a long time in different time periods. First, traverse Count the partitions to which each account v belongs in different time periods t And calculate the number of times it appears in each partition. For each account v, determine the partition in which it appears most frequently That is, the partition to which the account belongs the most in all time periods:

[0041]

[0042] in, Indicates the number of times account v is assigned to partition P in the time period [1, T]. Then, calculate the number of times account v is assigned to partition P in the time period [1, T]. The attribution ratio in:

[0043]

[0044] in, represents the number of times account v is assigned to partition P in the time period [1, T], γ v Indicates that account v is in partition The attribution ratio in .

[0045] If γ v Greater than or equal to the set stability threshold θ s , then the account is considered to belong to the stable partition. If γ v Less than the set stability threshold θ s , otherwise it is classified as an unstable account.

[0046] For all satisfying γ v ≥θ s accounts, based on their most frequent partitions Perform calculations to form a stable partition set:

[0047]

[0048] Each stable partition S i All the nodes that remain in partition P for most of the time i The account composition is:

[0049]

[0050] Accounts that frequently migrate across partitions are considered unstable accounts and are not assigned to any stable partition. They are recorded as:

[0051]

[0052] After the stable accounts and the unstable accounts are divided, in S140 , the historical transaction data of the stable accounts and the unstable accounts are obtained.

[0053] Stable accounts are stable because of their division. Stable partitions can be determined through stable accounts, thus forming a basic structure and providing data reference for the subsequent division of unstable accounts.

[0054] In S150 , a stable partition is determined based on the historical transaction data of the stable account, and the stable partition is used as the partition to which the stable account belongs in the future period.

[0055] In the partition results of different time periods, if a group of accounts are divided into the same partition for a long time, it constitutes a stable partition. Figure 4 is a schematic diagram of a stable partition structure provided by an exemplary embodiment of the present invention. Figure 4 For example, the transaction relationship between accounts A, B, and C in the figure is close, so they can continue to exist in the same partition. Therefore, the partition where A, B, and C continue to exist is determined as Similarly, accounts F, G, and E are also another stable partition. The stable partition where accounts F, G, and E exist can be determined as D and H are unstable accounts, which will produce a certain frequency of partition changes, but it can be seen that D and H are related to the stable partition. There is a connection relationship.

[0056] In S160 , a partition prediction model for unstable accounts is established based on the historical transaction data of the unstable accounts and the stable partitions.

[0057] In some embodiments, a sliding window-based long short-term memory (LSTM) network prediction method can be used to extract key time series features from the historical transaction data of unstable accounts to predict the partition affiliation of unstable accounts in the next phase. For example, the historical transaction data of unstable accounts can be divided into multiple subsequences using a sliding window technique. Each subsequence represents the transaction behavior of an unstable account within a time window, and each time window consists of multiple time steps, each of which includes multidimensional data features of an unstable account. Based on the number of unstable accounts and the subsequences of unstable accounts, an input tensor for the partition prediction model of unstable accounts is constructed. In other words, key features are extracted from the historical transaction data of unstable accounts, and the historical transaction data is divided into multiple subsequences using a sliding window technique. Each subsequence represents the transaction behavior of an account within a specific time window. Each time window consists of multiple time steps, each of which includes multidimensional data features of an account.

[0058] As a possible implementation, the model's input tensor X consists of a set of unstable accounts The data is composed of the shape:

[0059]

[0060] in, represents the number of unstable accounts extracted above, n_windows represents the number of subsequences obtained by sliding windows for each unstable account, t is the time interval for recording sample data, and |F| is the feature dimension contained in each time step.

[0061] In addition, stable partitions can be used as supervisory signals and as reference labels for classification tasks due to their long-term stability. Therefore, based on the categories of stable partitions of accounts, the label tensor of the partition prediction model of unstable accounts can be constructed. For example, the label tensor Y corresponds to the partition category of account v calculated in each time window above. Its shape is represented as:

[0062]

[0063] Where n_classes represents the number of partition classes in all blockchain partition systems. Label Y uses one-hot encoding, and the label vector for each time window has only one element set to 1, indicating the actual partition to which the account belongs in that time window.

[0064] During training, the LSTM model learns the relationship between temporal features and partitions based on the input tensor X and the label tensor Y, and outputs a normalized category probability distribution tensor through the softmax layer:

[0065]

[0066] Among them, Y pred Each row represents the predicted probability of the account in each partition category, satisfying:

[0067]

[0068] Finally, the predicted partition of the account is determined by the maximum probability decision rule, that is, the category with the highest predicted probability is selected as the final partition prediction result:

[0069]

[0070] In addition, building a partition prediction model also requires constructing features. Therefore, based on the input tensor of the partition prediction model, a feature matrix is constructed; based on the relationship between unstable accounts and stable partitions, key features are constructed; the key features are merged into the feature matrix to construct a multi-dimensional matrix; the multi-dimensional matrix is used as the test data set and training data set of the partition prediction model to train the partition prediction model of unstable accounts.

[0071] As a possible implementation method, for the features of unstable account v at time step t, construct the feature matrix The following three features are constructed to model the relationship between unstable accounts and all stable partitions:

[0072] Calculate the partition connectivity based on the connection strength between the unstable account and other accounts in the stable partition:

[0073]

[0074] Partition connectivity Represents unstable account v and stable partition S i The connection strength between other accounts in deg(v i ,S i ,t),v ′ Indicates other accounts in the stable partition, represents the node weight, t is the time interval for recording sample data, and the connection strength represents the sum of the edge weights of the unstable account and other accounts in the partition. The larger the degree of connection strength, the closer the unstable account is to the partition.

[0075] Calculate partition stability based on the ratio of unstable accounts to stable partitions:

[0076] Partition stability Indicates that account v belongs to stable partition S within m time steps i The ratio of partition stability characterizes the proportion of unstable accounts in the corresponding stable partition S i The degree of stability in . The higher it is, the stronger the stable relationship between account v and the partition is. The lower the value, the worse the stability of account v in the partition. The calculation formula is as follows:

[0077]

[0078] in, Indicates partition stability, It represents the number of times that account v is assigned to partition P in the time period [1, T], and m represents the time step.

[0079] Calculate the account coreness based on the coreness of the unstable account in the stable partition:

[0080] Account coreness Measurement Account v Measurement Account S i The core degree of an account in a stable partition indicates the degree of connection of an unstable account in the stable partition. The larger the value of the account core degree, the stronger the connection of the account in the partition and the more important the role. The smaller the value of the account core degree, the lower the connection of the account in the partition and the less important the role. The calculation formula is as follows:

[0081]

[0082] Among them, deg(v i ,S i ,t) indicates that the unstable account is in the stable partition S i The connection strength, deg(v ′ ,S i ,t) indicates that other accounts are in the stable partition S i connection strength.

[0083] Taking partition connectivity, partition stability, and account coreness as key features, the above three features are merged into the feature matrix to form a matrix with a dimension of 3×k, where k represents the number of stable partitions in the system.

[0084] The shape of the multidimensional matrix is as follows:

[0085]

[0086] in, represents the partition connectivity, Indicates the core degree of the account, Indicates partition stability.

[0087] The multi-dimensional matrix is fed into the LSTM model for training. After training, the model can be used to predict the optimal partitioning for unstable accounts in future periods. This prediction result can be used to guide the next round of state partitioning deployment in the system.

[0088] In S170 , based on the partition prediction model of the unstable account and the transaction data of the unstable account, the partition affiliation of the unstable account in the future period is obtained to determine the partition affiliation of the unstable account in the future period.

[0089] In some embodiments, as time goes by, when there is newly generated transaction data, the newly generated transaction data will be included in the updated transaction time sequence diagram. The method can repeat the above steps based on the new historical data, periodically update the model and achieve continuous optimization of the dynamic partitioning strategy, thereby improving the performance of the blockchain sharding system in dynamic transaction scenarios.

[0090] Figure 5 This is a schematic diagram of the structure of an account partitioning device of a blockchain provided by an exemplary embodiment of the present invention. Figure 5As shown, the account partitioning device 5 of the blockchain includes: a construction module 51, which constructs a weighted undirected graph of blockchain transactions based on a snapshot graph and a time sequence graph of blockchain transactions; wherein the snapshot graph represents the account transaction relationship within a specified time period; an export module 52, which exports the account partitioning result for each snapshot graph based on the weighted undirected graph; an identification module 53, which identifies stable accounts and unstable accounts based on the account partitioning result; wherein a stable account represents an account that is divided into the same partition within a preset time period, and an unstable account represents an account that is divided into multiple partitions within a preset time period; an acquisition module 54, which acquires historical transaction data of stable accounts and unstable accounts; a first partitioning module 55, which determines a stable partition based on the historical transaction data of the stable account, and uses the stable partition as the partition affiliation of the stable account in the future time period; a model building module 56, which establishes a partition prediction model for the unstable account based on the historical transaction data of the unstable account and the stable partition; and a second partitioning module 57, which obtains the partition affiliation of the unstable account in the future time period based on the partition prediction model and the transaction data of the unstable account, so as to determine the partition affiliation of the unstable account in the future time period.

[0091] In one embodiment, the identification module 53 can be configured to: calculate the partition stability of each account based on the account partitioning result; when the partition stability of the account is greater than or equal to the preset stability threshold, determine the account as a stable account; when the partition stability of the account is less than the preset stability threshold, determine the account as an unstable account.

[0092] In one embodiment, the identification module 53 can also be configured to: traverse the partitions to which the account belongs at different times, and calculate the number of times the account appears in each partition; determine the partition in which the account appears the most times as the belonging partition; based on the number of times the account is assigned to the partition and the number of times the account is assigned to the belonging partition, calculate the belonging ratio of the account assigned to the belonging partition; and use the belonging ratio as the partition stability of the account.

[0093] In one embodiment, the model building module 56 can be configured to: construct a label tensor for a partition prediction model of an unstable account based on the category of the stable partition of the account; divide the historical transaction data of the unstable account into multiple subsequences through a sliding window technology; wherein each subsequence represents the transaction behavior of the unstable account within a time window, each time window is composed of multiple time steps, and each time step includes multidimensional data features of the unstable account; and construct an input tensor for a partition prediction model of an unstable account based on the number of unstable accounts and the subsequences of the unstable accounts.

[0094] In one embodiment, the model building module 56 can also be configured to: construct a feature matrix based on the input tensor of the partition prediction model; construct key features based on the relationship between unstable accounts and stable partitions; merge the key features into the feature matrix to construct a multi-dimensional matrix; use the multi-dimensional matrix as a test data set and a training data set of the partition prediction model to train the partition prediction model of unstable accounts.

[0095] In one embodiment, the model building module 56 can also be configured to: calculate the partition connectivity based on the connection strength between the unstable account and other accounts in the stable partition; wherein the connection strength represents the sum of the connection edge weights between the unstable account and other accounts in the partition; calculate the partition stability based on the proportion of unstable accounts belonging to the stable partition; wherein the partition stability represents the degree of stability of the unstable account in the corresponding stable partition; calculate the account coreness based on the coreness of the unstable account in the stable partition; wherein the account coreness represents the connectivity of the unstable account in the stable partition; use partition connectivity, partition stability and account coreness as key features to construct a multi-dimensional matrix.

[0096] In one embodiment, the construction module 51 can be configured to: associate each snapshot graph with a unique timestamp; extract transaction data within a specified time period based on the snapshot graph and the time series graph; construct a weighted undirected graph by aggregating the transaction data within the specified time period; wherein the weighted undirected graph represents the transaction relationship of the system within the current time period, the weighted undirected graph includes a node set, an edge set and a weight function, the node set represents a set of accounts that have had at least one transaction within the specified time period, the edge set represents account pairs that have a direct transaction relationship within the specified time period, the weight function includes node weight and edge weight, the node weight represents the number of transactions of the account within the specified time period, and the edge weight represents the transaction frequency of the account pair within the specified time period.

[0097] In one embodiment, the export module 52 can be configured to: based on the snapshot graph, record the partition to which each account belongs at different time points to form an account partition record; integrate all account partition records into a global partition record set; wherein the global partition record set records the partition affiliation of the account at all time points.

[0098] In one embodiment, the account partitioning device 5 of the blockchain may further include: when there is newly generated transaction data, incorporating the newly generated transaction data into the weighted undirected graph of the updated transaction, and periodically updating the partition prediction model of the unstable account.

[0099] Embodiments of the present invention provide a blockchain account partitioning device. Device embodiments can be implemented via software, hardware, or a combination of software and hardware. From a hardware perspective, in addition to a CPU, memory, network interface, and non-volatile memory, the device in which the device resides typically includes other hardware, such as a forwarding chip responsible for message processing. For example, in a software implementation, as a logical device, the device's CPU reads the corresponding computer program instructions from non-volatile memory into memory and executes them.

[0100] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the storage medium stores a computer program for executing the account partitioning method of the blockchain according to any one of the above embodiments.

[0101] In addition to the above-described methods and devices, embodiments of the present invention may also be a computer program product, which includes computer program instructions. When the computer program instructions are executed by a processor, the processor performs the steps of the blockchain account partitioning method according to various embodiments of the present invention described above.

[0102] According to another aspect of the present invention, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; and a processor for executing the blockchain account partitioning method of any of the above embodiments.

[0103] In addition, an embodiment of the present invention may also be a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the processor executes the steps of the account partitioning method of the blockchain according to various embodiments of the present invention described above.

[0104] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A blockchain account partitioning method, characterized in that: include: Constructing a weighted undirected graph of blockchain transactions based on a snapshot graph and a time sequence graph of blockchain transactions; wherein the snapshot graph represents the account transaction relationship within a specified time period; Based on the weighted undirected graph, deriving an account partition result for each snapshot graph; Based on the account partitioning result, identifying stable accounts and unstable accounts; Obtain historical transaction data for stable and unstable accounts; Determine a stable partition based on historical transaction data of the stable account, and use the stable partition as the partition to which the stable account belongs in a future period; Establishing a partition prediction model for unstable accounts based on the historical transaction data of the unstable accounts and the stable partitions; Based on the partition prediction model of the unstable account and the transaction data of the unstable account, the partition affiliation of the unstable account in the future time period is obtained to determine the partition affiliation of the unstable account in the future time period.

2. The blockchain account partitioning method according to claim 1, characterized in that: Based on the account partitioning result, stable accounts and unstable accounts are identified, including: Based on the account partitioning result, calculate the partition stability of each account; When the partition stability of the account is greater than or equal to a preset stability threshold, determining the account as a stable account; When the partition stability of the account is less than a preset stability threshold, the account is determined to be an unstable account.

3. The blockchain account partitioning method according to claim 2, characterized in that: Based on the account partitioning results, the partition stability of each account is calculated, including: Traverse the partitions to which the account belongs at different times and calculate the number of times the account appears in each partition; Determine the partition where the account appears the most times as the belonging partition; Calculate the attribution ratio of the account to the attribution partition based on the number of times the account is assigned to the partition and the number of times the account is assigned to the attribution partition; The attribution ratio is used as the partition stability of the account.

4. The blockchain account partitioning method according to claim 1, characterized in that: Based on the historical transaction data of unstable accounts, a partition prediction model for unstable accounts is established, including: Based on the categories of stable partitions described by the account, a label tensor is constructed for the partition prediction model of the unstable account; The sliding window technique is used to segment the historical transaction data of unstable accounts into multiple subsequences. Each subsequence represents the transaction behavior of an unstable account within a time window. Each time window consists of multiple time steps, each of which contains multidimensional data features of the unstable account. Based on the number of unstable accounts and the subsequences of unstable accounts, the input tensor of the partition prediction model of unstable accounts is constructed.

5. The blockchain account partitioning method according to claim 4, characterized in that: Based on the historical transaction data of unstable accounts, a partition prediction model for unstable accounts is established, which also includes: Constructing a feature matrix based on the input tensor of the partition prediction model; Based on the relationship between unstable accounts and stable partitions, key features are constructed; Merging the key features into the feature matrix to construct a multi-dimensional matrix; The multi-dimensional matrix is used as a test data set and a training data set of the partition prediction model to train the partition prediction model of unstable accounts.

6. The blockchain account partitioning method according to claim 5, characterized in that: Based on the relationship between unstable accounts and stable partitions, key features are constructed, including: Calculate the partition connectivity based on the connection strength between the unstable account and other accounts in the stable partition; wherein the connection strength represents the sum of the edge weights of the connection between the unstable account and other accounts in the partition; Calculate partition stability based on the proportion of unstable accounts belonging to stable partitions; wherein the partition stability represents the degree of stability of unstable accounts in the corresponding stable partition; Calculate the account coreness based on the coreness of the unstable account in the stable partition; wherein the account coreness represents the connectivity of the unstable account in the stable partition; The partition connectivity, the partition stability and the account coreness are used as the key features to construct a multi-dimensional matrix.

7. The blockchain account partitioning method according to claim 1, characterized in that: Based on the snapshot graph and time sequence graph of blockchain transactions, a weighted undirected graph of blockchain transactions is constructed, including: Associate a unique timestamp with each snapshot graph; Extract transaction data within a specified time period based on snapshot graphs and time series graphs; A weighted undirected graph is constructed by aggregating transaction data within a specified time period; wherein the weighted undirected graph represents the transaction relationship of the system within the current time period, and the weighted undirected graph includes a node set, an edge set, and a weight function. The node set represents a set of accounts that have had at least one transaction within the specified time period, and the edge set represents account pairs that have a direct transaction relationship within the specified time period. The weight function includes node weight and edge weight. The node weight represents the number of transactions of an account within the specified time period, and the edge weight represents the transaction frequency of an account pair within the specified time period.

8. The blockchain account partitioning method according to claim 1, characterized in that: Based on the weighted undirected graph, deriving an account partition result for each snapshot graph includes: Based on the snapshot graph, record the partition to which each account belongs at different time points to form an account partition record; All account partition records are integrated into a global partition record set; wherein the global partition record set records the partition affiliation of accounts at all time points.

9. The blockchain account partitioning method according to claim 1, characterized in that: The account partitioning method of the blockchain further includes: When there is newly generated transaction data, the newly generated transaction data is included in the weighted undirected graph of the updated transaction, and the partition prediction model of the unstable account is periodically updated.

10. A blockchain account partitioning device, characterized in that: include: A construction module constructs a weighted undirected graph of blockchain transactions based on a snapshot graph and a time sequence graph of blockchain transactions; wherein the snapshot graph represents the account transaction relationship within a specified time period; An export module, which exports an account partition result for each snapshot graph based on the weighted undirected graph; an identification module, which identifies stable accounts and unstable accounts based on the account partitioning result; wherein the stable accounts refer to accounts that are partitioned into the same partition within a preset time period, and the unstable accounts refer to accounts that are partitioned into multiple partitions within a preset time period; Acquisition module, obtains historical transaction data of stable accounts and unstable accounts; A first partitioning module determines a stable partition based on historical transaction data of a stable account, and uses the stable partition as a partition for the stable account in a future period; Establishing a model module to establish a partition prediction model for unstable accounts based on the historical transaction data of the unstable accounts and the stable partitions; The second partitioning module obtains the partition affiliation of the unstable account in the future time period based on the partition prediction model of the unstable account and the transaction data of the unstable account, so as to determine the partition affiliation of the unstable account in the future time period.

Images