A blockchain sharding account adjustment method and device based on timing

Abstract

The application discloses a blockchain sharding account adjustment method and device based on time sequence and a computer device. The method comprises the following steps: based on the transaction data of the continuous period of an account, a time series prediction model for predicting future transaction behavior is constructed for the account. After determining the account that needs to be adjusted, the last stage of each period of the account is dynamically adjusted according to the state-identifiable Patricia tree and multi-account model proposed by the application, aiming at long-term stable reduction of the number of cross-shard transactions in the sharding system. For the case that a single shard is overloaded, the load of each shard is monitored in real time by adjusting the shard, and a load balancing strategy is executed when a single shard is overloaded, temporarily activating the low-load shard-related sub-account to realize the parallel processing of a large number of transactions of the same account by multiple shards, so as to realize the high availability and high performance of the sharding system.

Description

Technical Field

[0001] This invention relates to the field of blockchain sharding technology, and in particular to a method and apparatus for adjusting blockchain sharded accounts based on time sequence. Background Technology

[0002] Blockchain technology, as a key foundation for decentralized applications, has garnered significant attention in both academia and industry. This technology utilizes a peer-to-peer network, enabling each node to verify and record transactions by solving computational problems, thus supporting decentralized applications without central authority intervention, such as cryptocurrencies. However, blockchain faces performance limitations because its operation relies on the joint verification and data storage of all nodes in the network, resulting in its processing power being unable to match that of centralized systems. Furthermore, while increasing the number of network participants improves system security, it does not enhance performance, a significant weakness for modern applications requiring high processing volumes. To overcome this challenge, blockchain state sharding technology has emerged, enhancing scalability and significantly improving system throughput by subdividing network and account states into subsets. However, cross-shard transactions require additional communication and consensus mechanisms to ensure transaction consistency, which can be counterproductive when cross-shard transactions constitute a high proportion, degrading system performance. Therefore, finding an optimized state partitioning method to reduce the frequency of transactions between shards has become crucial for improving blockchain performance.

[0003] In sharded blockchain systems, two main factors affect system performance: First, cross-shard transactions. When a transaction needs to be executed across multiple shards, since the shard where the transaction initiator resides does not store the recipient's state information, it must communicate and collaborate with other shards to complete the transaction and ensure the atomicity and consistency of both parties' states. This requires consensus to be reached across multiple shards, resulting in a significant additional confirmation delay compared to intra-shard transactions with single consensus. Furthermore, completing a cross-shard transaction requires multiple consensus processes, which not only increases transaction confirmation time but also consumes more block storage resources, thus impacting the overall system throughput. Second, load balancing. Ideally, we want each shard's transaction pool to complete the processing and on-chain processing of all transactions within a single consensus cycle. However, when the number of transactions in a shard's transaction pool exceeds its block capacity limit, newly arriving transactions must wait for the processing of existing transactions in the pool. In extreme cases, this may cause transactions to fail to be on-chain even after multiple rounds of consensus, resulting in severe transaction confirmation delays.

[0004] To overcome the aforementioned challenges, current research on account status sharding primarily relies on analyzing historical transaction data to understand account trading habits before sharding. However, account trading behavior is not static; it has a temporal attribute and evolves over time. As the system continues to develop, the original account division may become inadequate, leading to an increase in cross-shard transactions. Therefore, this research aims to propose a method that can monitor changes in trading habits in real time and adjust accordingly, ensuring that the sharding system minimizes cross-shard transactions and optimizes system performance at any given time.

[0005] To address the dynamic changes inherent in blockchain account state sharding, two main challenges arise. First, the dynamic adjustment of user accounts requires a method that is both efficient and ensures secure and stable transactions. Given the critical importance of security in blockchain systems, this method must be able to withstand various attacks and safeguard account funds. Second, the challenge lies in developing a monitoring mechanism capable of accurately identifying and locating accounts requiring adjustment from among numerous participating accounts. Considering the high cost of predicting a large number of accounts, finding an economical and effective prediction method to accurately pinpoint accounts needing adjustment is crucial. Summary of the Invention

[0006] To address the challenges posed by blockchain account sharding technology, we propose a time-series-based blockchain sharding account adjustment method and apparatus that can promptly detect and adjust account sharding, thereby maintaining a long-term, stable, and low number of cross-shard transactions in the sharding system.

