Account Migration-Based Blockchain Sharding Method and Blockchain System

Abstract

This application discloses a blockchain sharding method and system based on account migration. It uses historical transaction data to predict future transaction volumes of accounts, and continuously redistributes the accounts with the largest transaction volumes in the heaviest-loaded shards to the lightest-loaded shards based on these predictions, minimizing account redistribution to maximize system load balancing. A secure and efficient account migration mechanism is proposed, enabling rapid account migration between shards while maintaining security, without excessive performance loss. The method disclosed in this application overcomes the problem of unbalanced transaction loads in traditional blockchain sharding, effectively improving the throughput of the blockchain system and reducing transaction confirmation latency.

Description

Technical Field

[0001] This invention belongs to the field of blockchain sharding technology application, and particularly relates to a blockchain sharding method and blockchain system based on account migration. Background Technology

[0002] Blockchain is essentially a chain-like data structure that links data blocks sequentially in chronological order, and is a distributed ledger that is cryptographically guaranteed to be immutable and unforgeable. Blockchain networks are typically maintained by a group of peer-to-peer nodes, and are characterized by decentralization, immutability, traceability, and transparency. However, traditional blockchain systems suffer from low throughput and scalability.

[0003] Blockchain sharding aims to solve the scalability problem in traditional blockchain systems. Its core idea is to divide the nodes in a blockchain system into several groups (also called shards). Each shard stores a different subset of the entire blockchain state, executes different transactions, reaches consensus in parallel, and generates its own shard chain. Through this parallel processing, sharding improves the scalability of traditional blockchains in terms of storage, computation, network, and transactions per second (TPS).

[0004] In account-based blockchain sharding networks, each shard maintains transactions for several accounts. Transactions sent by the same account are mapped to the corresponding shard based on the account's shard address for processing. However, while existing sharding protocols can improve blockchain throughput, a significant gap remains between current performance and potential throughput optimization. Ideally, system throughput growth should be proportional to the number of shards, but in reality, existing sharding protocols result in throughput losses exceeding 30%, thus reducing scalability. More importantly, these sharding protocols neglect another crucial system performance issue: improving user-perceived Transaction Confirmation Delay (TCD). TCD refers to the time delay between a user sending a transaction and its submission to the chain. Existing sharding protocols still suffer from high latency, with user-perceived TCDs exceeding hundreds of seconds, leading to a poor user experience.

[0005] Cross-shard transactions and transaction load imbalance are considered two important factors affecting system performance. Cross-shard transactions incur additional communication overhead, while transaction load imbalance refers to an imbalance in the number of transactions processed by different shards, causing some shards to exceed their processing capacity. However, much current research on blockchain sharding protocols has not analyzed the extent to which these two factors affect system performance, or which factor dominates the impact. Furthermore, these studies have not been validated on real-world blockchain systems. The few studies on transaction load imbalance that exist only propose account allocation algorithms based on account models, without addressing how to migrate accounts.

[0006] Existing sharding protocols still suffer from severe load imbalance, which limits system performance improvement. In real systems, account allocation algorithms alone are insufficient. More importantly, a secure and efficient account migration protocol must be designed to enable accounts and transactions to migrate between shards in a real-world manner to achieve system load balancing. Summary of the Invention

[0007] Based on this, the present invention proposes a blockchain sharding method and blockchain system based on account migration, and proposes a secure and efficient account allocation algorithm and account migration scheme to allocate as few accounts as possible to improve the transaction load balance of the system.

[0008] In a first aspect, the present invention provides a blockchain sharding method based on account migration, which is performed at an allocation server and is used to perform transaction prediction and account allocation, including:

[0009] Transaction prediction process:

[0010] Step S100. Obtain the historical transaction volume of each account and select the first account according to preset conditions;

[0011] Step S200. Predict the future trading volume of the first account based on historical trading volume, and record it as the predicted trading volume of the first account;

[0012] Account allocation process:

[0013] Step S300. Initialize the transaction load of each shard and the load balance of the blockchain shard network;

[0014] Step S400. If the transaction load of the heaviest shard is greater than the set value, proceed to step S500; otherwise, proceed to step S600.

[0015] Step S500. Select the first account in the heaviest load shard and reallocate it to the lightest load shard and update the load balance until the load balance no longer increases;

[0016] Step S600. Broadcast the account allocation results to each shard.

[0017] Further, step S500 includes:

[0018] Step S510. Sort the first account in the heaviest shard in descending order according to the total transaction volume;

[0019] Step S520. Take a first account without replacement and redistribute it to the lightest-loaded shard according to the arrangement order determined in step S510;

