A blockchain sharding method, blockchain system and cross-sharding transaction processing method

Abstract

The present application discloses a blockchain sharding method, a blockchain system, and a cross-sharding transaction processing method, including: generating a state graph of the blockchain according to the newly generated transaction block in the current partition period; dividing the state graph into at least two non-overlapping sub-state graphs, obtaining a state graph division result, wherein the number of transactions between the sub-state graphs is less than a preset first threshold, and the variance of the total number of transactions within each sub-state graph is less than a preset second threshold; reaching a consensus on the state graph division result within the blockchain to generate a new state block; and reconstructing the state of each account according to the new state block. The present application can minimize the number of transactions between sub-state graphs, thereby achieving the effect of reducing the number of transactions between shards; at the same time, it can make the number of transactions of each sub-state graph as close as possible, thereby achieving the effect of balancing the workload between shards as much as possible.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and more specifically, to a blockchain sharding method, a blockchain system, and a cross-shard transaction processing method. Background Art

[0002] Sharding technology is considered a feasible solution to improve the scalability of blockchain. Sharding technology divides blockchain nodes into multiple small committees, each of which only needs to process transactions within a shard and some cross-shard transactions, thereby improving throughput.

[0003] However, the distribution of transactions in each shard is not necessarily balanced, which may cause congestion in some shards. When a shard is congested, cross-shard transactions may be delayed indefinitely. In fact, congested shards are caused by active users frequently publishing a large number of transactions on their related shards.

[0004] In addition, although increasing the number of shards can improve throughput, when the number of shards becomes larger, almost all transactions are cross-shard, which will also lead to a significant increase in the number of transactions that the shards have to process.

[0005] Therefore, in the blockchain sharding environment, workload balancing between shards and how to reduce cross-sharding are important issues to be solved. Summary of the invention

[0006] In view of this, the present application provides a blockchain sharding method, a blockchain system, and a cross-shard transaction processing method to reduce cross-shard transactions and balance the workload between shards.

[0007] To achieve the above objectives, the first aspect of the present application provides a blockchain sharding method, comprising:

[0008] Generate a state graph of the blockchain based on the newly generated transaction blocks in the current partition period, wherein the state graph includes the transaction relationship of each account / sub-account in the current partition period, and the transaction relationship includes the number of transactions between transaction accounts / sub-accounts;

[0009] When the number of newly generated transaction blocks reaches a preset number, the state graph is divided into at least two non-overlapping sub-state graphs to obtain a state graph division result, wherein the number of transactions between the sub-state graphs is less than a preset first threshold, and the variance of the total number of transactions within each sub-state graph is less than a preset second threshold;

[0010] A consensus is reached on the state graph partitioning result in the blockchain to generate a new state block;

[0011] According to the new status block, the status of each account is reconstructed.

[0012] Preferably, the process of generating a state graph of the blockchain according to the newly generated transaction blocks in the current partition period includes:

[0013] According to the newly generated transaction blocks in the current partition period, determine the total number of transactions of each account in the current partition period and the number of transactions with other accounts;

[0014] The state graph is constructed by taking accounts as vertices and setting edges between accounts with transactions;

[0015] Among them, the weight of the edge between two vertices is set to the number of transactions between the accounts to which the two vertices belong in the current partition period; the weight of the vertex is set to the total number of transactions of the account to which the vertex belongs in the current partition period.

[0016] Preferably, the process of dividing the state diagram into at least two non-overlapping sub-state diagrams comprises:

[0017] According to the weight of each vertex and the weight of each edge in the state graph, the state graph is divided into at least two non-overlapping sub-state graphs by using the Metis algorithm.

[0018] Preferably, the process of reconstructing the status of each account according to the new status block includes:

[0019] According to the new status block, obtain the shard to which each account belongs;

[0020] Based on the shards to which each account belongs, the status of each account is reconstructed using the Elastico algorithm

[0021] The second aspect of the present application provides a blockchain system, including:

[0022] Partition sharding, used to shard the blockchain according to the above-mentioned blockchain sharding method;

[0023] Block generation shards are used to generate transaction blocks within shards.

[0024] The third aspect of the present application provides a cross-shard transaction processing method, including:

[0025] The source account obtains the information of the relay account according to the target account and the current status block, wherein the relay account includes at least two sub-accounts, and the sub-accounts exist at least in the source shard where the source account is located and the target shard where the target account is located;

[0026] The source account initiates an original transaction to the target account and relay account with a preset first lock time;

[0027] After receiving the original transaction, the relay account initiates the first cross-shard transaction to the source account according to the current first block height of the source shard;

[0028] When the first cross-shard transaction is verified and confirmed, the relay account initiates a second cross-shard transaction to the target account, wherein the transaction assets in the first cross-shard transaction are attached with a preset second lock time;

[0029] When the second cross-shard transaction is verified, the target shard determines whether the current second block height of the source shard is within a first interval, where the first interval is determined by the first block height and the first lock time;

[0030] If yes, confirm the second cross-shard transaction;

[0031] If not, the target shard sends a failure certificate to the source shard; when the failure certificate is verified, the source shard confirms the failure certificate in a new block of the source shard, and the transaction assets in the first cross-shard transaction are returned to the source account.