[0007] A time-series-based blockchain sharded account rebalancing method, the method comprising:

[0008] Based on the transaction records of each account in the sharded blockchain system in consecutive epochs, a predictive model that can predict future transaction behavior is built for each account.

[0009] Based on the special shard AD-shard in the system, obtain the accounts that have sent cross-shard transactions in the current epoch, filter out the accounts with a high proportion of cross-shard transactions, and obtain the accounts that need to be adjusted in the current epoch.

[0010] Based on the transaction records of the account in recent consecutive epochs, the RNN model is used as input to predict the transaction probability of these accounts in each shard in the next epoch, and the account is adjusted at the end of each epoch in combination with the load of each shard.

[0011] AD-shard is used to monitor the load of each shard. For shards that are overloaded, load balancing strategies are implemented. Low-load shards are temporarily activated to activate relevant accounts and process transactions of overloaded shards in parallel, thereby alleviating the performance overload of a single shard.

[0012] In one embodiment, the method further includes implementing a sub-account-based adjustment mechanism within a Patricia tree with a state field, where an account can exist across multiple shards in the sharding system. Adjustments to the account can be made by transferring the balance of the primary account to a sub-account in the form of a transaction, and then setting the sub-account as the primary account, thereby achieving dynamic adjustment of the account across different shards.

[0013] In one embodiment, the system further includes: in an account / balance model-based blockchain system, the state tree is maintained by a Patricia tree, wherein the non-leaf nodes of the Patricia tree with state remain unchanged, and a state field is added to the leaf nodes representing the state to identify the account in three states: active, dormant, and temporarily active. The same account can only be active in one shard, which is called the master account.

[0014] In one embodiment, it further includes: AD-shard, which is a shard composed of special participants, which stores the addresses of each shard participant and the shard where each master account is located locally. It is responsible for receiving and forwarding cross-shard transactions in the system, recording all cross-shard transactions, communicating with each shard in real time, monitoring the load balancing of the shard transaction pool, and running a load balancing algorithm to maintain the load balancing of each shard.

[0015] In one embodiment, the method further includes: based on the real-time load of the shard monitored by AD-shard, when a shard is overloaded at a certain moment, AD-shard will run a load balancing algorithm and will no longer send cross-shard transactions related to the shard to that shard. Instead, it will temporarily activate the relevant sub-accounts of the shard with lower load to process the transactions in batches. After the processing is completed, the transactions will be adjusted through the account to synchronize the processing results to the main account.

[0016] A time-series-based blockchain sharded account adjustment device, comprising:

[0017] The model building module is used to train a neural network model based on the transaction records of each epoch of the account. The input of the neural network model is the number of cross-shard transactions in n consecutive epochs, and the output is the prediction of cross-shard transaction data in the (n+1)th epoch.

[0018] The transaction prediction module is used to predict the cross-shard trading behavior of a single account in the next epoch based on the transaction records of the current epoch and the previous n-1 epochs, and to dynamically adjust the account based on the prediction results.

[0019] The account adjustment module is used to dynamically adjust accounts based on prediction results. The adjustment method is to transfer the same account between different shards through a sub-account model. The account transfer is realized through cross-shard transactions and enjoys the security protection mechanism of blockchain transactions, which can ensure the safe adjustment of accounts.

[0020] The load balancing module is used to monitor the load of each shard, promptly identify and alleviate the transaction volume of overloaded shards. The method to alleviate the overload of a single shard is to temporarily activate a sub-account in a shard with a low load, so that the shard temporarily has the ability to process the transactions related to that account. After the shard has processed all transactions, the results are synchronized to the main account through account adjustment.

[0021] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps:

[0022] Based on the transaction records of each account in the sharded blockchain system in consecutive epochs, a predictive model that can predict future transaction behavior is built for each account.

[0023] Based on the special shard AD-shard in the system, obtain the accounts that have sent cross-shard transactions in the current epoch, filter out the accounts with a high proportion of cross-shard transactions, and obtain the accounts that need to be adjusted in the current epoch.

[0024] Based on the transaction records of the account in recent consecutive epochs, the RNN model is used as input to predict the transaction probability of these accounts in each shard in the next epoch, and the account is adjusted at the end of each epoch in combination with the load of each shard.