[0020] Step S530. Update the load balance. If the load balance does not increase, update the transaction load and account information of each shard and return to step S400; otherwise, return to step S520.

[0021] Further, step S530 includes:

[0022] Step S531. Update load balancing;

[0023] Step S532. If the load balancing does not increase, update the transaction load and account information of each shard and proceed to step S533; otherwise, proceed to step S534.

[0024] Step S533. Based on the transaction load updated in step S532, redetermine the heaviest and lightest shards, and return to step S400;

[0025] If not all first accounts are retrieved in step S534. If not, return directly to step S520; otherwise, exclude the currently determined heaviest load fragment, re-determine the heaviest load fragment and the lightest load fragment, and return to step S400.

[0026] Furthermore, the preset condition is the highest historical transaction volume. Individual accounts.

[0027] Furthermore, step S100 also includes:

[0028] Consolidate accounts that are not the first account within the segment into a second account.

[0029] Furthermore, step S200 also includes:

[0030] The future trading volume of the second account is predicted based on historical trading volume, and is denoted as the predicted trading volume of the second account.

[0031] Further, step S200 uses an LSTM network to predict transactions for the first account and / or the second account.

[0032] Furthermore, the calculation of load balancing degree includes:

[0033] The transaction load of each shard is calculated based on the historical transaction volume and transaction forecast of the first account and the transaction forecast of the second account. The variance of the transaction load is recorded as the load balance.

[0034] Secondly, the present invention provides a blockchain sharding method based on account migration, which is performed in the source shard of a blockchain sharding network and includes:

[0035] Receive the account allocation results broadcast by the allocation server:

[0036] The migration account will be determined based on the account allocation results;

[0037] Initiate an account migration transaction and complete consensus within the shard;

[0038] Based on the account allocation results, send the account migration transaction that has reached consensus to the corresponding target shard, and delete the migrated account and its account status in the source shard.

[0039] Furthermore, initiating an account migration transaction and completing intra-shard consensus includes:

[0040] An account migration transaction is generated by at least one node within the shard;

[0041] The block generating node packages the account migration transactions it generates into a block and broadcasts the block within the shard;

[0042] Each node within a shard reaches consensus on the block.

[0043] Furthermore, the consensus reached by the nodes within a shard on the block includes:

[0044] Each node must verify at least the following information:

[0045] The sending and receiving accounts of the transaction are the same, the signature information of the block generating node, the transfer value of the account migration transaction is equal to the balance of the migration account, and the source and target shards of the migration account are consistent with the account allocation result.

[0046] Furthermore, to ensure the security of account migration transactions, the information verified by each node also includes:

[0047] The sequence numbers of migration transactions are consecutive.

[0048] Furthermore, the second aspect of the method also includes:

[0049] Send the queued transactions for the migration account to the target shard.

[0050] Thirdly, the present invention provides a blockchain sharding method based on account migration, which is performed in a target shard of a blockchain sharding network and includes:

[0051] Receive account migration transactions sent by the source fragment;

[0052] Establish the account status of the migrated account in the shard based on the account migration transaction.

[0053] Furthermore, the third aspect of the approach also includes:

[0054] Receive and execute queued transactions for migration accounts.

[0055] Furthermore, the third aspect of the approach also includes:

[0056] Adjust the execution priority of account migration transactions to the highest level, so that shards execute immediately upon receiving an account migration transaction.

[0057] Fourthly, the present invention provides a blockchain system, including an allocation server, the allocation server comprising the following modules:

[0058] The transaction monitoring and prediction module is used to implement the transaction prediction process in the first aspect of the method;

[0059] The account allocation module is used to implement the account allocation process in the method of the first aspect.

[0060] Fifthly, the present invention provides a blockchain system including an allocation server and at least two shards, wherein the two shards are a source shard and a target shard;

[0061] The allocation server is used to implement the first aspect of the blockchain sharding method based on account migration, the source shard is used to implement the second aspect of the blockchain sharding method based on account migration, and the target shard is used to implement the third aspect of the blockchain sharding method based on account migration.

[0062] In a sixth aspect, the present invention provides an electronic device, including a memory and a processor;

[0063] The memory is used to store programs;

[0064] The processor is used to execute the program to implement the various steps of the aforementioned blockchain sharding method based on account migration.

[0065] In a seventh aspect, the present invention provides a readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the various steps of the aforementioned blockchain sharding method based on account migration.

[0066] Compared with existing fragmentation protocols, the present invention has the following advantages:

[0067] The blockchain sharding method and system based on account migration provided by this invention predicts the future transaction volume of accounts, allocates a small number of accounts based on the predicted transaction volume to improve system load balancing, and proposes a secure and efficient account migration mechanism. This mechanism enables the system to quickly migrate accounts between shards while ensuring security, without sacrificing excessive system performance. By implementing this invention, the problem of unbalanced transaction load in traditional blockchain sharding can be overcome, effectively improving the throughput of the blockchain system and reducing transaction confirmation latency. Attached Figure Description

[0068] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0069] Figure 1 The blockchain system framework provided in the embodiments of the present invention;

[0070] Figure 2 An implementation process for a blockchain sharding method based on account migration provided in this embodiment of the invention;

[0071] Figure 3 Another implementation process of a blockchain sharding method based on account migration provided by an embodiment of the present invention;

[0072] Figure 4 Another implementation process of a blockchain sharding method based on account migration provided by an embodiment of the present invention;

[0073] Figure 5 A schematic diagram of a blockchain system structure provided for an embodiment of the present invention;

[0074] Figure 6 This invention provides an implementation process for allocating accounts to hot accounts.

[0075] Figure 7 and Figure 8 This is a specific scenario example diagram illustrating an embodiment of the present invention;

[0076] Figure 9 This is a hardware structure block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0077] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0078] A blockchain sharding network divides nodes in a blockchain system into several groups, or shards. Each shard maintains its independent state and transaction history and executes different transactions in parallel. Currently, there are two main models for allocating transactions to different shards: the UTXO model and the account model. The UTXO model allocates transactions to shards based on transaction IDs, while the account model allocates them based on the sending account. Different shards maintain different accounts, so transactions sent by the same account will be allocated to the same shard. Because the account model offers better scalability, the following embodiments of this invention are all based on the account model.

[0079] Through extensive data research, the applicant discovered that unbalanced transaction load is the main reason for the performance degradation of sharded networks. Since different shards maintain different accounts, and a small number of accounts often generate most of the transactions in the entire system, the shards where the accounts that generate a large number of transactions are located are prone to overload, resulting in uneven transaction load across the system's shards.

[0080] To address the above problems, this invention proposes a novel blockchain sharding method and blockchain system, which will be described in detail in the following embodiments.

[0081] like Figure 1 As shown, the basic framework of the blockchain system of the present invention is illustrated, including an allocation server 100 and a shard network 200. In order to balance the load on different shards, the allocation server 100 periodically allocates accounts, predicts the number of transactions of an account, and determines which shard an account should be allocated to based on the prediction results. In order to truly improve the load balancing of the blockchain shard network, the source shard in the shard network 100 performs account migration according to the account allocation results, migrating the migrated accounts from the source shard to the newly allocated target shard, and correspondingly, the transactions of these accounts are also sent to the target shard for execution.

[0082] It's easy to understand that a source shard can also be a target shard, and a target shard can also be a source shard. A source shard in the current epoch can be a target shard in other epochs, and a target shard in the current epoch can also be a target shard in other epochs.

[0083] based on Figure 1 The system framework shown, Figure 2 This illustration shows an implementation flow of a blockchain sharding method based on account migration provided by an embodiment of the present invention. The process is performed at the allocation server and mainly involves transaction prediction and account allocation. The flow may include:

[0084] Step S10. Obtain the historical transaction volume of each account and select the first account according to the preset conditions.

[0085] Specifically, the server is assigned to connect to several nodes in each shard to synchronize historical transaction data generated in the shard network, and the historical transaction data is integrated according to the account, and the first account is selected based on the integration result.

[0086] In a real blockchain system, it is not feasible to predict transactions for all accounts because there are millions of accounts in a real system. More importantly, the vast majority of accounts only generate a small number of transactions, while a small number of accounts generate the majority of transactions. According to the applicant's calculations, less than 0.02% of accounts sent more than half of the transactions. Predicting transactions and allocating accounts only for a portion of the accounts can effectively reduce the computational complexity.

[0087] The preset conditions can be selected based on the account's transaction volume or transaction time. Specifically, in this embodiment of the invention, the first account is selected based on the account's historical transaction volume, and the preset condition is set to the account with the highest historical transaction volume. Individual accounts.

[0088] Step S11. Predict the future trading volume of the first account based on historical trading volume, and record it as the predicted trading volume of the first account.

[0089] Specifically, machine learning can be used for transaction prediction. In a further embodiment, a two-layer LSTM model can be used to predict the transaction volume of an account in future epochs.

[0090] Step S12. Initialize the transaction load of each shard and the load balance of the blockchain shard network.

[0091] Specifically, the transaction load of each shard can be calculated based on the transaction volume of the first and second accounts, and the load balance can be calculated based on the transaction load of each shard. The load balance reflects the degree of difference in transaction load between shards; the greater the difference, the more unbalanced the load.