[0032] Preferably, the process of the source account obtaining the information of the relay account according to the target account and the current status block includes:

[0033] The source account obtains the shard status tree of the source shard where the source account is located and the shard status tree of the target shard where the target account is located according to the current status block;

[0034] According to the shard status tree of the source shard and the shard status tree of the target shard, the information of the relay account is obtained, where the information of the relay account includes: the address of the relay account and the random value nonce.

[0035] Preferably, the process of verifying the first cross-shard transaction includes:

[0036] The node that receives the first cross-shard transaction verifies the signature of the relay account and obtains a signature verification result;

[0037] If the signature verification result is passed, the account address of the relay account is obtained according to the public key of the relay account;

[0038] Based on the account address and the target account's account address, obtain information about the source shard and the target shard through the current status block;

[0039] Forwarding the first cross-shard transaction to the source shard and the target shard;

[0040] The nodes in the source shard verify the validity of the first cross-shard transaction according to a preset standard, and add the first cross-shard transaction that passes the validity verification to the transaction pool of the source shard.

[0041] Preferably, the process of verifying the second cross-shard transaction includes:

[0042] The node that receives the second cross-shard transaction verifies the signature of the relay account and obtains a signature verification result;

[0043] If the signature verification result is passed, the account address of the relay account is obtained according to the public key of the relay account;

[0044] Based on the account address and the target account’s account address, obtain the target shard’s information through the current status block;

[0045] Forwarding the second cross-shard transaction to the target shard;

[0046] The nodes in the target shard verify the validity of the second cross-shard transaction according to a preset standard, and add the second cross-shard transaction that passes the validity verification to the transaction pool of the target shard.

[0047] Preferably, the process of generating the failure certificate includes:

[0048] Obtain the index of the target shard, the current third block height of the target shard, and the Merkle tree path of the first cross-shard transaction;

[0049] A failure proof message is generated according to the index, the third block height, the first cross-shard transaction, and the Merkle tree path.

[0050] It can be known from the above technical solution that the present application generates a state graph of the blockchain according to the newly generated transaction blocks of the blockchain in the current partition cycle. Among them, the state graph includes the transaction relationship of each account or sub-account in the current partition cycle, and the transaction relationship includes the number of transactions between transaction accounts. When the newly generated transaction blocks reach a preset number, the state graph is divided into at least two non-overlapping sub-state graphs to obtain a state graph division result. Then, the state graph division result is consensused within the blockchain to generate a new state block; finally, each account node reconstructs the state of each account according to the new state block, so that each account can achieve network sharding according to the state graph division result. Since the top of the state graph includes accounts or sub-accounts, and since the state graph includes the transaction relationship of each account or sub-account in the current partition period, the account can be segmented according to all transaction relationships in the current partition period, and the state graph can be divided in combination with the account segmentation, so that the weight of the edge between the sub-state graphs is less than the preset first threshold, that is, to a certain extent, it is guaranteed that the number of transactions between the sub-state graphs is as small as possible, and the effect of reducing the number of transactions between shards is achieved; at the same time, the variance of the total number of transactions within each sub-state graph is less than the preset second threshold, that is, to a certain extent, it is guaranteed that the number of transactions in each sub-state graph is as close as possible, and the effect of balancing the workload between each shard is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] 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 embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0052] Figure 1 A schematic diagram of a blockchain sharding method disclosed in an embodiment of the present application;

[0053] Figure 2 A schematic diagram illustrating each stage of the blockchain sharding method disclosed in the embodiment of the present application is illustrated;

[0054] Figure 3 A schematic diagram illustrating the account segmentation disclosed in the embodiment of the present application;

[0055] Figure 4 A schematic diagram of a sharding state tree disclosed in an embodiment of the present application is illustrated;

[0056] Figure 5 A schematic diagram illustrating a state diagram of a blockchain disclosed in an embodiment of the present application;

[0057] Figure 6A schematic diagram of a blockchain sharding device disclosed in an embodiment of the present application;

[0058] Figure 7 A schematic diagram of a blockchain sharding device disclosed in an embodiment of the present application;

[0059] Figure 8 A schematic diagram illustrating a blockchain system disclosed in an embodiment of the present application is provided;

[0060] Fig. 9 A schematic diagram of the cross-shard transaction processing method disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0061] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions 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.

[0062] The inventor of the present application found that in a sharded blockchain based on an account model, accounts are assigned to different shards based on the bits of their addresses. Although this approach can reduce node storage overhead and improve system throughput, it will inevitably lead to cross-shard transactions. Under this type of sharding scheme, cross-shard transaction processing becomes a major technical issue.

[0063] Among them, under the account model, users can use the balance in their accounts to generate a transaction. Some mainstream blockchain systems, such as Ethereum, use the account model. The account model stipulates that each transaction has only one sender account and one receiver account. When confirming the legitimacy of the transaction, it is necessary to check whether the sender's account balance is sufficient.

[0064] The idea of ​​sharding the blockchain is to distribute all transactions submitted to the blockchain to different shards. There are three main types of sharding modes, namely network sharding, transaction sharding, and state sharding. Among them, network sharding is to divide the entire blockchain network into smaller shards, which is also regarded as the basis of the other two types of sharding; transaction sharding is to distribute transactions to different shards according to certain rules, and each shard will store complete ledger information; in state sharding, each shard only stores part of the state.