[0025] AD-shard is used to monitor the load of each shard. For shards that are overloaded, load balancing strategies are implemented. Low-load shards are temporarily activated to activate relevant accounts and process transactions of overloaded shards in parallel, thereby alleviating the performance overload of a single shard.

[0026] The aforementioned time-series-based blockchain sharding account adjustment method, apparatus, and computer equipment have the following advantages compared to existing sharding technologies:

[0027] First, we designed a novel Patricia tree structure for storing account state leaf nodes. This structure allows an account to have multiple sub-accounts, transforming account adjustments into a special cross-shard transaction that benefits from all transaction security features, supporting efficient and secure dynamic account adjustments. Furthermore, we introduced a special shard—AD-shard—whose primary functions are forwarding cross-shard transactions and monitoring shard load. Next, we built a time-series prediction model (Recurrent Neural Network) for each user to predict potential cross-shard transaction behavior in the next epoch. Before the end of each epoch, the system collects and filters accounts with high cross-shard transaction ratios using AD-shard, and utilizes the RNN models of these accounts to predict transaction behavior for the next stage, thereby performing precise account state adjustments to maintain a low number of cross-shard transactions in the long term within the sharded blockchain system. To address the potential overload of a single shard due to a few hot accounts, we also designed a single-shard load balancing strategy. This strategy effectively manages and distributes transaction load during peak periods, ensuring the stability and efficiency of the sharded system during surges in transaction volume. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a time-series-based blockchain sharded account adjustment method in one embodiment;

[0029] Figure 2 This is a schematic diagram of an account adjustment algorithm in one embodiment;

[0030] Figure 3 This is a schematic diagram of the system structure in one embodiment;

[0031] Figure 4 This is a structural block diagram of a blockchain sharded account adjustment device based on time sequence in one embodiment;

[0032] Figure 5 This is a diagram of the internal structure of a computer device in one embodiment. Detailed Implementation

[0033] To more clearly illustrate the purpose, technical solution, and advantages of this application, a detailed description will be provided below in conjunction with the accompanying drawings and embodiments. It should be noted that the specific embodiments described below are merely illustrative of this application and do not limit its scope.

[0034] The time-series-based blockchain sharded account adjustment method provided in this application, such as Figure 1 As shown, it includes the following steps:

[0035] Step 102: Based on the transaction records of each account in the sharded blockchain system in consecutive epochs, use them as the training set for the time series RNN neural network to build a predictive model for each account that can predict future transaction behavior.

[0036] The account prediction model is for a single account. The input to the neural network is multiple n-dimensional vectors, where each vector represents the number of transactions initiated by the account to n different shards in the sharded blockchain system in one epoch, corresponding to different dimensions of the vector. The output of the neural network is an n-dimensional vector, where each dimension represents the number of transactions that the user may initiate to the corresponding shard in the next epoch.

[0037] Step 104: Based on the special shard AD-shard in the system, obtain the accounts that have sent cross-shard transactions in the current epoch, and filter out the accounts with a high proportion of cross-shard transactions to obtain the accounts that need to be adjusted in the current epoch.

[0038] AD-shard is primarily responsible for receiving, forwarding, and recording cross-shard transactions in the system. Through AD-shard, accounts that have generated cross-shard transactions in the system can be quickly identified. For these accounts, AD-shard will count the shard that sent the most transactions in the current epoch. If the shard is the same shard as the account, no adjustment is needed; otherwise, the account will be listed as the account that needs adjustment.

[0039] Step 106: Based on the transaction records of the account in recent consecutive epochs, use them as input to the RNN model to predict the possible transactions of these accounts in each shard in the next epoch, and adjust the account at the end of each epoch in combination with the load of each shard.

[0040] Based on the neural network prediction model, the possible transaction data of the account that needs adjustment in the next epoch is obtained, and the account is adjusted. The account adjustment is to switch the state of an account from one shard to another. In this invention, an account is allowed to have multiple sub-accounts located in different shards. The account adjustment can be carried out by transferring the state of the main account to the sub-account through transactions, and setting the target sub-account as the main account. The original main account then becomes a sub-account. By switching the account's shards through transactions, all the security protection mechanisms for transactions in the blockchain design can be enjoyed, achieving efficient and secure account adjustment.

