A shard account adjustment method for a blockchain shard system and related devices

Abstract

The present application discloses a shard account adjustment method for a blockchain shard system and a related device thereof. The blockchain shard system includes working shards and coordinating shards. The coordinating shards collect transaction information generated by transactions between accounts currently processed by each working shard, and construct an account transaction network based on the transaction information; the coordinating shards calculate the sum of the weights of the edges between each account set through the account transaction network, and re-divide the accounts of all working shards with the minimum sum of the weights of the edges between different account sets as the optimization goal to obtain the division result; the coordinating shards send the division result to the working shards, so that the working shards update their own account information based on the division result, thereby improving the technical problem that the existing blockchain sharding system has too many cross-shard transactions, resulting in reduced throughput of the sharding system and increased transaction confirmation delay.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a shard account adjustment method for a blockchain shard system and related devices. Background Art

[0002] The scalability of blockchain is still a major limitation to the development of blockchain technology. For blockchain networks, throughput is always a bottleneck. In order to improve the scalability of blockchain systems and increase their throughput, sharding technology has been introduced into blockchain networks. In traditional blockchain networks, all nodes in the network maintain the same ledger and process all transactions. With sharding technology, nodes on the network are divided into different groups, each of which is called a shard. Transactions arriving in the network will also be divided into different shards according to certain rules. Therefore, in a sharded network, shard nodes only need to process transactions belonging to the shard, and multiple shards process different transactions in parallel, greatly improving the throughput of the system. However, the blockchain sharding system still has many defects. With the increase in the number of shards in the existing sharding system, almost all transactions are cross-shard transactions, which increases the overhead of the sharding system, reduces the throughput of the sharding system, and increases the confirmation delay of transactions. Summary of the invention

[0003] The present application provides a shard account adjustment method for a blockchain shard system and a related device thereof, which are used to improve the technical problem that there are too many cross-shard transactions in the existing blockchain shard system, which reduces the throughput of the shard system and increases the confirmation delay of transactions.

[0004] In view of this, the first aspect of the present application provides a shard account adjustment method for a blockchain shard system, wherein the blockchain shard system includes a working shard and a coordination shard, and the method includes:

[0005] The coordination shard collects the transaction information generated by the transactions between the accounts currently processed by the working shards, and constructs an account transaction network G(V,E) based on the transaction information, where V is the account set of all the working shards, E is the edge set of two accounts, and the weight of the edge is the number of transactions between the two accounts;

[0006] The coordination shard calculates the sum of the weights of the edges between each account set through the account transaction network G(V,E), and re-divides the accounts of all the working shards with the minimum sum of the weights of the edges between different account sets as the optimization goal to obtain a division result;

[0007] The coordinating slice sends the division result to the working slice, so that the working slice updates its own account information according to the division result.

[0008] Optionally, the optimization goal also includes: the weights of the edges related to each account set are as close as possible;

[0009] Accordingly, the coordination shard calculates the sum of the weights of the edges between each account set through the account transaction network G(V,E), and re-divides the accounts of all the working shards with the minimum sum of the weights of the edges between different account sets as the optimization goal, and obtains the division results, which specifically include:

[0010] The coordination shard calculates the sum of the weights of the edges between each account set through the account transaction network G(V,E), and re-divides the accounts of all the working shards with the optimization goal of minimizing the sum of the weights of the edges between different account sets and making the weights of the edges related to each account set as close as possible, to obtain a division result.

[0011] Optionally, the method further includes:

[0012] The coordination shard generates a corresponding status block according to the division result, and performs consensus confirmation on the status block.

[0013] Optionally, the working slice updates its own account information according to the division result, and the process also includes:

[0014] The working slice verifies the partition result according to the status block, and executes subsequent steps after the verification passes.

[0015] Optionally, the working slice updates its own account information according to the division result, and then further includes:

[0016] The working slice generates a reference block;

[0017] The working slice acquires new slice information, and acquires a new node added to the working slice through the new slice information, wherein the new slice information is node information obtained by shuffling and reorganizing the nodes in the coordination slice and the working slice;

[0018] For a new node added to the working slice, the state information of the working slice is synchronized through the reference block.

[0019] Optionally, the method further includes:

[0020] The coordinating shard obtains the new shard information, and obtains a new node to be added to the coordinating shard through the new shard information;

