Transaction processing optimization method based on fragmented block chain

Abstract

The invention relates to the technical field of fragmentation, and relates to a transaction processing optimization method based on a fragmented block chain. The method comprises the following steps: 1) learning historical transaction data of a hot account by using machine learning; 2) predicting the future transaction quantity of the hot account, and performing account distribution according to a prediction result; 3) the node creates a slave account state for a transaction receiver account whose account state does not exist in the fragment; 4) the node packages and processes the transactions in the transaction pool; and 5) the fragment receives the slave account states sent by other fragments, and executes an account state merging mechanism. According to the method, the transaction processing performance on the fragmented block chain can be well improved.

Description

Technical Field

[0001] The present invention relates to the field of sharding technology, and more specifically, to a transaction processing optimization method based on blockchain. Background Art

[0002] In recent years, due to the great success of blockchain technology in the financial field, more and more researchers have made blockchain technology their research focus. As a decentralized distributed ledger technology, blockchain has the advantages of data transparency, integrity and immutability, and has been widely used in finance, medical care, the Internet of Things and other fields. However, the scalability issue is the main challenge hindering the large-scale application of blockchain. As the number of accounts increases, the number of transactions also increases rapidly. The existing blockchain system faces many problems in data storage, processing efficiency, consensus mechanism, etc., which limits the further promotion of blockchain technology in practical applications.

[0003] Sharding technology is considered to be one of the most promising ways to solve the scalability problem of blockchain. It divides the blockchain system into multiple non-intersecting parts at the structural level. Each independent part is called a "shard". The core idea of ​​sharding technology is "divide and conquer". Each shard is maintained by a group of nodes. Each shard only needs to store and process part of the transaction related to itself. This split processing method improves the system's parallel processing capabilities, thereby significantly improving the transaction throughput of the blockchain. Sharding technology makes the blockchain network no longer a single entity, but consists of multiple independently running shards. This sharding architecture allows each node in the network to focus on processing only a small amount of data, improving the efficiency and scalability of the blockchain system.

[0004] Elastico is considered to be the first public blockchain sharding protocol with security candidate. It shards the network and transactions, but does not implement state sharding, which requires each blockchain node to store the entire state ledger, consuming a lot of storage overhead. OmniLedger is a distributed ledger system that implements full sharding. It introduces a commit protocol for atomic commit of cross-shard transactions and improves system performance through parallel processing. RapidChain proposes an optimal committee internal consensus and a cross-shard transaction verification technology to achieve fast committee consensus and efficient cross-shard transaction verification while reducing system overhead. Chainspace proposes a new commit protocol for implementing universal smart contracts across shards. Monoxide proposes a relay transaction mechanism to ensure the final atomicity of cross-shard TX, but the communication overhead brought by the mechanism also leads to a long transaction confirmation delay. Pyramid is the first hierarchical sharding blockchain system. It introduces a cascading architecture. The upper b-shard stores complete data in multiple shards. Therefore, cross-shard transactions can be processed and verified within these shards, but the top b-shard stores almost the entire system's data. BrokerChain introduced a market maker account to handle cross-shard transactions and split the account at the protocol layer to achieve workload balance between shards, but it lacked an incentive mechanism and could not motivate users to voluntarily join the market maker. TxAllo proposed a dynamic allocation mechanism based on graph partitioning, which optimized the system throughput and balanced the workload of each shard.

[0005] Although sharding technology can improve the throughput of the system, the existing sharding protocols still face many severe challenges and limitations, including unbalanced sharding workloads, complex cross-shard transaction processing, and consensus security risks. As the first sharding blockchain protocol, Elastico is groundbreaking, but it only implements partial sharding. Nodes in each shard still need to store all blockchain ledger data, and the storage overhead of the nodes is not reduced, which affects the overall scalability of the system. Omniledger proposed the Atomix protocol for processing cross-shard transactions and used verifiable random functions to achieve secure shard member elections, but the communication complexity between nodes in its consensus process is high. When the number of nodes in the shard increases and the number of cross-shard transactions increases, the system throughput drops significantly.

[0006] In Monoxide, accounts are distributed to different blockchain shards based on the first few digits of their addresses. It aims to randomly and evenly distribute account status. Ideally, the number of accounts in each shard is roughly the same, but Monoxide does not consider whether the number of transactions is balanced in the shards, which will cause the shards to have an unbalanced transaction load. Unbalanced transaction load refers to the uneven number of transactions processed between different shards, which is generally caused by differences in the ability of different accounts to initiate transactions. This will cause the number of transactions initiated by accounts in some shards to exceed the shard processing capacity, thereby affecting the overall performance of the system.