[0041] Step 108: Monitor the load of each shard according to AD-shard, execute load balancing strategy for shards with excessive load, call low-load shards to temporarily activate relevant accounts to process transactions of overloaded shards in parallel, and alleviate the performance overload phenomenon of a single shard.

[0042] AD-shard uses heartbeat monitoring to obtain the size of the transaction pool in each shard in real time, thereby grasping the load status of each shard. The heartbeat monitoring means that each shard transmits its own transaction pool information to AD-shard every few seconds. For shards with excessive load, AD-shard will forward transactions from accounts with a large number of cross-shard transactions to shards with low load for processing, thereby achieving parallel processing of transactions. If the low-load shard has relevant sub-accounts, it will activate the sub-accounts to process these transactions; otherwise, it will create a sub-account to process the transactions. When the transaction pool of a low-load shard no longer has transactions related to that account, the low-load shard will synchronize the status of the sub-accounts to the main account through account adjustment.

[0043] The aforementioned time-series-based blockchain sharding account adjustment method, apparatus, and computer equipment have the following advantages compared to existing sharding technologies:

[0044] First, we designed a novel Patricia tree structure for storing account state leaf nodes. This structure allows an account to have multiple sub-accounts, transforming account adjustments into a special cross-shard transaction that benefits from all transaction security features, supporting efficient and secure dynamic account adjustments. Furthermore, we introduced a special shard—AD-shard—whose primary functions are forwarding cross-shard transactions and monitoring shard load. Next, we built a time-series prediction model (Recurrent Neural Network, RNN) for each user to predict potential cross-shard transaction behavior in the next epoch. Before the end of each epoch, the system uses AD-shard to collect and filter accounts with high cross-shard transaction ratios, and utilizes the RNN models of these accounts to predict transaction behavior for the next stage, thereby performing precise account state adjustments to maintain a low number of cross-shard transactions in the long term within the sharded blockchain system. To address the potential overload of a single shard due to a few hot accounts, we also designed a single-shard load balancing strategy. This strategy effectively manages and distributes transaction load during peak periods, ensuring the stability and efficiency of the sharded system during surges in transaction volume.

[0045] In one embodiment, during the data collection phase, we aggregate all transaction records for all accounts across multiple epochs. These records are arranged chronologically according to the epochs to construct a training set suitable for time series analysis. Notably, our model targets a single account as the prediction unit. For each account, its data in the training set is represented as an n-dimensional vector x_in∈Rn, where n represents the total number of shards in the sharding system. In this vector, the value of each dimension k corresponds to the total number of transactions initiated by that account to accounts in shard number k. For example, a vector like [0,0,12,42] indicates that in a certain epoch with 4 shards, an account initiated 12 transactions to shard number 3, 42 transactions to shard number 4, and no transactions to shards numbered 1 and 2. In this way, we can accurately capture the transaction patterns of each account in different time periods, thus providing a solid data foundation for subsequent predictive analysis and account adjustment strategies. Algorithm 1 illustrates the construction process of x_in.

[0046] In one embodiment, for the initial stage of model building, taking the transaction data of a single account as an example, we first determine the maximum number of transactions for that account across all epochs for a single shard. Subsequently, we process each data point in the training set by dividing each dimension value in the data by this maximum number of transactions. Through this normalization process, the transaction data for each account is converted into values ​​between 0 and 1, thereby ensuring the comparability of data across different accounts and the consistency of model input.

[0047] Specifically, when constructing the training data for the time series model, we set a time step of size w, aiming to predict the trading behavior in the (w+1)th epoch using trading records from w consecutive epochs. This approach allows our model to predict future trading patterns while taking historical trading behavior into account.

[0048] Specifically, during model training, the choice of loss function and the application of the optimizer are crucial for improving model performance. Therefore, we chose Mean Squared Error (MSE) as the loss function and adopted the Adaptive Matrix Estimation Algorithm (Adam) as the optimizer. Adam combines the advantages of gradient descent and momentum methods, automatically adjusting the learning rate during training. This approach allows the optimizer to better adapt to different data characteristics and model architectures, thereby improving training efficiency and model performance. The core of the Adam optimizer lies in its simultaneous consideration of the first moment (mean) and second moment (uncentered variance) of the gradient, thus achieving a more stable optimization process. The MSE loss function calculates the square of the difference between the model's predicted value and the true value, and then takes their average. The specific formula is as follows:

[0049]