[0065] In a blockchain that uses sharding technology, nodes are divided into different shards to form committees, and user ledger information is also divided into different shards. Sharding technology evenly distributes storage overhead, and each shard only needs to maintain its own ledger information, but it also brings problems such as data validity and cross-shard communication.

[0066] The Monoxide protocol ensures the atomicity of cross-shard transactions by introducing relay transactions. However, this way of handling cross-shard transactions may cause shard congestion. Such shards blocked by a large number of transactions can be called hot shards. In each hot shard, transactions cannot be processed in time and the confirmation delay becomes very long.

[0067] In order to evaluate the situation of hot sharding generated by sharded blockchain, in the processing of cross-shard transactions through the Monoxide protocol, 80,000 transactions were injected into each stage to evaluate the workload of all shards. During the multiple iterations of the above-mentioned cross-shard transactions, the inventors of the present application found that hot sharding is widespread. Since some accounts frequently publish a large number of transactions on their related shards, transactions are distributed on different shards in an unbalanced manner. The main reason for this phenomenon is that the account model adopted by Monoxide does not take into account the frequency of account posting transactions. In addition, the protocol will also generate a large number of cross-shard transactions, which further leads to the generation of hot shards.

[0068] In previous sharding protocols, an account can generally only be stored in one shard. However, some active accounts may participate in a large number of transactions, and the shard where such accounts are located will inevitably become a hot shard.

[0069] In response to the above problems, the present application provides a blockchain sharding method, which shards the blockchain based on state division and account segmentation. Through fine-grained state division and account segmentation, the number of cross-shard transactions is reduced, and the state sharding load balancing problem of the account model is solved to a certain extent.

[0070] The following describes a blockchain sharding method provided by an embodiment of the present application. Figure 1 The blockchain sharding method provided in the embodiment of the present application may include the following steps:

[0071] Step S101, generating a state diagram of the blockchain according to the newly generated transaction blocks in the current partition period.

[0072] The state diagram includes the transaction relationship of each account or sub-account in the current partition period, and the transaction relationship includes the number of transactions between the transaction accounts or sub-accounts.

[0073] For example, the account number or sub-account can be used as the vertex of the state diagram, and the transaction relationship between the accounts or sub-accounts can be described by the edges between the vertices.

[0074] A sub-account is an account separated from an account. Each sub-account separated from the same account shares an account address, and the total balance of each account is consistent with the balance of the account.

[0075] For example, for account C with a balance of 100 and an account address of b711355, it can be divided into sub-account C1 with a balance of 50 and an account address of b711355, and sub-account C2 with a balance of 50 and an account address of b711355.

[0076] Assuming that the accounts that generate transactions in the current partition period of the blockchain are account A, account B, sub-account C1 and sub-account C2, then the state diagram of the blockchain generated according to the newly generated transaction block in the current partition period includes the transaction relationship and transaction number between account A, account B, sub-account C1 and sub-account C2.

[0077] Step S102, dividing the state graph into at least two non-overlapping sub-state graphs to obtain a state graph division result.

[0078] Specifically, when the number of newly generated transaction blocks reaches a preset number, the state graph generated in step S100 is divided into at least two non-overlapping sub-state graphs to obtain a state graph division result.

[0079] The number of transactions between the sub-state graphs is less than a preset first threshold, and the variance of the total number of transactions within each sub-state graph is less than a preset second threshold.

[0080] The number of transactions between sub-state graphs is the number of transactions between the vertices of the sub-state graphs. When dividing the sub-state graphs, the division results should be considered to minimize the number of transactions between state graphs, which can reduce cross-shard transactions.

[0081] In addition, when dividing the sub-state graph, the division result is considered to make the variance of the total number of transactions within each sub-state graph small, that is, the number of transactions within each sub-state graph is as close as possible, so that the transactions of each shard can be as balanced as possible.

[0082] Step S103, consensus is reached on the state graph partitioning result within the blockchain to generate a new state block.

[0083] Optionally, the PBFT (Practical Byzantine Fault Tolerance) algorithm can be used to achieve consensus on the state graph partition results within the blockchain. Through the consensus on the state graph partition results, each account node in the blockchain can reach a consensus on the results of the state graph partition and account segmentation.

[0084] Among them, a partition shard can be set up separately in the blockchain, and the account nodes on the partition shard will reach a consensus on the state graph division result. When the state block is generated, the state block is added to the state chain of the partition shard.

[0085] Step S104, reconstructing the status of each account according to the new status block.

[0086] Specifically, since the status block contains the account segmentation and shard distribution of each account, based on this information, the account node responsible for proof of work in the blockchain can reset the status of each account node to construct each committee under the new sharding plan.

[0087] It is understandable that the above steps S101 to S104 only describe the sharding situation in a partition cycle. Proof of work, generation of a new state graph, state graph partitioning, generation of a new state block, and state reconstruction based on the new state block is a repetitive process.

[0088] The blockchain involved in the embodiment of the present application includes block generation shards and partition shards. The block generation shards generate transaction blocks by packaging transactions and achieve intra-shard consistency at the beginning of each partition cycle; the partition shards partition the account status in an adaptive manner through the above steps S101 to S103 during each cycle.