[0092] This step, which calculates the transaction load for sharding, reflects the transaction volume to be processed in the upcoming epoch sharding. Therefore, in the embodiments of the present invention, the transaction volume of the first account can be calculated based on the transaction forecast. Furthermore, considering that the first account is the migration target, in order to ensure that transaction verification can be completed smoothly after the account migration, transactions that are still in the queue and have not been verified for the migration account are also included as part of the sharding transaction load.

[0093] Step S13. If the transaction load of the heaviest shard is greater than the set value, proceed to step S14; otherwise, proceed to step S15.

[0094] Specifically, in order to minimize the number of accounts to be migrated, this embodiment of the invention prioritizes migrating accounts in the shard with the heaviest load when allocating accounts, and sets the migration condition to be when the transaction load of the shard exceeds a set value.

[0095] Step S14. Select the first account in the heaviest-loaded shard and reallocate it to the lightest-loaded shard and update the load balance until the load balance no longer increases.

[0096] Specifically, only one account is allocated in each calculation, and the load balancing is updated after each allocation to determine whether to retain the allocation result and further prioritize the allocation of the first account with the largest historical transaction volume.

[0097] Step S15. Broadcast the account allocation results to each shard.

[0098] Furthermore, for accounts other than the first account, they are integrated into an aggregated account for each shard, referred to as the second account. The allocation server also performs transaction predictions for the second account, but it is not considered in the account allocation.

[0099] Furthermore, when calculating the transaction load of a shard, the transaction volume of the second account can include the transaction volume in the queue of the second account, as well as the transaction forecast volume of the second account.

[0100] Furthermore, step S14 includes the following processes:

[0101] Step S141. Sort the first account in the heaviest shard in descending order according to the total transaction volume.

[0102] Step S142. Take a first account without replacement and redistribute it to the lightest-loaded shard according to the arrangement determined in step S141.

[0103] Specifically, the purpose of taking out the first account without replacement is that if the first account taken out cannot reduce the load balance, the account will not be redistributed, and the next first account will be taken out in sequence. Since the first accounts have been sorted in descending order of total transaction volume in step S141, how can we ensure that the account with the largest total transaction volume in the shard is allocated each time, so as to maximize the load balance?

[0104] Step S143. Update the load balance. If the load balance does not increase, update the transaction load and account information of each shard and return to step S13; otherwise, return to step S142.

[0105] Specifically, when the allocation result of step S142 meets the requirements for reducing load balancing, the allocation result will be retained and will trigger changes to the account information maintained by each shard. Transactions initiated by the reassigned account will be routed to the new shard. Therefore, it is necessary to update the transaction load and account information of each shard according to the allocation result to form the account allocation result.

[0106] Furthermore, step S143 may include the following processes:

[0107] Step S1431. Update load balancing;

[0108] Step S1432. If the load balancing does not increase, update the transaction load and account information of each shard and proceed to step S1433; otherwise, proceed to step S1434.

[0109] Step S1433. Based on the transaction load updated in step S1432, redetermine the heaviest and lightest shards, and return to step S13;

[0110] If not all first accounts are retrieved in step S142, return directly to step S142; otherwise, exclude the currently determined heaviest load fragment, re-determine the heaviest load fragment and the lightest load fragment, and return to step S13.

[0111] See Figure 3 , Figure 3 This invention illustrates an implementation flow of a blockchain sharding method based on account migration, performed at the source shard of the sharding network. The flow may include:

[0112] Step S20. Receive the account allocation results broadcast by the allocation server.

[0113] Specifically, the allocation server connects to several nodes in the shard. At the beginning of each epoch, each node in the shard receives the account allocation results for the current epoch from the allocation server and caches them in its own local block for use in the subsequent consensus process.

[0114] Step S21. Determine the migration account based on the account allocation results.

[0115] Specifically, based on the account allocation results, the node compares which accounts maintained by its own shard have been allocated to other shards in the current epoch and determines these accounts as migration accounts.

[0116] Step S22. Initiate an account migration transaction and complete consensus within the shard.

[0117] Specifically, in order to address security issues related to account migration, such as malicious nodes initiating erroneous migration transactions, sending the same transaction multiple times (replay attack), or refusing to send transactions (silence attack), this embodiment of the invention designs a consensus mechanism that requires the completion of account migration transactions within a shard before the actual account migration.