[0021] For a new node that joins the coordination shard, the status information of the coordination shard is synchronized through the status block.

[0022] A second aspect of the present application provides a shard account adjustment device for a blockchain shard system, wherein the blockchain shard system includes a working shard and a coordination shard, and the device includes:

[0023] A collecting and constructing unit, used to collect transaction information generated by transactions between accounts currently processed by each of the working slices, and construct an account transaction network G(V,E) according to the transaction information, wherein V is the account set of all the working slices, E is the edge set of two accounts, and the weight of the edge is the number of transactions between the two accounts;

[0024] A partitioning unit, configured to calculate the sum of the weights of the edges between each account set through the account transaction network G(V, E), and re-partition the accounts of all the working slices with the minimum sum of the weights of the edges between different account sets as an optimization goal to obtain a partitioning result;

[0025] The sending unit is used to send the division result to the working slice, so that the working slice updates its own account information according to the division result.

[0026] Optionally, the optimization goal also includes: the weights of the edges related to each account set are as close as possible;

[0027] Accordingly, the division unit is specifically used for:

[0028] The sum of the weights of the edges between each account set is calculated through the account transaction network G(V,E), and the accounts of all the working shards are re-divided with the optimization goals of minimizing the sum of the weights of the edges between different account sets and making the weights of the edges related to each account set as close as possible to obtain the division result.

[0029] A third aspect of the present application provides a shard account adjustment device for a blockchain sharding system, the device comprising a processor and a memory;

[0030] The memory is used to store program code and transmit the program code to the processor;

[0031] The processor is used to execute the shard account adjustment method of the blockchain sharding system described in any one of the first aspects according to the instructions in the program code.

[0032] In a fourth aspect, the present application provides a computer-readable storage medium, which is used to store program code. When the program code is executed by a processor, the shard account adjustment method of the blockchain sharding system described in any one of the first aspects is implemented.

[0033] It can be seen from the above technical solutions that this application has the following advantages:

[0034] The present application provides a shard account adjustment method for a blockchain shard system, wherein the blockchain shard system includes working shards and coordinating shards, and the method includes: the coordinating shard collects transaction information generated by transactions between accounts currently processed by each working shard, and constructs an account transaction network G(V, E) according to the transaction information, wherein V is an account set of all working shards, E is an edge set of two accounts, and the weight of the edge is the number of transactions between the two accounts; the coordinating shard calculates the sum of the weights of the edges between each account set through the account transaction network G(V, E), and re-divides the accounts of all working shards with the minimum sum of the weights of the edges between different account sets as an optimization goal to obtain a division result; the coordinating shard sends the division result to the working shard, so that the working shard updates its own account information according to the division result.

[0035] In the present application, the transaction information generated when the working shard processes the transaction is collected by the coordination shard, and an account transaction network is constructed based on the transaction information. After the sum of the weights of the edges between each account set is calculated through the account transaction network, all accounts are re-divided with the minimum sum of the weights of the edges between each account set as the optimization goal to obtain the division result, so as to reduce cross-shard transactions. Finally, the account information in the working shard is updated according to the division result, so that each working shard can reduce cross-shard transactions when performing the next transaction processing, thereby improving the technical problem that there are too many cross-shard transactions in the existing blockchain sharding system, which reduces the throughput of the sharding system and increases the confirmation delay of the transaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0037] Figure 1 A flowchart of a shard account adjustment method for a blockchain shard system provided in an embodiment of the present application;

[0038] Figure 2 A schematic diagram of a blockchain sharding system provided for an embodiment of the present application;

[0039] Figure 3 A flowchart of a shard account adjustment method for a blockchain shard system provided in an embodiment of the present application;

[0040] Figure 4 A schematic diagram of the process of each stage in a blockchain sharding system provided in an embodiment of the present application;

[0041] Figure 5 A schematic diagram of a state block in a coordination shard provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] The present application provides a shard account adjustment method for a blockchain shard system and a related device thereof, which are used to improve the technical problem that there are too many cross-shard transactions in the existing blockchain shard system, which reduces the throughput of the shard system and increases the confirmation delay of transactions.

[0043] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0044] For easier understanding, see Figure 1 , the embodiment of the present application provides a shard account adjustment method of a blockchain shard system, comprising:

[0045] Step 101: The coordination shard collects the transaction information generated by the transactions between accounts processed by the current working shards, and constructs an account transaction network G(V,E) based on the transaction information, where V is the account set of all working shards, E is the edge set of two accounts, and the weight of the edge is the number of transactions between the two accounts.

[0046] The blockchain sharding system is used to divide the original large account book into multiple small account books, and then let different nodes (i.e., shards) maintain different small account books. Multiple small account books can be recorded at the same time, thereby improving the system throughput. The nodes in the blockchain sharding system of the embodiment of the present application will be divided into different shards according to the allocation mechanism, and at the same time, the transactions in the sharding system will also be sent to the responsible shard.

[0047] In the traditional sharding system, there are only working shards. The blockchain sharding system in the embodiment of the present application is as follows: Figure 2As shown in the figure, there are two types of shards in the blockchain sharding system: working shards and coordination shards. The blockchain sharding network is divided into multiple working shards. Each working shard maintains a shard chain of its own shard, and the working shard is used to process transactions. When a transaction is sent to the corresponding working shard, the node that receives the transaction will verify it. If the transaction is legal, it will be added to the local transaction pool and broadcast to other nodes in the same working shard. If the transaction is illegal, it will be rejected by the working shard. According to the set consensus protocol, each working shard will select some transactions from the transaction pool for chain confirmation, and then these transactions will be removed from the transaction pool. The coordination shard listens to and collects the transaction information generated when the working shard processes transactions. The nodes in the coordination shard will save the transaction information in all working shards.

[0048] When each working shard has processed a certain number of transactions, the shard system ends the current phase and prepares for state reorganization. The coordination shard builds an undirected edge-weighted account transaction network G(V,E) based on the transaction information of all working shards in the current phase, where V is the account set of all working shards, E is the edge set of two accounts, and the edge weight is the number of transactions between the two accounts.

[0049] Step 102: The coordination shard calculates the sum of the weights of the edges between each account set through the account transaction network G(V,E), and re-divides the accounts of all working shards with the minimum sum of the weights of the edges between different account sets as the optimization goal to obtain the division result.