[0089] A status block can be generated in each partition cycle, and the length of a cycle is determined by the number of transaction blocks generated by the block generation shard reaching a preset number. The number of transaction blocks generated by a block generation shard in a cycle depends on the network parameters within the block generation shard, such as network bandwidth. Figure 2 B t-1 As shown in the figure, the first transaction block generated by the transaction shard follows the status block, recording the status partition result of the previous cycle.

[0090] In each partition cycle, the partition shard continuously loads transaction data from the new transaction blocks generated by the block generation shard and updates the state graph of all accounts. When the block generation shard generates all transaction blocks in the current cycle, the state graph is determined.

[0091] This application generates a state graph of a blockchain based on the transaction blocks newly generated by the blockchain in the current partition cycle. The state graph includes the transaction relationship of each account or sub-account in the current partition cycle, and the transaction relationship includes the number of transactions between transaction accounts. When the number of newly generated transaction blocks reaches a preset number, the state graph is divided into at least two non-overlapping sub-state graphs to obtain a state graph division result. Then, a consensus is reached on the state graph division result within the blockchain to generate a new state block; finally, each account node reconstructs the state of each account according to the new state block, so that each account can achieve network sharding according to the state graph division result. Since the top of the state graph includes accounts or sub-accounts, and since the state graph includes the transaction relationship of each account or sub-account in the current partition period, the account can be segmented according to all transaction relationships in the current partition period, and the state graph can be divided in combination with the account segmentation, so that the weight of the edge between the sub-state graphs is less than the preset first threshold, that is, to a certain extent, it is guaranteed that the number of transactions between the sub-state graphs is as small as possible, and the effect of reducing the number of transactions between shards is achieved; at the same time, the variance of the total number of transactions within each sub-state graph is less than the preset second threshold, that is, to a certain extent, it is guaranteed that the number of transactions in each sub-state graph is as close as possible, and the effect of balancing the workload between each shard is achieved.

[0092] In previous sharding protocols, an account can generally only be stored in one shard. However, some active accounts may participate in a large number of transactions, and the shards where such accounts are located will inevitably become hot shards. In order to solve the hot sharding problem, the embodiment of the present application allows users to split an account into multiple accounts at the protocol level, and allows these accounts to be stored in multiple arbitrary shards. The following introduces the account segmentation problem involved in the accounts and sub-accounts mentioned in the above step S101.

[0093] Assume that account μ has opened an account list, which is represented by {X μ,1 ,X μ,2 ,…,X μ,m}, where m is the number of sub-accounts opened by user μ. User μ can publish different transactions through multiple sub-accounts opened by it to achieve workload balancing of all shards and reduce the number of cross-shard transactions.