[0050] Where is the actual number of transactions generated by the account in the i-th shard, is the predicted number of transactions generated by the account in the i-th shard, and n is the total number of shards. The smaller the MSE, the closer the model's prediction is to the actual value.

[0051] In one embodiment, in existing classic blockchain systems based on the account / balance model, accounts are stored in the form of a Merkle Patricia Tree (MPT), where leaf nodes represent account nodes and store information including fields such as account balance, contract code, and storage. This efficient storage structure saves storage space and ensures fast account retrieval.

[0052] In the fragmentation system designed in this invention, such as Figure 3 As shown, we want an account to have multiple sub-accounts residing in multiple shards, but generally only one account is allowed to be active, while the rest are dormant. Therefore, we add a field called `state` to the account storage node to identify the account's state, so as to identify whether an account exists in the current shard as the primary account.

[0053] Specifically, there are three states: 1 indicates an active state, in which the account is the main account and all transactions involving this account will be processed by the shard to which the account belongs; 0 indicates a dormant state, in which the account does not participate in any transactions; and 2 indicates a temporarily active state, in which the account is a sub-account of a main account. They are temporarily awakened to handle a large number of transactions of the hot main account. After the processing is completed, the shard participants initiate a migration transaction to synchronize the state of the sub-account to the main account, and then enter the dormant state.

[0054] It's worth noting that not all shards need to store all sub-accounts for every account. Sub-accounts are only created in the target shard when an account needs to be migrated or when an idle shard needs to participate in parallel processing of a hot account, thus saving storage space. Furthermore, using a single number to identify the status of each account requires very little storage space, making this approach feasible.

[0055] In one embodiment, the migration transaction is initiated by a shard participant and is essentially a special cross-shard transaction specifically designed to migrate an account. Its contents include the sender's hash address, the receiver's hash address being the same as the sender's, the target shard ID, and the balance.

[0056] Specifically, based on the account's status, shard participants can quickly determine whether an account exists within the current shard and confirm whether a transaction is a local transaction or a cross-shard transaction. Since a migration transaction is essentially a cross-shard transaction, shard participants can process it conveniently and efficiently, and change the account's status through the content of the migration transaction, achieving efficient account migration.

[0057] It is worth noting that when sending migration transactions, the nonce value of the account also needs to be calculated to prevent replay attacks. To ensure the atomicity of migration transactions, we allocate a specific period at the end of each epoch to complete the confirmation of migration transactions, and ensure the eventual consistency of migration transactions through the relay transaction method designed in existing work. Since the sharding system of this invention has performed precise account partitioning through the account sharding algorithm, it greatly reduces the number of accounts that need to be adjusted. Therefore, the number of migration transactions that need to be processed during dynamic adjustment is small, and the processing of migration transactions can be completed in a short time.

[0058] In one embodiment, the sharding system designed in this invention includes a special type of shard called AD-shard, used for efficient cross-shard transaction forwarding. AD-shard records the shard to which each participant in the entire blockchain sharding system belongs, along with their IP address, and monitors load balancing and transaction activity in each shard in real time. Simultaneously, AD-shard maintains a time-series model for each account. At the end of each epoch, AD-shard, based on the account model and account adjustment algorithm, provides an account adjustment plan through intra-shard consensus. It is also responsible for receiving and forwarding cross-shard transactions from various shards.

[0059] Specifically, each shard only needs to communicate with AD-shard to achieve rapid cross-shard transaction transmission. This allows each shard to focus on its local intra-shard transactions without needing to consider how to deliver cross-shard transactions to designated shards. For account rebalancing, firstly, each shard obtains the account rebalancing plan from AD-shard and generates migration transactions for the accounts that need rebalancing within its shard. After consensus is reached within the shard, the state of the relevant accounts is reset, and these relay transactions are sent to AD-shard. Since AD-shard possesses complete information on the participant shards and their IP addresses, it can quickly forward these transactions to the corresponding shards for processing, completing the account rebalancing.

[0060] It's worth noting that at the end of each epoch, participants in each shard, based on the predictions from the time series model, initiate account migration transactions for accounts that generate a large number of cross-shard transactions. This transfers all account balances from the current shard to the target shard, and simultaneously sets the account to dormant status. If the relevant sub-account exists in the target shard, its status is set to active after the migration transaction is confirmed. If no sub-account exists, a new sub-account is created and set to active status.