[0007] In addition, Monoxide introduces a mechanism of relaying transactions to ensure the atomicity of transactions, which inevitably leads to cross-shard transactions. Cross-shard transactions are a problem that occurs in sharded blockchain systems based on the account / balance model. Cross-shard transactions require information exchange and verification between multiple shards, which increases the communication overhead and processing delay of the blockchain network. Each shard needs to understand and confirm the transaction status of other shards. This process will cause transaction delays, thereby affecting the overall performance of the sharded system. When the number of shards in the system increases, almost all transactions are cross-shard transactions. A large number of cross-shard transactions may reduce system throughput and increase communication costs between shards. These problems are not solved in Monoxide. Summary of the invention

[0008] The purpose of the present invention is to provide a transaction processing optimization method based on sharded blockchain in view of the shortcomings of the prior art. This method can balance the workload of shards, reduce the number of cross-shard transactions, and improve the performance of blockchain transaction processing.

[0009] The technical solution for achieving the purpose of the present invention is:

[0010] A transaction processing optimization method based on sharded blockchain, the system uses a fixed epoch as the operating cycle, adopts the PBFT consensus protocol, so that each node in the shard reaches a consensus on the transaction, each shard is maintained by a group of nodes, and each shard only needs to store and process a part of the transaction. The method includes the following steps:

[0011] 1) Transaction Quantity Prediction: In a sharded blockchain system, accounts are randomly assigned to shards. Ideally, the workload between shards is balanced. However, when multiple hot accounts are assigned to the same shard, the shard needs to process and verify a large number of asset transfer transactions. Shards that contain only a small number of hot accounts only need to process a small number of asset transfer transactions. This will cause the shards to be hot and cold, resulting in a decrease in system performance and throughput.

[0012] The third-party entity regularly predicts the number of transactions of hot accounts in each epoch. Therefore, the third-party entity needs to regularly collect and count the historical transaction data of hot accounts and use the GRU model to predict the number of transactions that each hot account may generate in the next epoch. The GRU model contains 32 hidden layer neurons, 1 input and output features, and uses the mean square error between the predicted value and the actual value as the loss function. Compared with the LSTM model for prediction, the GRU model has fewer parameters, faster convergence speed, and less time spent on modeling, and can more quickly predict the future number of transactions of hot accounts.

[0013] 2) Account allocation phase: Before each epoch starts, the system will allocate hot accounts based on machine learning prediction results and evenly distribute them to each shard in order to balance the workload of each shard.

[0014] 3) Slave account creation phase: During the transaction processing and verification process, the node will create a slave account status for the transaction recipient account whose account status does not exist in this shard. An account has one master account and multiple slave accounts, and the slave account status of the account can be directly operated without cross-shard interaction.

[0015] 4) Transaction processing stage: At the beginning of each transaction proposal, the master node will package the transaction transactions injected into the transaction pool. Each shard will process and verify the transaction transactions through the PBFT consensus protocol, and then generate new transaction blocks and upload them to the chain. The number of transaction blocks is determined by the network parameters of the blockchain system.

[0016] 5) Account status synchronization phase: The master node sends the slave account status generated by itself to other shards, and also receives the slave account status sent by other shards. Each shard reaches a consensus on the received status results, generates a new status block through the PBFT consensus protocol, and merges the slave account status into the master account status.

[0017] This technical solution uses machine learning prediction and master-slave accounts to fully shard the extended blockchain method. The machine learning prediction model is used to learn the historical transaction data of hot accounts to predict their future transaction volume, and the load-aware dynamic transaction allocation algorithm is used to transfer hot accounts with more transactions from busy shards to relatively idle shards to balance the workload between shards. The master-slave account model is used to process cross-shard transactions in a single shard, reducing the cross-shard interactions caused by cross-shard transaction processing in traditional sharding systems, improving the system throughput, and reducing confirmation delays.

[0018] In this technical solution, in order to predict the number of future transactions of hot accounts in the sharded blockchain, the GRU model is used to predict the number of transactions that each hot account may generate in the next epoch. The GRU model contains 32 hidden layer neurons, 1 input and output features, and uses the mean square error between the predicted value and the actual value as the loss function. Compared with other models for prediction, the GRU model has fewer parameters, faster convergence speed, and less time spent on modeling, and can predict the number of future transactions of hot accounts more quickly.

[0019] This technical solution has the ability to balance the workload between shards, and designs a load-aware account allocation mechanism. The account allocation mechanism will regularly confirm the shard location of the account in each epoch. In order to balance the workload of different shards, reduce the difference in the number of transactions processed by each shard, and improve the performance and efficiency of the blockchain system. The core of the account allocation mechanism is to move as few accounts as possible to achieve load balancing. In each epoch, the account allocation mechanism will move hot accounts from high-workload shards to low-workload shards to achieve load balancing. Because there are a large number of accounts in the actual blockchain system, it is very time-consuming and laborious to solve the account allocation problem. Therefore, the account allocation mechanism is only designed for hot accounts that will generate a large number of transactions.