[0094] See also Figure 3 , the blockchain includes two shards (shard #1, shard #2) and three accounts (A, B, C), and there are three transactions in the ledger (i.e. A→C, B→C, A→B). Accounts A and B are deployed in shard 1 and shard 2 respectively. Under the Monoxide sharding strategy, account C can only be stored in shard 2 (or shard 1), so transactions A→B and A→C will generate 4 cross-shard transactions.

[0095] Under the account splitting mechanism of the embodiment of the present application, account C can be split into sub-account C1 and sub-account C2, and then placed in two shards respectively. After account C is split, 50% of the balance of account C is stored in shard 1, and the other 50% of the balance is stored in shard 2. Therefore, the original transaction A→C becomes an intra-shard transaction.

[0096] Under this mechanism, the workload imbalance problem of shards can be alleviated and the number of cross-shard transactions can be reduced. It should be noted that multiple sub-accounts under the account segmentation mechanism of the embodiment of the present application share the same account address, and use Ethereum's counter mechanism to identify the status of an account in different shards.

[0097] In order to serve the state graph partitioning and account segmentation, the state tree of Ethereum needs to be modified to store account states. The shard state tree of the embodiment of the present application is built on the storage mapping of all accounts, which is represented by a vector Ψ = [e1, e2, ..., e S ], where e i = 0 or 1, i∈{1,2,…,S}, S is the number of shards. i =1, it means that the account can be stored in shard i. When multiple elements in Ψ are marked as 1, the account is split into several accounts and stored in specific shards respectively.

[0098] Figure 4 The design of the shard state tree data structure is given. Among them, η is the nonce field of Ethereum, which is used to record the transaction records issued by users; ω is the value field, which represents the user balance; ζ represents the code field, which is used to mark the account type. For a specific account, different shards maintain different shard state trees for it. If an account is no longer stored in a shard, the fields related to the account in the shard state tree will be deleted. Due to the characteristics of the tree, any change in the account status will lead to a change in the root of the shard state tree, so the consistency of the accounts in the shard can be guaranteed.

[0099] In some embodiments of the present application, the process of generating a state diagram of the blockchain in step S101 according to the newly generated transaction blocks in the current partition period may include:

[0100] S1, based on the newly generated transaction blocks in the current partition period, determine the total number of transactions of each account in the current partition period and the number of transactions with other accounts.

[0101] S2, takes accounts as vertices and constructs a state graph by setting edges between accounts where transactions exist.

[0102] Among them, see Figure 5, the weight of the edge between two vertices is set to the number of transactions between the accounts to which the two vertices belong in the current partition period; the weight of a vertex is set to the total number of transactions of the account to which the vertex belongs in the current partition period.

[0103] In some embodiments of the present application, the process of dividing the state diagram into at least two non-overlapping sub-state diagrams in step S102 may include:

[0104] According to the weight of each vertex and the weight of each edge in the state graph, the state graph is divided into at least two non-overlapping sub-state graphs by using the Metis algorithm.

[0105] The algorithm of METIS is mainly based on multi-level recursive binary partitioning, multi-level K-way partitioning and multi-constraint partitioning mechanism to partition the state graph. It has high-quality partitioning results, which are said to be 10%-50% more accurate than the usual spectral clustering; the execution efficiency is 1 to 2 orders of magnitude faster than the common partitioning method, and it has very low fill-in, which can reduce storage load and calculation.

[0106] Since the weight of the edge in the state graph is set to the number of transactions, and the vertex of the graph represents the account, workload balancing is transformed into a graph partitioning problem. The Metis tool is used to solve this graph partitioning problem, dividing the vertices and edges into multiple different graphs, each of which is a shard. When the sum of the edge weights in each graph has the smallest variance, the workload between the shards is balanced.

[0107] In some embodiments of the present application, the process of reconstructing the status of each account according to the new status block in step S104 may include:

[0108] S1, based on the new status block, obtain the shard to which each account belongs.

[0109] S2, based on the shard to which each account belongs, reconstructs the status of each account through the Elastico algorithm.

[0110] The blockchain sharding device provided in an embodiment of the present application is described below. The blockchain sharding device described below and the blockchain sharding method described above can be referenced to each other.

[0111] See also Figure 6 The blockchain sharding device provided in the embodiment of the present application may include:

[0112] A state graph generating unit 21 is used to generate a state graph of the blockchain according to the newly generated transaction block in the current partition period, wherein the state graph includes the transaction relationship of each account / sub-account in the current partition period, and the transaction relationship includes the number of transactions between the transaction accounts / sub-accounts;

[0113] The state graph division unit 22 is used to divide the state graph into at least two non-overlapping sub-state graphs when the number of newly generated transaction blocks reaches a preset number, and obtain a state graph division result, wherein the number of transactions between the sub-state graphs is less than a preset first threshold, and the variance of the total number of transactions within each sub-state graph is less than a preset second threshold;

[0114] The state graph consensus unit 23 is used to reach a consensus on the state graph partitioning result in the blockchain and generate a new state block;

[0115] The state reconstruction unit 24 is used to reconstruct the state of each account according to the new state block.

[0116] In some embodiments of the present application, the process of the state diagram generation unit 21 generating the state diagram of the blockchain according to the transaction block newly generated in the current partition period may include:

[0117] According to the newly generated transaction blocks in the current partition period, determine the total number of transactions of each account in the current partition period and the number of transactions with other accounts;

[0118] The state graph is constructed by taking accounts as vertices and setting edges between accounts with transactions;

[0119] Among them, the weight of the edge between two vertices is set to the number of transactions between the accounts to which the two vertices belong in the current partition period; the weight of the vertex is set to the total number of transactions of the account to which the vertex belongs in the current partition period.

[0120] In some embodiments of the present application, the process of the state diagram division unit 22 dividing the state diagram into at least two non-overlapping sub-state diagrams may include:

[0121] According to the weight of each vertex and the weight of each edge in the state graph, the state graph is divided into at least two non-overlapping sub-state graphs by using the Metis algorithm.

[0122] In some embodiments of the present application, the process of reconstructing the state of each account by the state reconstruction unit 24 according to the new state block may include:

[0123] According to the new status block, obtain the shard to which each account belongs;

[0124] Based on the shard to which each account belongs, the status of each account is reconstructed using the Elastico algorithm.

[0125] The blockchain sharding device provided in the embodiment of the present application can be applied to blockchain sharding devices, such as computers, etc. Optionally, Figure 7 The hardware structure diagram of the blockchain sharding device is shown in Figure 7 The hardware structure of the blockchain sharding device may include: at least one processor 31, at least one communication interface 32, at least one memory 33 and at least one communication bus 34.

[0126] In the embodiment of the present application, the number of the processor 31, the communication interface 32, the memory 33, and the communication bus 34 is at least one, and the processor 31, the communication interface 32, and the memory 33 communicate with each other through the communication bus 34;

[0127] The processor 31 may be a central processing unit CPU, or an application-specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present application, etc.;

[0128] The memory 32 may include a high-speed RAM memory, and may also include a non-volatile memory, such as at least one disk memory;

[0129] The memory 33 stores a program, and the processor 31 can call the program stored in the memory 33, and the program is used to:

[0130] Generate a state graph of the blockchain based on the newly generated transaction blocks in the current partition period, wherein the state graph includes the transaction relationship of each account / sub-account in the current partition period, and the transaction relationship includes the number of transactions between transaction accounts / sub-accounts;

[0131] When the number of newly generated transaction blocks reaches a preset number, the state graph is divided into at least two non-overlapping sub-state graphs to obtain a state graph division result, wherein the number of transactions between the sub-state graphs is less than a preset first threshold, and the variance of the total number of transactions within each sub-state graph is less than a preset second threshold;

[0132] A consensus is reached on the state graph partitioning result in the blockchain to generate a new state block;

[0133] According to the new status block, the status of each account is reconstructed.

[0134] Optionally, the detailed functions and extended functions of the program may refer to the above description.

[0135] The embodiment of the present application further provides a storage medium, which may store a program suitable for execution by a processor, wherein the program is used to:

[0136] Generate a state graph of the blockchain based on the newly generated transaction blocks in the current partition period, wherein the state graph includes the transaction relationship of each account / sub-account in the current partition period, and the transaction relationship includes the number of transactions between transaction accounts / sub-accounts;

[0137] When the number of newly generated transaction blocks reaches a preset number, the state graph is divided into at least two non-overlapping sub-state graphs to obtain a state graph division result, wherein the number of transactions between the sub-state graphs is less than a preset first threshold, and the variance of the total number of transactions within each sub-state graph is less than a preset second threshold;

[0138] A consensus is reached on the state graph partitioning result in the blockchain to generate a new state block;

[0139] According to the new status block, the status of each account is reconstructed.

[0140] Optionally, the detailed functions and extended functions of the program may refer to the above description.

[0141] The following is a description of the blockchain system provided by the embodiment of this application. Figure 8 The blockchain system provided by the embodiment of the present application may include a partition shard 51 and a block generation shard 52.

[0142] Among them, the partition sharding 51 is used to shard the blockchain according to the blockchain sharding method of the above-mentioned embodiments; the block generation sharding 52 is used to generate transaction blocks within the shard.

[0143] The partition shard 51 and the block generation shard 52 may be composed of the same account nodes or different account nodes. The account nodes between the partition shard 51 and the block generation shard 52 may have an intersection.

[0144] In the above blockchain system, accounts are assigned to different shards according to the latest status block. Although this method can reduce the storage overhead of account nodes and improve system throughput, it will inevitably lead to cross-shard transactions. Cross-shard transaction processing has become a key technical issue.

[0145] The following describes the cross-shard transaction processing method provided by the embodiment of the present application. The cross-shard transaction processing method described below is applied to the blockchain system described above. Fig. 9 , the cross-shard transaction processing method may include the following steps:

[0146] Step S201, the source account obtains the information of the relay account according to the target account and the current status block.

[0147] Among them, the source account is the transaction initiating account; the target account is the transaction receiving account; the relay account includes at least two sub-accounts, and the sub-accounts exist at least in the source shard where the source account is located and the target shard where the target account is located.

[0148] For example, for Figure 3 In the example, account A is the source account, account B is the target account, and account C is the relay account, also known as the middleman account.

[0149] Step S202: The source account initiates an original transaction to the target account and the relay account with a preset first lock time.

[0150] For example, for Figure 3 The transaction between account A and account B (the following steps are all explained in detail using this example), account A is locked for the first time H lock Initiate original transaction Θ raw , where the original transaction Θ raw It can be expressed as:

[0151] Θ raw :=< <B,v,C,H lock , η Sende r, η b r oke r>,σ A >

[0152] Among them, η sender and η broker are the nonce values ​​of source account A and relay account C respectively, σ A Indicates the signature of source account A, which is calculated by calling the ECDSA algorithm.

[0153] Step S203, after receiving the original transaction, the relay account initiates the first cross-shard transaction to the source account according to the current first block height of the source shard.

[0154] Assume that the current first block height of the source shard is H current , then the first cross-shard transaction Θ1 can be expressed as:

[0155] θ1:=< <Type1,Θ raw， H current >,σ C >

[0156] Type1 is the label of Θ1, which is used to identify that this transaction is the first half of the cross-shard transaction; CRepresents the signature of relay account C.

[0157] Next, the first cross-shard transaction Θ1 will be broadcast to all shards. When the blockchain nodes in other shards receive the transaction information, they will verify it.

[0158] Step S204: After the first cross-shard transaction is verified and confirmed, the relay account initiates a second cross-shard transaction to the target account.

[0159] Among them, when the first cross-shard transaction is verified and confirmed, the account node in the source shard will include the first cross-shard transaction θ1 in the height marked as H source In the block, it is easy to know that H current <H source Then, source account A transfers the transaction asset v to relay account C. The transaction asset v is attached with a preset second lock time. At the same time, the nonce value of source account A is incremented by 1 to prevent replay attacks.

[0160] The preset second lock time is used to temporarily lock the transaction assets in the first cross-shard transaction to prevent unreasonable loss of assets of source account A when the subsequent second cross-shard transaction fails.

[0161] Specifically, the second cross-shard transaction can be expressed as:

[0162] θ2:=< <Type2,Θ raw > ， σ C >

[0163] Type2 is the label of Θ2, which is used to identify that this transaction is the second half of the cross-shard transaction.

[0164] Next, Θ2 will be broadcast in the blockchain network and eventually routed to the target shard. broker After the balance of the relay account is verified, Θ2 will be added to the transaction pool of the target shard.

[0165] Step S205: After the second cross-shard transaction is verified, the target shard determines whether the current second block height of the source shard is within the first interval. If so, execute step S206; if not, execute step S207.

[0166] Specifically, the first interval is determined by the first block height and the first lock time. The left boundary value of the first interval can be set to the first block height, and the right boundary value can be set according to the length of the first lock time. If the value of the right boundary value is small, the transaction processing speed will be faster, but it may lead to insufficient security; if the value of the right boundary value is large, the transaction processing speed will be slower, but it will be more secure.

[0167] For example, for the first block with height H current , the first locking time is H lock In the case of taking both speed and safety into consideration, the first interval can be set to: (H current ,H current + H lock / 2).

[0168] Step S206: confirm the second cross-shard transaction.

[0169] Specifically, the account node of the target shard will package the second cross-shard transaction Θ2 into the block of the target shard. Then, the relay account C will pass the transaction asset v to the target account B. At the same time, the nonce value of the relay account C will be increased by 1 to prevent replay attacks.

[0170] Step S207: The target shard sends a failure certificate to the source shard.

[0171] When the current second block height of the source shard exceeds the first interval (H current ,H current + H lock / 2), the blockchain node in shard 2 does not receive Θ2, then it can be considered that Θ2 processing failed. This failure result may be caused by malicious behavior of source account A. In order to handle the failure situation, the embodiment of the present application adopts the method of sending a failure certificate from the target shard to the source shard to ensure the atomicity of cross-shard transactions.

[0172] Step S208, when the failure proof is verified, the source shard confirms the failure proof in a new block of the source shard, and the transaction assets in the first cross-shard transaction are returned to the source account.

[0173] In some embodiments of the present application, in the above step S201, the process in which the source account obtains the information of the relay account according to the target account and the current status block may include:

[0174] S1, the source account obtains the shard status tree of the source shard where the source account is located and the shard status tree of the target shard where the target account is located according to the current status block.

[0175] S2, obtain the information of the relay account according to the shard status tree of the source shard and the shard status tree of the target shard.

[0176] The information of the relay account includes: the address of the relay account and the random value nonce.

[0177] In some embodiments of the present application, the process in which the first cross-shard transaction in step S204 is verified may include:

[0178] S1, the node that receives the first cross-shard transaction verifies the signature of the relay account and obtains a signature verification result;

[0179] S2. If the signature verification result is passed, the account address of the relay account is obtained according to the public key of the relay account;

[0180] S3, based on the account address and the account address of the target account, obtain information of the source shard and the target shard through the current status block;

[0181] S4, forwarding the first cross-shard transaction to the source shard and the target shard;

[0182] S5. The nodes in the source shard verify the validity of the first cross-shard transaction according to a preset standard, and add the first cross-shard transaction that passes the validity verification to the transaction pool of the source shard.

[0183] In some embodiments of the present application, the process in which the second cross-shard transaction in step S204 is verified may include:

[0184] S1, the node that receives the second cross-shard transaction verifies the signature of the relay account and obtains a signature verification result;

[0185] S2. If the signature verification result is passed, the account address of the relay account is obtained according to the public key of the relay account;

[0186] S3, based on the account address and the account address of the target account, obtain the information of the target shard through the current status block;

[0187] S4, forwarding the second cross-shard transaction to the target shard;

[0188] S5, the node in the target shard verifies the validity of the second cross-shard transaction according to a preset standard, and adds the second cross-shard transaction that passes the validity verification to the transaction pool of the target shard.

[0189] In some embodiments of the present application, the process of generating the failure certificate in step S207 may include:

[0190] S1, obtain the index of the target shard, the current third block height of the target shard, and the Merkle tree path of the first cross-shard transaction.

[0191] S2: Generate a failure proof message according to the index, the third block height, the first cross-shard transaction, and the Merkle tree path.

[0192] Assume that the index of the target shard is dest, and the current third block height of the target shard is H dest , the Merkle tree path of the first cross-shard transaction is {P dest}, then the failure proof γ can be expressed as:

[0193] γ:=<Θ1,dest,H desti {P dest}>

[0194] Among them, the Merkle tree path is {P dest}Starting from the root of the Merkle tree, it ends at the entry hash node of Θ1, which is used to verify that Θ1 is packaged in the block of the target shard. Once the node in the source shard receives the failure proof γ and verifies {P dest}, the source shard will confirm that θ1 is included in the target shard’s block, but θ2 is not. Then, γ will be included in the block height between (H current ,H current +H lock ) in the block of the original shard. Finally, the locked transaction asset v in step S204 will be returned to the source account A.

[0195] In summary:

[0196] This application generates a state graph of a blockchain based on the transaction blocks newly generated by the blockchain in the current partition cycle. The state graph includes the transaction relationship of each account or sub-account in the current partition cycle, and the transaction relationship includes the number of transactions between transaction accounts. When the number of newly generated transaction blocks reaches a preset number, the state graph is divided into at least two non-overlapping sub-state graphs to obtain a state graph division result. Then, a consensus is reached on the state graph division result within the blockchain to generate a new state block; finally, each account node reconstructs the state of each account according to the new state block, so that each account can achieve network sharding according to the state graph division result. Since the top of the state graph includes accounts or sub-accounts, and since the state graph includes the transaction relationship of each account or sub-account in the current partition period, the account can be segmented according to all transaction relationships in the current partition period, and the state graph can be divided in combination with the account segmentation, so that the weight of the edge between the sub-state graphs is less than the preset first threshold, that is, to a certain extent, it is guaranteed that the number of transactions between the sub-state graphs is as small as possible, and the effect of reducing the number of transactions between shards is achieved; at the same time, the variance of the total number of transactions within each sub-state graph is less than the preset second threshold, that is, to a certain extent, it is guaranteed that the number of transactions in each sub-state graph is as close as possible, and the effect of balancing the workload between each shard is achieved.

[0197] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0198] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can refer to each other.