[0061] In one embodiment, after preparing the training set and configuring the RNN model, we train the model using the Adam optimizer and mean squared error loss function described above. This training process aims to build a model capable of accurately predicting the number of cross-shard transactions for a single account. Specifically, the model predicts the number of cross-shard transactions for an account in the next epoch by analyzing the account's transaction data from the previous w epochs.

[0062] Specifically, the model's output is denoted as x. out ∈R n The predictions are consistent with the input data in terms of dimensions and meaning, where each dimension represents the predicted number of transactions to a specific shard. By analyzing these predictions, we can determine the shard with the largest number of transactions for each account. If the predictions show that the account's main transactions are within its own shard (i.e., most transactions are intra-shard transactions), then this account does not require adjustment. However, if the predictions show that the account's main transaction target shard is not its own shard (i.e., the transactions are mainly cross-shard), then an appropriate adjustment strategy needs to be adopted for the account. It is worth noting that we only perform model predictions for accounts with a high cross-shard transaction ratio in the current epoch, and use Algorithm 2 to identify the accounts that need adjustment. The shard S with the most transactions sent by this account is obtained using the following formula. target :

[0063]

[0064] Where x i x represents out The i-th value in the array, where n is the number of slices.

[0065] In implementing dynamic account adjustments, controlling load balancing across shards hinges on accurately predicting the total number of transactions initiated by all accounts within each shard in the next epoch. To achieve this, we trained a separate time-series model for each shard. The primary task of these models is to estimate the total number of transactions each shard will initiate in the next epoch. Specifically, we use STT... i This represents the total number of transactions predicted for the i-th shard in the next epoch.

[0066] Specific account adjustment strategies, such as Figure 2 As shown, the first step involves x for each account. out We sort the accounts by their maximum values ​​to determine adjustment priorities. Following this order, we evaluate each account one by one. If S... target If the current shard corresponds to the account's maximum trading volume, no adjustment is needed; otherwise, adjustment is required. The primary criterion for adjustment is the shard corresponding to the account's maximum trading volume. If the expected total trading volume (STT) of that shard in the next epoch is... target If the trading volume does not exceed the set dynamic load balancing threshold θ, an adjustment strategy will be implemented for that account. However, if the trading volume of the target shard is close to or has reached the threshold, we will consider whether there are other accounts with comparable trading volumes to the target account that are also scheduled for adjustment. In this case, we will prioritize adjusting accounts within the target shard. If no such account exists, we will adjust the trading volume based on account x. out The second largest value, i.e. the shard with the second most transactions, is used to determine the adjustment scheme.

[0067] It's worth noting that, to ensure each shard can efficiently process all transactions within an epoch, the load balancing threshold θ is set considering the shard's maximum transaction processing rate *a* (in transactions / second), the cross-chain transaction ratio γ in the system, and the duration of a single epoch, *t*. Under this framework, the maximum number of transactions a single shard can theoretically handle in one epoch is *a* × *t*. However, considering the characteristics of cross-shard transactions in the system, these transactions are typically broken down into two sub-transactions because they require relay transactions to ensure their atomicity. This means that cross-shard transactions require an additional transaction processing step compared to intra-shard transactions. Therefore, to ensure sufficient resources to handle potential cross-shard transactions, the load balancing threshold θ should be set to *a* × *t* × (1-γ). This design aims to guarantee that a shard can not only handle its own normal transactions but also has sufficient capacity to handle potential cross-shard transactions.

[0068] In one embodiment, when individual hot accounts cause overheating of a single shard, our strategy aims to effectively offload excessive cross-shard transactions from these accounts to less loaded shards for parallel processing by monitoring the load of all shards. This is done to avoid overloading the shard containing the hot account and to ensure that resources are fully utilized across every shard in the network.

[0069] Specifically, to achieve this goal, we utilized the AD-shard system, which uses a heartbeat monitoring mechanism to obtain real-time load information for each shard in the network. Heartbeat monitoring refers to each shard sending its transaction pool information to AD-shard every few seconds to collect load information for each shard. Using this mechanism, AD-shard can monitor the load status of each shard in the network in real time. When processing cross-shard transactions, AD-shard assesses the current load of the target shard. If it finds that the target shard is a hot shard and that related accounts have a large number of pending transactions, it activates the transaction balancing mechanism.