[0020] This technical solution aims to address the problem of system performance degradation caused by excessive cross-shard transaction ratio in sharded blockchains. By introducing a master-slave account model to reduce the number of cross-shard transactions, cross-shard interactions are effectively reduced. In addition, we have designed an account status merging mechanism to regularly merge the status of slave accounts into the master account. In order to efficiently merge the status of master and slave accounts, the system needs to ensure that each shard can grasp the shard location of all account statuses, so as to accurately locate and update the status information of each account. We have modified the Merkle tree of Ethereum in the real world and introduced a mapping mechanism to quickly locate the location where the master and slave account status is stored. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A schematic diagram of the system architecture in the embodiment;

[0022] Figure 2 This is a schematic diagram of the master-slave account model in the embodiment;

[0023] Figure 3 This is a schematic diagram of the improved block structure in the embodiment;

[0024] Figure 4 This is a schematic diagram of the number of shards and throughput in the embodiment;

[0025] Figure 5 This is a schematic diagram of the number of shards and transaction confirmation delay in the embodiment;

[0026] Figure 6 , 7 This is a schematic diagram of shard load balancing comparison in the embodiment;

[0027] Figure 8 This is a schematic diagram of transaction queue size comparison in the embodiment;

[0028] Fig. 9 Flowchart of optimization of the sharded blockchain system of the present invention. DETAILED DESCRIPTION

[0029] The content of the present invention is further described below in conjunction with the drawings and embodiments, but the present invention is not limited thereto.

[0030] Example:

[0031] A transaction processing optimization method based on sharded blockchain. The system uses a fixed epoch as the operating cycle and adopts the PBFT consensus protocol to make each node in the shard reach a consensus on the transaction. Each shard is maintained by a group of nodes, and each shard only needs to store and process a part of the transaction, such as Figure 1 As shown, the method comprises the following steps:

[0032] 1) Transaction Quantity Prediction: In a sharded blockchain system, accounts are randomly assigned to shards. Ideally, the workload between shards is balanced. However, when multiple hot accounts are assigned to the same shard, the shard needs to process and verify a large number of asset transfer transactions. Shards that contain only a small number of hot accounts only need to process a small number of asset transfer transactions. This will cause the shards to be hot and cold, resulting in a decrease in system performance and throughput.

[0033] The third-party entity regularly predicts the number of transactions of hot accounts in each epoch. Therefore, the third-party entity needs to regularly collect and count the historical transaction data of hot accounts and use the GRU model to predict the number of transactions that each hot account may generate in the next epoch. The GRU model contains 32 hidden layer neurons, 1 input and output features, and uses the mean square error between the predicted value and the actual value as the loss function. Compared with the LSTM model for prediction, the GRU model has fewer parameters, faster convergence speed, and less time spent on modeling, and can more quickly predict the future number of transactions of hot accounts.

[0034] 2) Account allocation phase: Before each epoch starts, the system will allocate hot accounts based on machine learning prediction results and evenly distribute them to each shard in order to balance the workload of each shard.

[0035] 3) Slave account creation phase: During the transaction processing and verification process, the node will create a slave account status for the transaction recipient account whose account status does not exist in this shard. An account has one master account and multiple slave accounts. The slave account status of the account can be directly updated without cross-shard transaction processing.

[0036] 4) Transaction processing stage: At the beginning of each transaction proposal, the master node will package the transaction transactions injected into the transaction pool. Each shard will process and verify the transaction transactions through the PBFT consensus protocol, and then generate new transaction blocks and upload them to the chain. The number of transaction blocks is determined by the network parameters of the blockchain system.

[0037] 5) Account status synchronization phase: The master node sends the slave account status generated by itself to other shards, and also receives the slave account status sent by other shards. Each shard reaches a consensus on the received status results, generates a new status block through the PBFT consensus protocol, and merges the slave account status into the master account status.

[0038] This technical solution uses machine learning prediction and master-slave accounts to fully shard the extended blockchain method. The machine learning prediction model is used to learn the historical transaction data of hot accounts to predict their future transaction volume, and the load-aware dynamic transaction allocation algorithm is used to transfer hot accounts with more transactions from busy shards to relatively idle shards to balance the workload between shards. The master-slave account model is used to process cross-shard transactions in a single shard, reducing the cross-shard interactions caused by cross-shard transaction processing in traditional sharding systems, improving the system throughput, and reducing confirmation delays.