[0199] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A blockchain sharding method, characterized in that: include: Generate a state graph of the blockchain based on the newly generated transaction blocks in the current partition period, wherein the state graph includes the transaction relationship of each account / sub-account in the current partition period, and the transaction relationship includes the number of transactions between transaction accounts / sub-accounts; When the number of newly generated transaction blocks reaches a preset number, the state graph is divided into at least two non-overlapping sub-state graphs to obtain a state graph division result, wherein the number of transactions between the sub-state graphs is less than a preset first threshold, and the variance of the total number of transactions within each sub-state graph is less than a preset second threshold; A consensus is reached on the state graph partitioning result in the blockchain to generate a new state block; Reconstructing the status of each account according to the new status block; The process of reconstructing the status of each account according to the new status block includes: According to the new status block, obtain the shard to which each account belongs; Based on the shard to which each account belongs, the status of each account is reconstructed using the Elastico algorithm.

2. The method according to claim 1, characterized in that The process of generating a state diagram of the blockchain according to the newly generated transaction blocks in the current partition period includes: According to the newly generated transaction blocks in the current partition period, determine the total number of transactions of each account in the current partition period and the number of transactions with other accounts; The state graph is constructed by taking accounts as vertices and setting edges between accounts with transactions; Among them, the weight of the edge between two vertices is set to the number of transactions between the accounts to which the two vertices belong in the current partition period; the weight of the vertex is set to the total number of transactions of the account to which the vertex belongs in the current partition period.