[0070] It's worth noting that AD-shard does not send these cross-shard transactions to the overloaded target shard. Instead, it redirects them to other shards with lower loads through a special balancing transaction mechanism. The shard receiving this balancing transaction temporarily activates the corresponding recipient account (account state set to 2) and is responsible for processing a batch of transactions for that account. Once the current block and transaction pool no longer contain transactions related to that account, these transactions are considered complete. These shards then initiate a migration transaction through intra-shard consensus to synchronize the processing results back to the account's primary account in the main shard and restore the sub-account to a dormant state.

[0071] It should be understood that, although Figure 1-3 The steps are shown in the order indicated by the arrows, but this does not mean that these steps must be performed in a strict order. Unless explicitly stated in the text, there are no strict restrictions on the order of execution of these steps, and they can be performed in other orders. Furthermore, Figure 1-3 Some steps in the process may contain multiple sub-steps or stages, which do not need to be completed simultaneously but can be executed at different times. Moreover, the execution order of these sub-steps or stages can also alternate with other steps or their sub-steps or stages.

[0072] In one embodiment, such as Figure 4 As shown, a time-series-based blockchain sharding account adjustment device is provided, comprising: a model building module, a transaction prediction module, an account adjustment module, and a load balancing module, wherein:

[0073] The model building module is used to train a neural network model based on the transaction records of each epoch of the account. The input of the neural network model is the number of cross-shard transactions in n consecutive epochs, and the output is the prediction of cross-shard transaction data in the (n+1)th epoch.

[0074] The transaction prediction module is used to predict the cross-shard trading behavior of a single account in the next epoch based on the transaction records of the current epoch and the previous n-1 epochs, and to dynamically adjust the account based on the prediction results.

[0075] The account adjustment module is used to dynamically adjust accounts based on prediction results. The adjustment method is to transfer the same account between different shards through a sub-account model. The account transfer is realized through cross-shard transactions and enjoys the security protection mechanism of blockchain transactions, which can ensure the safe adjustment of accounts.

[0076] The load balancing module is used to monitor the load of each shard, promptly identify and alleviate the transaction volume of overloaded shards. The method to alleviate the overload of a single shard is to temporarily activate a sub-account in a shard with a low load, so that the shard temporarily has the ability to process the transactions related to that account. After the shard has processed all transactions, the results are synchronized to the main account through account adjustment.

[0077] In one embodiment, the transaction records of each account in a sharded blockchain system in consecutive epochs are used as the training set for a time series RNN neural network to build a predictive model for each account that can predict future transaction behavior.

[0078] In one embodiment, accounts that have sent cross-shard transactions in the current epoch are obtained based on the special shard AD-shard in the system, and accounts with a high proportion of cross-shard transactions are selected to obtain the accounts that need to be adjusted in the current epoch.

[0079] In one embodiment, the transaction records of the account in recent consecutive epochs are used as input to the RNN model to predict the possible transactions of these accounts in each shard in the next epoch, and the account is adjusted at the end of each epoch based on the load of each shard.

[0080] In one embodiment, the load of each shard is monitored based on AD-shard, and a load balancing strategy is executed on the shard that is overloaded. The relevant accounts of the low-load shard are temporarily activated to process the transactions of the overloaded shard in parallel, thereby alleviating the performance overload phenomenon of a single shard.

[0081] The aforementioned time-series-based blockchain sharded account adjustment device can be implemented through software, hardware, or a combination thereof. Specific limitations can be found in the preceding description of the time-series-based financial product recommendation method. Each module can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the corresponding operations of each module.

[0082] Regarding the computer equipment used in this application, Figure 5 The structures shown are merely block diagrams of relevant parts and do not limit their specific composition. Specific computer devices may include more or fewer components than shown in the diagram, may combine certain components, or may have different component arrangements.

[0083] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps:

[0084] Based on the transaction records of each account in the sharded blockchain system in consecutive epochs, a predictive model that can predict future transaction behavior is built for each account.

[0085] Based on the special shard AD-shard in the system, obtain the accounts that have sent cross-shard transactions in the current epoch, filter out the accounts with a high proportion of cross-shard transactions, and obtain the accounts that need to be adjusted in the current epoch.