[0039] During the experimental test, we compared the throughput and transaction confirmation delay under different numbers of shards, as well as the shard load balancing results compared with the baseline method, and also compared the transaction queue size. The results show that as the number of shards increases, the throughput shows an increasing trend, which is consistent with the theoretical expectation that more transactions can be processed in parallel as the sharding scale increases. The more shards there are, the faster the transaction processing is. Compared with the baseline, this method always shows good throughput. We further tested the transaction confirmation delay of this method and the baseline. The results show that as the number of shards increases, the transaction confirmation delay gradually decreases and eventually stabilizes. Since in this method, the processing of cross-shard transactions is carried out in the shard where the transaction sender is located, no additional cross-shard interaction is required. In the baseline, cross-shard transactions need to be relayed to other shards, and the communication overhead between shards will increase the confirmation delay. Therefore, the confirmation delay shown by this method is significantly better than the baseline.

[0040] In addition, we evaluate the load balancing ability of the shards by whether the number of transactions processed in different shards can be balanced. The results show that the account allocation mechanism adopted by this method makes the load between the shards relatively balanced, which is more uniform than the random allocation method under the baseline. Finally, we study the changes in the TX pool by monitoring the queue size. The results show that the queue size management performance of this method under high load conditions is better than the baseline, and it can maintain a low queue size in a large range, showing better transaction processing capabilities.

[0041] The important contributions of this embodiment are as follows:

[0042] a. A load-aware account allocation mechanism is proposed. Its core goal is to minimize the difference between the workload of all shards and the average workload. Before the start of each epoch, hot accounts are moved from high-workload shards to low-workload shards to achieve load balancing. This is used to optimize the workload balance of shards and improve the scalability and performance of the system.

[0043] b. A cross-shard blockchain protocol is proposed, which introduces a master-slave account model and ensures the atomicity of transactions through an account status merging mechanism. The number of cross-shard transactions is reduced, thereby significantly improving the throughput of the blockchain system and reducing transaction confirmation delays.

[0044] c. Through comparative analysis with baseline experiments, we reveal the performance advantages of our method.

[0045] The present invention and its embodiments are described schematically above, and the description is not restrictive. The drawings show only one embodiment of the present invention, and the actual structure is not limited thereto. Therefore, if a person skilled in the art is inspired by it and designs a structural method and an embodiment similar to the technical solution without creativity without departing from the purpose of the invention, they shall all fall within the protection scope of the present invention.

Claims

1. A transaction processing optimization method based on sharded blockchain, characterized in that: The following steps are involved: Step 1: Regularly collect and count the historical transaction data of hot accounts, and use the GRU model to predict the number of transactions that each hot account may generate in the next epoch; Step 2: Allocate hot accounts according to the prediction results and evenly distribute them to each shard to balance the workload of each shard; Step 3: During the transaction processing and verification process, the node will create a secondary account status for the transaction recipient account whose account status does not exist in this shard; Step 4: The node packages the transactions in the transaction pool, and each shard processes and verifies the transaction through the PBFT consensus protocol, generates a new block and uploads it to the chain; Step 5: The shard sends the slave account status it has generated to other shards, generates a new status block through the PBFT consensus protocol, and merges the slave account status into the master account status.

2. A transaction processing optimization method based on sharded blockchain according to claim 1, characterized in that: In step 1, in the sharded blockchain system, accounts are randomly assigned to each shard. Ideally, the workload between shards is balanced. However, when multiple hot accounts are assigned to the same shard, the shard needs to process and verify a large number of asset transfer transactions. Shards that contain only a small number of hot accounts only need to process a small number of asset transfer transactions. This will cause the shards to be hot and cold, resulting in a decrease in system performance and throughput. Therefore, historical transaction data of hot accounts is collected and counted regularly, and the GRU model is used to predict the number of transactions that each hot account may generate in the next epoch. Compared with the LSTM model for prediction, the GRU model has fewer parameters, faster convergence speed, and less time spent on modeling, and can more quickly predict the number of future transactions of hot accounts.

3. A transaction processing optimization method based on sharded blockchain according to claim 2, characterized in that: In step 2, before each epoch starts, the system will allocate hot accounts based on the machine learning prediction results and evenly distribute them to each shard in order to balance the workload of each shard.

4. A transaction processing optimization method based on sharded blockchain according to claim 3, characterized in that: In step three, during the transaction processing and verification process, the node will create a slave account state for the transaction recipient account whose account state does not exist in this shard. An account has one master account and multiple slave accounts, and can directly operate on the slave account state of the account without cross-shard interaction.

5. A transaction processing optimization method based on sharded blockchain according to claim 4, characterized in that: In step 4, at the beginning of each transaction proposal, the master node will package the transaction transactions injected into the transaction pool. Each shard will process and verify the transaction transactions through the PBFT consensus protocol, and then generate new transaction blocks and upload them to the chain. The number of transaction blocks is determined by the network parameters of the blockchain system.

6. A transaction processing optimization method based on sharded blockchain according to claim 5, characterized in that: In step 5, the shard sends the slave account status it generates to other shards, and also receives the slave account status sent by other shards. Each shard reaches a consensus on the received status results, generates a new status block through the PBFT consensus protocol, and merges the slave account status into the master account status.

Images