[0118] Specifically, consensus within a shard can employ common consensus mechanisms. However, unlike conventional verification information, account migration transactions also include other fields that need to be verified to ensure the accuracy of the account migration. These fields include that the sending account and receiving account of the transaction are the same, the signature information of the block generating node, the transfer value of the account migration transaction equals the balance of the migrating account, and the source and target shards of the migrating account are consistent with the account allocation results.

[0119] Step S23. Based on the account allocation results, send the account migration transactions that have completed consensus to the corresponding target shards.

[0120] Furthermore, step S22 can have the following process:

[0121] At least one node within a shard generates an account migration transaction. The block generating node packages its generated account migration transaction into a block and broadcasts the block within the shard. All nodes within the shard reach a consensus on the broadcast block.

[0122] Furthermore, considering that malicious nodes can save account migration transactions and resend them later to launch a replay attack, an additional field is added to the account migration transaction to maintain its sequence number in the account migration transaction (referred to as the migration random number in this embodiment of the invention). The migration random number should be maintained in the state of each account. When consensus is reached within the shard, each node must verify whether the migration transaction of a certain account has a continuous migration random number. Only if the migration random number is continuous can the account migration transaction pass the verification.

[0123] Furthermore, considering another malicious behavior, namely, a malicious node in the source shard does not send verified account migration transactions to the target shard, this embodiment of the invention also designs an inquiry mechanism when such behavior occurs. If the client does not receive transaction confirmation information within the timeout period, or if the target shard has received the account allocation result and determined that an account has been migrated but has not received the account migration transaction within the timeout period, it can send a notification to the source shard. After receiving the notification, the node in the source shard resends the account migration transaction.

[0124] Furthermore, after an account is migrated, its account status in the source shard will be cleared. This will cause the verification of its queued but incomplete transactions in the source shard to fail, resulting in discontinuous transaction sequence numbers. Consequently, the verification of subsequent transactions of the account will fail, leading to a loss of system throughput. To solve this problem, after the account migration transaction is completed, the queued transactions of the migrated account in the source shard are also sent to the target shard.

[0125] Furthermore, when a client wants to query its account information or transaction status, it can send a request to the blockchain system. The nodes will route the request to the corresponding shard based on the account allocation results, and the shard will return the query results to the client.

[0126] Furthermore, to encourage shard nodes to package account migration transactions, nodes that package account migration transactions into blocks can receive system rewards.

[0127] See Figure 4 , Figure 4 This invention illustrates an implementation flow of a blockchain sharding method based on account migration, performed on a target shard of a sharding network. The flow may include:

[0128] Step S31. Receive the account migration transaction sent by the source fragment.

[0129] Specifically, in order to improve the processing efficiency of account migration transactions and thus improve the status update of the migrated account and the verification of the transaction, the present invention addresses the issue that if the waiting time for an account migration transaction is too long, it will inevitably prolong the migration process, reduce throughput, and increase latency. Therefore, upon receiving an account migration transaction, its priority is adjusted to the highest level so that it can be executed immediately upon receipt.

[0130] Step S32. Establish the account status of the migration account in the shard based on the account migration transaction.

[0131] Furthermore, in addition to establishing the status of the migration account in the target shard, the target shard will also receive and execute queued transactions from the migration account in the source shard.

[0132] based on Figure 1 The system framework shown and Figure 5 The diagram illustrates the interaction of the blockchain system structure. The following embodiments further illustrate the blockchain sharding method based on account migration of the present invention.

[0133] exist Figure 5The illustrated structure includes an allocation server 300 and shards A, B, and C. The allocation server 300 connects to each node in shards A, B, and C to synchronize transaction data and return account allocation results to the nodes. For illustration purposes, each shard is designed with four nodes: nodes A1 to A4 for shard A, nodes B1 to B4 for shard B, and nodes C1 to C4 for shard C.

[0134] The allocation server 300 includes a transaction monitoring and prediction module 310 and an account allocation module 320. Before allocating accounts, the allocation server 300 periodically synchronizes historical transaction data. Specifically, synchronization can be performed at the beginning of each epoch. The historical transaction data is used to predict the trading volume of an account in future epochs.

[0135] The transaction monitoring and prediction module 310 statistically analyzes the historical transaction volume of each account based on historical transaction data and selects... The account that generated the most transactions, An account that generates more than half of the transactions on the system is referred to as a hot account in this embodiment. For the non-hot accounts maintained by each shard, they are integrated to generate an aggregate account.

[0136] Machine learning can be used to predict trading volume for hot and aggregated accounts, allowing predictions of trading volume for a single epoch or multiple epochs at once. In this embodiment, a two-layer LSTM model is used for prediction, with each layer consisting of 100 neurons and a dropout of 0.001. In a further embodiment, since machine learning is computationally intensive and time-consuming, the prediction interval can be increased to improve the accuracy of the prediction results when multiple epochs of trading volume need to be predicted at once.