3. The method according to claim 1, characterized in that: The process of dividing the state diagram into at least two non-overlapping sub-state diagrams comprises: According to the weight of each vertex and the weight of each edge in the state graph, the state graph is divided into at least two non-overlapping sub-state graphs by using the Metis algorithm.

4. A blockchain system, characterized in that: include: Partition sharding, for sharding the blockchain according to the method of claim 1; Block generation shards are used to generate transaction blocks within shards.

5. A cross-shard transaction processing method, the method is applied to the system according to claim 4, characterized in that: include: The source account obtains the information of the relay account according to the target account and the current status block, wherein the relay account includes at least two sub-accounts, and the sub-accounts exist at least in the source shard where the source account is located and the target shard where the target account is located; The source account initiates an original transaction to the target account and relay account with a preset first lock time; After receiving the original transaction, the relay account initiates the first cross-shard transaction to the source account according to the current first block height of the source shard; When the first cross-shard transaction is verified and confirmed, the relay account initiates a second cross-shard transaction to the target account, wherein the transaction assets in the first cross-shard transaction are attached with a preset second lock time; When the second cross-shard transaction is verified, the target shard determines whether the current second block height of the source shard is within a first interval, where the first interval is determined by the first block height and the first lock time; If yes, confirm the second cross-shard transaction; If not, the target shard sends a failure certificate to the source shard; when the failure certificate is verified, the source shard confirms the failure certificate in a new block of the source shard, and the transaction assets in the first cross-shard transaction are returned to the source account.