[0050] In the prior art, when there are K working shards in a shard system, for account M, account prefix mapping or suffix mapping is generally used to determine the working shard where account M is located. Taking suffix mapping as an example, account M will be assigned to the M%K+1th shard, and once determined, it will remain unchanged. This static allocation does not take into account the interactivity between accounts, resulting in a large number of cross-shard transactions. Taking the account model as an example, the balance information of account A is managed by working shard 1, and the balance information of account B is managed by working shard 2. When account A transfers T tokens to account B, the transaction cannot be completed directly because the two accounts belong to different shards. When a cross-shard transaction under the account model is processed based on the relay transaction mechanism, under this mechanism, the transaction will first be confirmed in the working shard 1, and the deduction operation will be performed on account A (A: A's balance - T), and a verifiable relay transaction (B: B's balance + T) will be generated and sent to the working shard 2 where account B is located. After the working shard 2 verifies that the relay transaction is correct, it will be put on the chain and perform the money addition operation (B: B's balance + T). It can be seen that a cross-shard transaction needs to be confirmed twice, which adds an additional burden to the system and increases the confirmation delay of the transaction. Among them, the account model is the model adopted by Ethereum, and the balance and other status of each account are directly recorded in the blockchain ledger.

[0051] In order to improve the above problems, the embodiment of the present application re-divides the accounts by coordinating the shards to minimize cross-shard transactions. When there are K working shards in the shard system, there are K corresponding account sets. The accounts of all working shards are re-divided with the minimum sum of the weights of the edges between different account sets as the optimization goal to obtain the division results.

[0052] It should be noted that the sharding account adjustment method proposed in the embodiment of the present application is applicable to the account model, but not to the unspent transaction output (UTXO) model.

[0053] Step 103: The coordinating slice sends the division result to the working slice, so that the working slice updates its own account information according to the division result.

[0054] After receiving the division result, the work slice will update its own account information according to the division result. The work slice will send the relevant status of the account being moved out to the corresponding work slice, and will request the status information of the newly added account from other work slices. The account status and its proof are provided by the work slice where it was previously located. The sharding system in the embodiment of the present application can adjust the shard account in a decentralized and adaptive manner by coordinating the shards without introducing a third-party organization.

[0055] In an embodiment of the present application, the transaction information generated when the working shard processes the transaction is collected by the coordination shard, and an account transaction network is constructed based on the transaction information. After the sum of the weights of the edges between each account set is calculated through the account transaction network, all accounts are re-divided with the minimum sum of the weights of the edges between each account set as the optimization goal to obtain a division result, so as to reduce cross-shard transactions. Finally, the account information in the working shard is updated according to the division result, so that each working shard can reduce cross-shard transactions when performing the next transaction processing, thereby improving the technical problem that there are too many cross-shard transactions in the existing blockchain sharding system, which reduces the throughput of the sharding system and increases the confirmation delay of the transaction.

[0056] The above is an embodiment of a shard account adjustment method for a blockchain sharding system provided by the present application. The following is another embodiment of a shard account adjustment method for a blockchain sharding system provided by the present application.

[0057] Please refer to Figure 3 and Figure 4 , a shard account adjustment method of a blockchain shard system provided in an embodiment of the present application includes:

[0058] Step 201: The coordination shard collects the transaction information generated by the transactions between accounts processed by the current working shards, and constructs an account transaction network G(V,E) based on the transaction information, where V is the account set of all working shards, E is the edge set of two accounts, and the weight of the edge is the number of transactions between the two accounts.

[0059] The specific content of step 201 is consistent with that of step 101 and will not be repeated here.

[0060] Step 202: The coordination shard calculates the sum of the weights of the edges between each account set through the account transaction network G(V,E), and re-divides the accounts of all working shards with the optimization goal of minimizing the sum of the weights of the edges between different account sets and making the weights of the edges related to each account set as close as possible, to obtain a division result.

[0061] In the prior art, when there are K working shards in a shard system, for account M, account prefix mapping or suffix mapping is generally used to determine the working shard where account M is located. Taking suffix mapping as an example, account M will be assigned to the M%K+1th shard, and once determined, it will remain unchanged. This static allocation method does not take into account the interactivity between accounts, resulting in a large number of cross-shard transactions. Taking the account model as an example, the balance information of account A is managed by working shard 1, and the balance information of account B is managed by working shard 2. When account A transfers T tokens to account B, the transaction cannot be completed directly because the two accounts belong to different shards. When a cross-shard transaction under the account model is processed based on the relay transaction mechanism, under this mechanism, the transaction will first be confirmed in the working shard 1, and the deduction operation will be performed on account A (A: A's balance - T), and a verifiable relay transaction (B: B's balance + T) will be generated and sent to the working shard 2 where account B is located. After the working shard 2 verifies that the relay transaction is correct, it will be put on the chain and the money addition operation will be performed (B: B's balance + T). It can be seen that a cross-shard transaction needs to be confirmed twice, which adds extra burden to the system and increases the confirmation delay of the transaction.

[0062] In order to improve the above problems, the embodiment of the present application re-divides the accounts by coordinating the shards to minimize cross-shard transactions. When there are K working shards in the shard system, there are K corresponding account sets. The accounts of all working shards are re-divided with the minimum sum of the weights of the edges between different account sets as the optimization goal to obtain the division results.

[0063] Furthermore, the embodiments of the present application also found that the prior art did not consider the transaction activity of the account, the shard load was unbalanced, some working shards needed to process excessive transactions, and some working shards had no transactions to process, which easily led to single / multi-shard overheating, reduced the throughput of the shard system, and increased transaction confirmation delays. Therefore, when re-dividing accounts, the embodiments of the present application re-divided the accounts of all working shards with the optimization goal of minimizing the sum of the weights of the edges between different account sets and making the weights of the edges related to each account set as close as possible, and considered the load balancing problem while considering reducing cross-shard transactions.

[0064] The account division process in the embodiment of the present application may be:

[0065] S1. After constructing the account transaction network G(V,E), set the maximum number of iterations τ and the maximum number of updates p;

[0066] S2, traverse the nodes in the working slice, initialize l(i), l(i) is the slice ID where node i is currently located, and update the number of times c(i) = 0;

[0067] S3. Initialize the weights of each working shard. Let k iterate from 1 to K, and calculate the sum of the weights of the edges related to the accounts in the working shard k, denoted as W. k Initialize the output result V. k (The set of accounts) is an empty set.

[0068] S4. Let the iteration count iterate from 1 to τ:

[0069] Let the node number i iterate from 1 to |V|:

[0070] If the update count of node i is less than p, i.e., c(i) < p, then calculate the new shard id of node i according to the objective function. The objective function is:

[0071]

[0072] where δ(l(j), k) is the display function. If l(j) = k, then δ(l(j), k) = 1; otherwise, δ(l(j), k) = 0. e i,j is the weight of the edge between node i and node j, [N] is the set {1, 2,..., N}, NB(i) is the set of neighbor nodes of node i, K(i) is the set of shard ids of the neighbor nodes of node i, i.e., K(i) = {l(j), j ∈ NB(i)}, and β ∈ [0, 1] is a preset parameter used to balance the number of cross-shard transactions and load balancing.

[0073] If node k!= l(i), then update W according to the updated result. k The weight W corresponding to the working shard l(i). l(i) c(i) = c(i) + 1, l(i) = k.

[0074] S5. Through the above iteration, obtain the mapping l(i) from each node i to its shard id, add these nodes to the corresponding account set, and return the partitioning result, i.e., the account sets V1, V2,..., VK of the K working shards. K .

[0075] Step 203. The coordinating shard generates the corresponding status block according to the partitioning result and conducts consensus confirmation on the status block.

[0076] After obtaining the partitioning result, the coordinating shard generates the corresponding status block, records the relevant information on the shard chain of the coordinating shard for other nodes to verify. The coordinating shard will conduct consensus confirmation on the status block to ensure the correctness and immutability of the status block.

[0077] The structure of the status block can refer to Figure 5, in addition to the necessary hash of the previous block and the current stage number, the status block also records the hash of the account transaction network constructed based on the transaction information in the current stage. The node can request the account transaction network of a certain stage from the coordinating shard and verify it through the hash without synchronizing all transactions. In addition, according to the obtained partitioning results, the accounts belonging to each working shard will form a Merkle tree, and its root hash will be recorded on the block. For K working shards, K corresponding hashes will be recorded, and this field can be used for fast verification of the partitioning results. Finally, the coordinating shard also maintains the mapping status of each account to the shard id. The mapping status of all accounts to the shard id will form a Merkle prefix tree, and its root hash will also be recorded on the block. The node can request the shard id of a certain account from the coordinating shard, and verify the correctness of the state through the provided state, Merkle path and root hash.

[0078] After the coordination shard generates the status block, the nodes in the coordination shard can discard the transaction records of this stage to save storage space. The status block provides other nodes with query and verification functions, and can also help other nodes quickly synchronize the status of the current shard system.

[0079] Step 204: The coordinating slice sends the partitioning result to the working slice, so that the working slice verifies the partitioning result according to the status block, and after the verification is passed, updates its own account information according to the partitioning result and generates a corresponding reference block.

[0080] The coordination block sends the division results to the working slices. The nodes in the working slices can perform corresponding hash transformations on the received division results to obtain hashes, and compare them with the information in the corresponding status blocks to determine the correctness of the received information. This fully ensures the immutability and traceability of the division results, and prevents malicious nodes from doing evil.

[0081] The working shard verifies the partition result according to the status block, and after the verification is passed, it updates its own account information according to the partition result and generates the corresponding reference block. The working shard will send the relevant status of the account being moved out to the corresponding working shard, and will request the status information of the newly added account from other working shards. The account status and its proof are provided by the working shard where it was previously located, and its legitimacy can be verified through the Merkle path. After the update is completed, each working shard will generate a reference block, which records the latest adjusted shard ledger information, and the reference block serves as the initial block for the next stage. At the same time, the working shard will also update the mapping of the account it maintains to the shard id to facilitate the forwarding of cross-shard transactions.

[0082] Furthermore, in order to prevent the nodes in the coordination shard and the working shard from colluding with each other to do evil, the sharding protocol is set to shuffle and reorganize the nodes in the coordination shard and each working shard, and then the sharding system enters the next stage, and the coordination shard collects the transaction information generated when each working shard processes transactions in the next stage. In the reorganization stage, the coordination shard obtains new shard information, which is the node information obtained after shuffling and reorganizing the nodes in the coordination shard and the working shard; obtains the new node added to the coordination shard through the new shard information, and synchronizes the status information of the coordination shard through the status block for the new node added to the coordination shard. The working shard obtains the new node added to the working shard through the new shard information, and synchronizes the status information of the working shard through the reference block for the new node added to the working shard.

[0083] In an embodiment of the present application, the transaction information generated when the working shard processes the transaction is collected by the coordination shard, and an account transaction network is constructed based on the transaction information. After the sum of the weights of the edges between each account set is calculated through the account transaction network, all accounts are re-divided with the minimum sum of the weights of the edges between each account set as the optimization goal to obtain a division result, so as to reduce cross-shard transactions. Finally, the account information in the working shard is updated according to the division result, so that each working shard can reduce cross-shard transactions when performing the next transaction processing, thereby improving the technical problem that there are too many cross-shard transactions in the existing blockchain sharding system, which reduces the throughput of the sharding system and increases the confirmation delay of the transaction.

[0084] Furthermore, the embodiments of the present application take into account that the shard system has an unbalanced shard load. Some working shards need to process excessive transactions, while some working shards have no transactions to process, resulting in overheating of single / multiple shards. When performing account repartitioning, the embodiments of the present application repartition the accounts of all working shards with the optimization goal of minimizing the sum of the weights of the edges between different account sets and making the weights of the edges related to each account set as close as possible. While considering reducing cross-shard transactions, load balancing issues are also considered to further improve the throughput of the shard system; and the shards are shuffled and reorganized to prevent nodes in the shards from colluding with each other.

[0085] The above is another embodiment of a shard account adjustment method for a blockchain sharding system provided by the present application. The following is a shard account adjustment device for a blockchain sharding system provided by the present application.

[0086] A shard account adjustment device of a blockchain shard system in an embodiment of the present application includes:

[0087] The collection and construction unit is used to collect the transaction information generated by the transactions between accounts processed by the current work slices, and construct the account transaction network G(V,E) based on the transaction information, where V is the account set of all work slices, E is the edge set of two accounts, and the weight of the edge is the number of transactions between the two accounts;

[0088] The partitioning unit is used to calculate the sum of the weights of the edges between each account set through the account transaction network G(V,E), and re-partition the accounts of all working shards with the minimum sum of the weights of the edges between different account sets as the optimization goal to obtain the partitioning result;

[0089] The sending unit is used to send the division result to the working slice, so that the working slice updates its own account information according to the division result.

[0090] As a further improvement, the optimization objectives also include: the weights of the edges related to each account set are as close as possible;

[0091] Accordingly, the division unit is specifically used for:

[0092] The sum of the weights of the edges between each account set is calculated through the account transaction network G(V,E), and the accounts of all working shards are re-divided with the optimization goal of minimizing the sum of the weights of the edges between different account sets and making the weights of the edges related to each account set as close as possible to obtain the division result.

[0093] As a further improvement, the device further comprises:

[0094] The status block generation unit is used to generate the corresponding status block according to the division result and to confirm the consensus of the status block.

[0095] As a further improvement, the method further comprises: an acquisition unit, configured to:

[0096] Get new shard information, and use the new shard information to get new nodes to join the coordination shard;

[0097] For new nodes that join the coordination shard, the status information of the coordination shard is synchronized through the status block.

[0098] In an embodiment of the present application, the transaction information generated when the working shard processes the transaction is collected by the coordination shard, and an account transaction network is constructed based on the transaction information. After the sum of the weights of the edges between each account set is calculated through the account transaction network, all accounts are re-divided with the minimum sum of the weights of the edges between each account set as the optimization goal to obtain a division result, so as to reduce cross-shard transactions. Finally, the account information in the working shard is updated according to the division result, so that each working shard can reduce cross-shard transactions when performing the next transaction processing, thereby improving the technical problem that there are too many cross-shard transactions in the existing blockchain sharding system, which reduces the throughput of the sharding system and increases the confirmation delay of the transaction.

[0099] Furthermore, the embodiments of the present application take into account that the shard system has an unbalanced shard load. Some working shards need to process excessive transactions, while some working shards have no transactions to process, resulting in overheating of single / multiple shards. When performing account repartitioning, the embodiments of the present application repartition the accounts of all working shards with the optimization goal of minimizing the sum of the weights of the edges between different account sets and making the weights of the edges related to each account set as close as possible. While considering reducing cross-shard transactions, load balancing issues are also considered to further improve the throughput of the shard system; and the shards are shuffled and reorganized to prevent nodes in the shards from colluding with each other.

[0100] The embodiment of the present application also provides a shard account adjustment device for a blockchain shard system, the device comprising a processor and a memory;

[0101] The memory is used to store the program code and transmit the program code to the processor;

[0102] The processor is used to execute the shard account adjustment method of the blockchain shard system in the aforementioned method embodiment according to the instructions in the program code.

[0103] The embodiment of the present application also provides a computer-readable storage medium, which is used to store program code. When the program code is executed by a processor, the shard account adjustment method of the blockchain sharding system in the aforementioned method embodiment is implemented.

[0104] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0105] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein, for example. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0106] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0107] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0108] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0109] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0110] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for executing all or part of the steps of the method described in each embodiment of the present application through a computer device (which can be a personal computer, a server, or a network device, etc.). The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (full name in English: Read-Only Memory, English abbreviation: ROM), random access memory (full name in English: Random Access Memory, English abbreviation: RAM), disk or optical disk and other media that can store program codes.