[0137] The following derivation illustrates the specific implementation of the account allocation process. In this embodiment, to reduce the complexity of system operations, allocation and migration are performed only for hot accounts.

[0138] First, the account allocation problem of the system can be expressed as the following objective function:

[0139] (1)

[0140] The objective function aims to minimize the value at epoch. The variance of transaction load between shards improves system load balancing. For accounts... , This represents a collection of accounts on the system. Indicates account In epoch The predicted transaction volume in the middle, Indicates account In epoch Queued transaction volume in the middle; for sharding , Represents the set of system fragments. Indicates whether the account is located in a shard. Indicates account Located in the partition ,on the contrary This indicates the account Not located in fragments ;definition For account In epoch Total transaction volume For epoch The average transaction load of the middle shard is expressed as follows (2):

[0141] (2)

[0142] Based on the objective function described above, the account allocation problem can be simplified to a k-partition problem, which is an NP-hard problem and can be solved using heuristic algorithms.

[0143] Since account allocation only applies to frequently accessed accounts, aggregated accounts remain on the original shards, and the goal is to allocate as few accounts as possible to maximize load balancing, this is defined in epochs. The load balancing expression in the code is as follows:

[0144] (3)

[0145] It is easy to understand that the load balancing degree defined in this embodiment is reflected by the variance of the transaction load of the shards, which is different from Equation (1). In Equation (3), Represents the set of hot accounts. Indicates fragmentation Centralized account in epoch Transaction prediction volume in epoch Average transaction load in sharding The calculation uses the following formula (4):

[0146] (4)

[0147] See Figure 6 Based on the above calculations and derivations, the account allocation process for hot accounts is explained as follows:

[0148] Step S400. Obtain parameters , , , , , , , .

[0149] Step S401. Based on epoch Account allocation and epochs The transaction forecast situation, for epoch The parameters are initialized as follows:

[0150]

[0151] Step S402. Based on the sharded transaction load For fragments Sorting in descending order to form a fragmented list Determine the heaviest load fragment and the lightest load fragment .

[0152] Step S403. Based on the total transaction volume of the account For the heaviest shard Sort the accounts in descending order to form an account list. .

[0153] Step S404. Calculation , If the condition is met, proceed to step S405; otherwise, proceed to step S409.

[0154] Step S405. In Retrieve one account in sequence without replacement , When all funds in the account are withdrawn, proceed to step S408.

[0155] Step S406. Retrieve the account information obtained in step S405. Assigned to ,renew .

[0156] Step S407. At that time, Update shard transaction load, , , , If the condition is met, return to step S404; otherwise, return to step S405.

[0157] Step S408. Put Remove Re-determine , , Return to step S404.

[0158] Step S409. Output each .

[0159] Based on the above Figure 6 The explanation is easy to understand: in each round of account allocation, the most active accounts with the largest total trading volume are selected from the heaviest-loaded shard and redistributed to the lightest-loaded shard. If the allocation result can improve load balancing (i.e. reduce...), then... If the allocation result is not met, the allocation result is retained; otherwise, the account with the second highest total transaction volume is selected in sequence. If all the hot accounts in the initially determined heaviest shard cannot improve the load balancing, the above algorithm will attempt to allocate hot accounts in the less loaded shards. It is monotonically decreasing, and only Account migration only occurs when the number of accounts decreases, so the algorithm will eventually converge and stop allocating hot accounts.

[0160] Each node in shards A, B, and C will receive the account allocation results output by allocation server 300 at the beginning of each shard. If an account is assigned to a new shard that is different from the shard assigned in the previous epoch, then the account should be migrated from the previous shard (i.e., the source shard) to the new shard (i.e., the target shard).

[0161] Each shard maintains multiple accounts. Nodes within a shard maintain the account status and process transactions generated by those accounts. Account status includes basic account information such as balance and transaction sequence number. Each transaction contains the following basic fields: sending account, receiving account, transaction sequence number, transfer amount, and signature. When a transaction is packaged into a block, nodes verify (consensus) the transaction to check if the sender has sufficient balance, if the transaction sequence number is consecutive, and if the signature is correct. The transaction sequence number should be consecutive to ensure transaction security.

[0162] In this embodiment, in order to efficiently and securely share account states between shards to achieve account migration, an account migration transaction is proposed. Consensus needs to be completed within the shard before the account migration transaction is sent to the corresponding target shard.