6. The method according to claim 5, characterized in that The process of the source account obtaining the information of the relay account according to the target account and the current status block includes: The source account obtains the shard status tree of the source shard where the source account is located and the shard status tree of the target shard where the target account is located according to the current status block; According to the shard status tree of the source shard and the shard status tree of the target shard, the information of the relay account is obtained, where the information of the relay account includes: the address of the relay account and the random value nonce.

7. The method according to claim 5, characterized in that The process of verifying the first cross-shard transaction includes: The node that receives the first cross-shard transaction verifies the signature of the relay account and obtains a signature verification result; If the signature verification result is passed, the account address of the relay account is obtained according to the public key of the relay account; Based on the account address and the target account's account address, obtain information about the source shard and the target shard through the current status block; Forwarding the first cross-shard transaction to the source shard and the target shard; The nodes in the source shard verify the validity of the first cross-shard transaction according to a preset standard, and add the first cross-shard transaction that passes the validity verification to the transaction pool of the source shard.

8. The method according to claim 5, characterized in that The process of verifying the second cross-shard transaction includes: The node that receives the second cross-shard transaction verifies the signature of the relay account and obtains a signature verification result; If the signature verification result is passed, the account address of the relay account is obtained according to the public key of the relay account; Based on the account address and the account address of the target account, obtain the information of the target shard through the current status block; Forwarding the second cross-shard transaction to the target shard; The nodes in the target shard verify the validity of the second cross-shard transaction according to a preset standard, and add the second cross-shard transaction that passes the validity verification to the transaction pool of the target shard.

9. The method according to claim 5, characterized in that The process of generating the failure proof includes: Obtain the index of the target shard, the current third block height of the target shard, and the Merkle tree path of the first cross-shard transaction; A failure proof message is generated according to the index, the third block height, the first cross-shard transaction, and the Merkle tree path.

Images