[0111] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A shard account adjustment method for a blockchain shard system, characterized in that: The blockchain sharding system includes a working shard and a coordination shard, and the method includes: The coordination shard collects the transaction information generated by the transactions between the accounts currently processed by the working shards, and constructs an account transaction network G(V,E) based on the transaction information, where V is the account set of all the working shards, E is the edge set of two accounts, and the weight of the edge is the number of transactions between the two accounts; The coordination shard calculates the sum of the weights of the edges between each account set through the account transaction network G(V,E), and re-divides the accounts of all the working shards with the minimum sum of the weights of the edges between different account sets as the optimization goal to obtain a division result; The coordinating slice sends the division result to the working slice, so that the working slice updates its own account information according to the division result. The working slice sends the relevant status of the moved account to the corresponding working slice, and requests the status information of the newly added account from other working slices. The account status and its proof are provided by the working slice where it was previously located.

2. The shard account adjustment method of the blockchain shard system according to claim 1, characterized in that: The method further comprises: The coordination shard generates a corresponding status block according to the division result, and performs consensus confirmation on the status block.

3. The shard account adjustment method of the blockchain shard system according to claim 2 is characterized in that: The working slice updates its own account information according to the division result, and the method also includes: The working slice verifies the partition result according to the status block, and executes subsequent steps after the verification passes.