[0163] In addition to the basic verification information mentioned above, each account migration transaction also requires consensus on the following fields: the sending account and the receiving account are the same, the signature information of the block generating node, the transfer value of the account migration transaction is equal to the balance of the migration account, the source shard and the target shard of the migration account are consistent with the account allocation result, and the migration random number is continuous.

[0164] During account migration, each node in the source shard (e.g., shard A, B, or C) generates an account migration transaction locally and signs it using its own signature. The block-generating node packages its generated account migration transaction along with other normal transactions into a block and initiates block consensus within the shard. After the source shard completes consensus, it sends the account migration transaction to the target shard (e.g., A, B, or C) corresponding to the account allocation result. The source shard deletes the migrated account, while the target shard constructs the migrated account and updates its account status. If a client wants to query its account or transaction status, it can send a request to the blockchain network. Nodes route the request to the corresponding shard based on the account allocation result, and the shard returns the query result to the client.

[0165] Because account migration takes time, during the migration process, new transactions generated by the migrated account will fail to be verified due to the unupdated account status in the target shard (account migration transactions awaiting packaging). This failure to verify these new transactions leads to discontinuous transaction sequence numbers, again resulting in significant throughput loss. Therefore, new transactions for migrating accounts will wait in the target shard's transaction queue, and their priority will be adjusted to the highest level, ensuring immediate execution upon receipt by the target shard. Furthermore, queued transactions for migrating accounts in the source shard will be sent to the target shard after the account migration is complete.

[0166] Figure 7 The blockchain sharding method described in the above embodiments will be introduced through specific scenarios.

[0167] See Figure 7 Shard A maintains accounts a1, a2, and a3; shard B maintains accounts b1, b2, and b3; and shard C maintains accounts c1, c2, and c3. In a certain account allocation, account a1 is migrated from shard A to shard C, account b2 is migrated from shard B to shard C, and account c3 is migrated from shard C to shard A.

[0168] The account allocation results have been broadcast to all nodes in each shard, allowing each shard to initiate account migration transactions and reach consensus. In shard A, node A1 initiates the transaction consensus and sends the account migration transaction to shard C; in shard B, node B2 initiates the transaction consensus and sends the account migration transaction to shard C; and in shard C, node C3 initiates the transaction consensus and sends the account migration transaction to shard A.

[0169] Figure 8 This example illustrates another scenario of the blockchain sharding method described in this application.

[0170] Figure 8 The examples are roughly the same as Figure 7Similarly, the difference is that node A1, which is responsible for initiating block consensus in shard A, is a malicious node that refuses to send account migration transactions after consensus is reached, causing shard C to be unable to receive transactions.

[0171] The timeout limit is set to 10 minutes. After 10 minutes, shard C sends a notification to shard A because it has not received the account migration transaction. All nodes in shard A can receive the notification. Node A3 packages the account migration transaction it generated into a block and initiates consensus in shard A. After the consensus is completed, the transaction is sent to shard C.

[0172] The blockchain system provided in this application embodiment can be applied to electronic devices. Figure 9 The hardware structure block diagram of this electronic device is shown below, for reference. Figure 9 The hardware structure of an electronic device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0173] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;

[0174] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0175] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0176] The memory stores a program, which the processor can call. The program is used to: implement the various processing flows of the aforementioned allocation server in the blockchain sharding scheme, or implement the various processing flows of the aforementioned source shard and / or target shard in the blockchain sharding scheme.

[0177] This application embodiment also provides a storage medium that can store a program suitable for execution by a processor. The program is used to: implement the various processing flows of the aforementioned allocation server in the blockchain sharding scheme, or to implement the various processing flows of the aforementioned source shard and / or target shard in the blockchain sharding scheme.

[0178] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0179] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain sharding method based on account migration, characterized in that, The method, performed at the allocation server, is used to execute transaction prediction and account allocation, including: Transaction prediction process: Step S100. Obtain the historical transaction volume of each account and select the first account according to preset conditions; Step S200. Predict the future trading volume of the first account based on historical trading volume, and record it as the predicted trading volume of the first account; Account allocation process: Step S300. Initialize the transaction load of each shard and the load balance of the blockchain shard network; Step S400. If the transaction load of the heaviest shard is greater than the set value, proceed to step S500; otherwise, proceed to step S600. Step S500. Select the first account in the heaviest load shard and reallocate it to the lightest load shard and update the load balance until the load balance no longer increases; Step S500 includes: Step S510. Sort the first account in the heaviest shard in descending order according to the total transaction volume; Step S520. Take a first account without replacement and redistribute it to the lightest-loaded shard according to the arrangement order determined in step S510; Step S530. Update the load balancing degree. If the load balancing degree does not increase, update the transaction load and account information of each shard and return to step S400; otherwise, return to step S520. Step S530 includes: Step S531. Update the load balancing degree; Step S532. If the load balancing does not increase, update the transaction load and account information of each shard and proceed to step S533; otherwise, proceed to step S534. Step S533. Based on the transaction load updated in step S532, redetermine the heaviest and lightest shards, and return to step S400; If not all first accounts are retrieved in step S534. If not, return directly to step S520; otherwise, exclude the heaviest load fragment determined in this step, re-determine the heaviest load fragment and the lightest load fragment, and return to step S400. Step S600. Broadcast the account allocation results to each shard.