[0086] Based on the transaction records of the account in recent consecutive epochs, the RNN model is used as input to predict the transaction probability of these accounts in each shard in the next epoch, and the account is adjusted at the end of each epoch in combination with the load of each shard.

[0087] AD-shard is used to monitor the load of each shard. For shards that are overloaded, load balancing strategies are implemented. Low-load shards are temporarily activated to activate relevant accounts and process transactions of overloaded shards in parallel, thereby alleviating the performance overload of a single shard.

[0088] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. These computer programs can be stored in a non-volatile computer-readable storage medium and, when executed, include the steps of the processes in the above embodiments. In the embodiments provided in this application, references to memory, storage, databases, or other media may include non-volatile and / or volatile memory.

[0089] The embodiments described above are merely examples of specific methods of this application and do not limit the scope of this patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and all such modifications and improvements fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A time-series-based blockchain sharded account adjustment method, characterized in that, The method includes: Based on the transaction records of each account in the sharded blockchain system in consecutive epochs, a predictive model that can predict future transaction behavior is built for each account. Based on the special shard AD-shard in the system, obtain the accounts that have sent cross-shard transactions in the current epoch, filter out the accounts with a high proportion of cross-shard transactions, and obtain the accounts that need to be adjusted in the current epoch. Based on the transaction records of the account in recent consecutive epochs, the RNN model is used as input to predict the possible transactions of these accounts in each shard in the next epoch, and the account is adjusted in combination with the load of each shard. The account adjustment refers to the consensus reached by each shard participant in the sharded blockchain system on the account adjustment based on the adjustment results obtained through a neural network at the final stage of each epoch. The account adjustment methods mentioned include: In a Patricia tree with a state field, an adjustment method based on a sub-account model is implemented. In the sharded blockchain system, an account is allowed to exist in multiple shards. The adjustment of the account can be achieved by transferring the balance of the main account to the sub-account in the form of a transaction, and then setting the sub-account as the main account, thereby completing the dynamic adjustment of the account in different shards. The Patricia tree with a state includes: In a blockchain system based on the account / balance model, the state tree is maintained by a Patricia tree. The non-leaf nodes of the Patricia tree with state remain unchanged, and a state field is added to the leaf nodes that represent the state to identify the account in three states: active, dormant, and temporarily active. The same account can only be active in one shard, which is called the master account. The AD-shard is a special type of shard used for forwarding cross-shard transactions in the system, including: Participants in special shards store the addresses of each participant in the shard and the shard where each main account is located locally. They are responsible for receiving and forwarding cross-shard transactions in the system, recording all cross-shard transactions, communicating with each shard in real time, monitoring the load balancing of the shard transaction pool, and running load balancing algorithms to maintain the load balancing of each shard. The load balancing algorithm refers to the balancing strategy employed when a single shard experiences excessive load, including: Based on the real-time load of the shards monitored by AD-shard, when a shard is overloaded at a certain moment, AD-shard will run a load balancing algorithm and will no longer send cross-shard transactions related to that shard to that shard. Instead, it will temporarily activate the relevant sub-accounts of the shards with lower loads to process the transactions in batches. After the processing is completed, the transactions will be adjusted through the accounts to synchronize the processing results to the main account.

2. A time-series-based blockchain sharded account adjustment device, used to implement the method of claim 1, characterized in that, The device includes: The model building module is used to train a neural network model based on the transaction records of each epoch of the account. The input of the neural network model is the number of cross-shard transactions in n consecutive epochs, and the output is the prediction of cross-shard transaction data in the (n+1)th epoch. The transaction prediction module is used to predict the cross-shard trading behavior of a single account in the next epoch based on the transaction records of the current epoch and the previous n-1 epochs, and to dynamically adjust the account based on the prediction results. The account adjustment module is used to dynamically adjust accounts based on prediction results. The adjustment method is to transfer the same account between different shards through a sub-account model. The account transfer is realized through cross-shard transactions and enjoys the security protection mechanism of blockchain transactions, which can ensure the safe adjustment of accounts. The load balancing module is used to monitor the load of each shard, promptly identify and alleviate the transaction volume of overloaded shards. The method to alleviate the overload of a single shard is to temporarily activate a sub-account in a shard with a low load, so that the shard temporarily has the ability to process the transactions related to that account. After the shard has processed all transactions, the results are synchronized to the main account through account adjustment.

3. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method of claim 1.

Images