4. The shard account adjustment method of the blockchain shard system according to claim 2 is characterized in that: The working slice updates its own account information according to the division result, and then further includes: The working slice generates a reference block; The working slice acquires new slice information, and acquires a new node added to the working slice through the new slice information, wherein the new slice information is node information obtained by shuffling and reorganizing the nodes in the coordination slice and the working slice; For a new node added to the working slice, the state information of the working slice is synchronized through the reference block.

5. The shard account adjustment method of the blockchain shard system according to claim 4 is characterized in that: The method further comprises: The coordinating shard obtains the new shard information, and obtains a new node to be added to the coordinating shard through the new shard information; For a new node that joins the coordination shard, the status information of the coordination shard is synchronized through the status block.

6. A shard account adjustment device for a blockchain shard system, characterized in that: The blockchain sharding system includes a working shard and a coordination shard, and the device includes: A collecting and constructing unit, used to collect transaction information generated by transactions between accounts currently processed by each of the working slices, and construct an account transaction network G(V,E) according to the transaction information, wherein V is the account set of all the working slices, E is the edge set of two accounts, and the weight of the edge is the number of transactions between the two accounts; A partitioning unit, configured to calculate the sum of the weights of the edges between each account set through the account transaction network G(V, E), and re-partition the accounts of all the working slices with the minimum sum of the weights of the edges between different account sets as an optimization goal to obtain a partitioning result; A sending unit is used to send the division result to the working slice, so that the working slice updates its own account information according to the division result. The working slice sends the relevant status of the account to be moved out to the corresponding working slice, and requests the status information of the newly added account from other working slices. The account status and its proof are provided by the working slice where it was previously located.

7. A shard account adjustment device for a blockchain shard system, characterized in that: The device comprises a processor and a memory; The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the sharding account adjustment method of the blockchain sharding system according to any one of claims 1-5 according to the instructions in the program code.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store program code, and when the program code is executed by the processor, the sharding account adjustment method of the blockchain sharding system according to any one of claims 1 to 5 is implemented.

Images