2. The blockchain sharding method based on account migration according to claim 1, characterized in that, The preset condition is the highest historical transaction volume. Individual accounts.

3. The blockchain sharding method based on account migration according to claim 1, characterized in that, Step S100 further includes: Consolidate accounts that are not the first account within the segment into a second account.

4. The blockchain sharding method based on account migration according to claim 3, characterized in that, Step S200 further includes: The future trading volume of the second account is predicted based on historical trading volume, and is denoted as the predicted trading volume of the second account.

5. The blockchain sharding method based on account migration according to claim 1 or 3, characterized in that, Step S200 uses an LSTM network to predict transactions for the first account and / or the second account.

6. The blockchain sharding method based on account migration according to claim 4, characterized in that, The calculation of the load balancing degree includes: The transaction load of each shard is calculated based on the historical transaction volume and transaction forecast of the first account and the transaction forecast of the second account. The variance of the transaction load is recorded as the load balance.

7. A blockchain sharding method based on account migration, characterized in that, The method is performed in the source shard of the blockchain sharding network, including: Receive the account allocation result obtained by the allocation server using the blockchain sharding method based on account migration according to any one of claims 1 to 6: The migration account is determined based on the account allocation results; Initiate an account migration transaction and complete consensus within the shard; Based on the account allocation results, the account migration transaction that has reached consensus is sent to the corresponding target shard, and the migrated account and its account status in the source shard are deleted.

8. The blockchain sharding method based on account migration according to claim 7, characterized in that, The process of initiating an account migration transaction and completing intra-shard consensus includes: An account migration transaction is generated by at least one node within the shard; The block generating node packages the account migration transactions it generates into a block and broadcasts the block within the shard; Each node within a shard reaches a consensus on the block.

9. The blockchain sharding method based on account migration according to claim 8, characterized in that, The consensus reached by the nodes within the shard for the block includes: Each node must verify at least the following information: The sending and receiving accounts of the transaction are the same, the signature information of the block generating node, the transfer value of the account migration transaction is equal to the balance of the migration account, and the source and target shards of the migration account are consistent with the account allocation result.

10. The blockchain sharding method based on account migration according to claim 9, characterized in that, The information verified by each node also includes: The sequence numbers of migration transactions are consecutive.

11. The blockchain sharding method based on account migration according to claim 7, characterized in that, The method further includes: Send the queued transactions of the migration account to the target shard.

12. A blockchain sharding method based on account migration, characterized in that, The method is performed in a target shard of a blockchain sharding network, including: The source fragment receives the account migration transaction sent using the method of any one of claims 7 to 11; The account status of the migrated account in the target shard is established based on the account migration transaction.

13. The blockchain sharding method based on account migration according to claim 12, characterized in that, The method further includes: Receive and execute queued transactions for the migration account.

14. The blockchain sharding method based on account migration according to claim 12, characterized in that, The method further includes: Adjust the execution priority of the account migration transaction to the highest level, so that the target shard executes the transaction immediately upon receiving it.

15. A blockchain system, characterized in that, The allocation server includes the following modules: A transaction monitoring and prediction module is used to implement the transaction prediction process in any one of claims 1 to 6; An account allocation module is used to implement the account allocation process in any one of claims 1 to 6.

16. A blockchain system, characterized in that, It includes an allocation server and at least two shards, which are divided into a source shard and a target shard; The allocation server is used to implement the blockchain sharding method based on account migration as described in any one of claims 1 to 6, the source shard is used to implement the blockchain sharding method based on account migration as described in any one of claims 7 to 11, and the target shard is used to implement the blockchain sharding method based on account migration as described in any one of claims 12 to 14.

17. An electronic device, characterized in that, Including memory and processor; The memory is used to store programs; The processor is configured to execute the program to implement the blockchain sharding method based on account migration as described in claims 1-6, and / or claims 7-11, and / or claims 12-14.

18. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the blockchain sharding method based on account migration as described in claims 1 to 6, and / or claims 7 to 11, and / or claims 12 to 14.

Images