Committee-based Sharded Blockchain Network Transaction Synchronization Consensus Method

Abstract

The present invention discloses a committee-based sharded blockchain network transaction synchronization consensus method. A sharded blockchain network is constructed, including user nodes, shard nodes, and committee nodes. When a user initiates a transaction, the shard node packages the transaction into a pre-constructed block and sends it to the committee node. After receiving the pre-constructed block, the committee node first conducts first-phase consensus to obtain a first-phase confirmed transaction pool, and then conducts first-phase consensus on the cross-shard transactions in the first-phase confirmed transaction pool to obtain a confirmed transaction pool for each shard. Then, a consensus confirmation area for each shard is constructed and distributed to the corresponding shard nodes, and the shard nodes conduct second-phase consensus on the received consensus confirmation blocks. In the present invention, transactions are collaboratively consensus between shard nodes and committee nodes, improving the processing efficiency of transactions.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and more specifically, relates to a transaction synchronization consensus method for a sharded blockchain network based on a committee. Background Art

[0002] Since all nodes in a blockchain network store a complete blockchain ledger, an ordinary blockchain network will occupy a high storage resource; the consensus method of competing for the block generation right by computing power adopted for improving security also brings a very low throughput. Current blockchain scaling solutions are all directed towards solving the above two problems. The most typical scaling solution is the sharding technology, which divides the nodes in the blockchain network into different shards to verify transactions and reach block consensus in parallel. However, the design difficulties lie in how to randomly allocate nodes in the network, how to evenly divide transactions among shards, how to handle transactions (cross-shard transactions) involving two or more shards, the security issues of the shard network, the consensus mechanisms within and between shards, etc.

[0003] Currently, the shard ID division of nodes is generally generated by using a verifiable random function (VRF), and the division rule of transactions is generally carried out according to the hash of the transaction or some other random fields in the transaction. The processing of cross-shard transactions is more diverse. A relatively common processing method is two-phase commit. Since most transactions in a sharded blockchain are cross-shard transactions, the processing efficiency of cross-shard transactions determines the performance of the sharded blockchain network. The two-phase commit method for processing cross-shard transactions is widely used in many existing works. However, this method requires a coordinator to drive the two-phase commit. In some works, client nodes are used to drive the two-phase commit, but this method driven by the client lacks security; in other works, shards are used to drive the two-phase commit, but this method brings extremely high communication complexity between shards, and the processing efficiency of transactions is very low and needs to be further improved. Summary of the Invention

[0004] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a transaction synchronization consensus method for a sharded blockchain network based on a committee, in which transactions are collaboratively consensus between shard nodes and committee nodes, improving the processing efficiency of transactions.

[0005] To achieve the above invention purpose, the transaction synchronization consensus method for a sharded blockchain network based on a committee of the present invention includes the following steps:

[0006] S1: Construct a sharded blockchain network, including user nodes, shard nodes and committee nodes, where:

[0007] The user node is for users. It generates and broadcasts transactions according to the actual transaction needs of users.

[0008] The shard node is used for receiving and verifying transactions in its affiliated shard, pre-building blocks, reaching consensus on and storing confirmed blocks. The number of shard nodes in each shard is determined according to actual needs.

[0009] The committee node is used for receiving and verifying pre-built blocks, building and returning confirmed blocks. The number of committee nodes is determined according to actual needs.

[0010] S2: When a shard node joins the shard blockchain network, it sends an in-chain request to the committee node for registration. After the committee node agrees to the in-chain request, it sends an in-chain proof to the shard node. The committee node sets the number of bits k of the binary address space according to actual needs, where 2 k is greater than or equal to the number of shards N. It generates a k-bit binary code for each shard as the ID of the shard. When the shard node assigns wallet addresses to user nodes in its affiliated shard, it uses the shard ID as part of the user's wallet address.

[0011] S3: When a user needs to transfer funds to another user, the user node constructs a UTXO transaction based on the wallet address of the target user. In this transaction, the payer's wallet address inAddr is the wallet address of the user initiating the transaction, and the payee's wallet address outAddr is the wallet address of the target user. The user node of the user initiating the transaction broadcasts this transaction to the shard blockchain network.

[0012] S4: After receiving the transaction, the shard node parses and determines whether the transaction is relevant to itself. The determination method is as follows:

[0013] The shard node extracts the payer's wallet address inAddr and the payee's wallet address outAddr from the transaction, and then extracts the payer's shard identifier inID and the payee's shard identifier outID respectively. If both the payer's shard identifier inID and the payee's shard identifier outID are different from the shard ID of the shard node, it is not relevant to the current shard node, otherwise it is relevant.

[0014] If the shard node determines that the transaction is not relevant to itself, it discards the transaction. If it is relevant, the shard node deposits the transaction into the unconfirmed transaction pool. The specific method is as follows: If both the payer's shard identifier inID and the payee's shard identifier outID of the transaction are the same as the shard ID of the current shard node, it deposits the transaction into the in-shard unconfirmed transaction pool, otherwise it deposits the transaction into the cross-shard unconfirmed transaction pool.

[0015] S5: Each sharding node selects several transactions from the in-shard unconfirmed transaction pool and the cross-shard unconfirmed transaction pool, validates them, packs the transactions that pass the validation into a pre-built block, and sends it to the committee nodes;

[0016] S6: After receiving the pre-built block, the committee nodes divide it according to shards, and denote the pre-built blocks of shard S i as PB i,j , where i = 1, 2, …, N, j = 1, 2, …, M i , and M i represents the number of sharding nodes in shard S i ; perform the first-phase consensus on the pre-built block PB i of shard S i,j . The specific method is as follows:

[0017] Count the occurrence frequency of each transaction in the M i pre-built blocks PB i,j . If the occurrence frequency of a certain transaction is less than (M i -1) / 2, the first-phase consensus of this transaction fails, and this transaction is discarded. Otherwise, the first-phase consensus of this transaction passes, and this transaction is put into the first-phase confirmed transaction pool PS i of shard S i ;

[0018] S7: For the N first-phase confirmed transaction pools PS i , the committee nodes count the occurrence frequency of each cross-shard transaction among them. If the occurrence frequency is not equal to 2, it means that the payer shard and the payee shard of this cross-shard transaction did not pick up this cross-shard transaction at the same time, and the first-phase consensus of this cross-shard transaction fails, and this transaction is discarded. Otherwise, the first-phase consensus of this cross-shard transaction passes; denote the confirmed transaction pools of each shard after the first-phase consensus of the cross-shard transactions as FP i ;

[0019] S8: Put all the transactions in the N confirmed transaction pools FP i into a confirmed block, calculate a block hash value once to obtain a consensus confirmed block CB, and then split the consensus confirmed block CB according to shards to obtain the consensus confirmed blocks CB i corresponding to each shard, and feedback them from each committee node to the corresponding sharding node;

[0020] S9: After receiving the consensus confirmed block CB i from the committee node, the sharding node judges whether the number of the received same consensus confirmed blocks CB i is greater than a preset threshold. If so, the second-phase consensus passes, and the consensus confirmed block CB iExecute and store in the sharded blockchain network. Otherwise, if the two-phase consensus fails, the consensus for this round of transactions ends.

[0021] The transaction synchronization and consensus method for a sharded blockchain network based on a committee in the present invention constructs a sharded blockchain network, including user nodes, shard nodes, and committee nodes. When a user initiates a transaction, the shard node packages the transaction into a pre-constructed block and sends it to the committee node. After receiving the pre-constructed block, the committee node first conducts the first-phase consensus to obtain the first-phase confirmed transaction pool, and then conducts the first-phase consensus on the cross-shard transactions in the first-phase confirmed transaction pool to obtain the confirmed transaction pool for each shard. Then, it constructs the consensus confirmation area for each shard and distributes it to the corresponding shard node, and the shard node conducts the second-phase consensus on the received consensus confirmation block.

[0022] The present invention has the following beneficial effects:

[0023] 1) In the present invention, through the first-phase consensus, it is ensured that the same cross-shard transactions are synchronously consensus in the same consensus cycle;

[0024] 2) In the present invention, the cross-shard transactions authenticated by the committee node can be directly chained without additional shard information exchange, thereby improving the transaction processing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 is a flowchart of the specific implementation manner of the transaction synchronization and consensus method for a sharded blockchain network based on a committee in the present invention;

[0026] Figure 2 is a structure diagram of the sharded blockchain network in the present invention;

[0027] Figure 3 is an example diagram of the first-phase consensus on the pre-constructed block in this embodiment;

[0028] Figure 4 is an example diagram of the first-phase confirmed transaction pool for each shard in this embodiment;

[0029] Figure 5 is an example diagram of the cross-shard transactions in the confirmed transaction pool in this embodiment;

[0030] Figure 6 is an example diagram of the consensus confirmation block in this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0031] The following describes the specific implementation manner of the present invention in conjunction with the drawings, so that those skilled in the art can better understand the present invention. It should be particularly noted that in the following description, when the detailed description of known functions and designs may dilute the main content of the present invention, these descriptions will be omitted here.

[0032] Embodiment

[0033] Figure 1 is the flowchart of the specific implementation manner of the committee-based sharded blockchain network transaction synchronization consensus method of the present invention. As Figure 1 shown, the flowchart of the committee-based sharded blockchain network transaction synchronization consensus method of the present invention. As Figure 1 shown, the specific steps of the committee-based sharded blockchain network transaction synchronization consensus method of the present invention include:

[0034] S101: Construct a sharded blockchain network:

[0035] In the present invention, it is first necessary to construct a sharded blockchain network. Figure 2 is the structural diagram of the sharded blockchain network in the present invention. As Figure 2 shown, the blockchain nodes in the sharded blockchain network of the present invention include user nodes, shard nodes, and committee nodes, where:

[0036] User nodes are used to face users and generate and broadcast transactions according to the actual transaction needs of users.

[0037] Shard nodes are used for receiving and verifying transactions in the belonging shard, pre-building blocks, consensus and storage of confirmed blocks. The number of shard nodes in each shard is determined according to actual needs.

[0038] Committee nodes are used for receiving and verifying pre-built blocks, constructing confirmed blocks and returning confirmed blocks. The number of committee nodes is determined according to actual needs.

[0039] S102: Allocate shard IDs:

[0040] When a shard node joins the sharded blockchain network, it sends an in-chain request to the committee node for registration. After the committee node agrees to the in-chain request, it sends an in-chain proof to the shard node. The committee node sets the number of bits k of the binary address space according to actual needs, where 2 k is greater than or equal to the number of shards N, and generates a k-bit binary code for each shard as the ID of the shard. When the shard node allocates wallet addresses to user nodes in the belonging shard, the shard ID is used as part of the user wallet address.

[0041] In this embodiment, the shard ID is generated based on the POW (Proof of Work) algorithm. The specific method is: the committee node publishes a random number, and the shard nodes of each shard respectively run the POW algorithm to calculate the hash value (which can be called Ticket) that meets the difficulty according to the random number, convert the hash value into a binary code, and use the last k-bit binary code as the ID of the corresponding shard.

[0042] S103: The user node initiates a transaction:

[0043] When a user needs to transfer funds to another user, the user node constructs a UTXO (full name: Unspent Transaction Output, literally meaning unspent transaction output) transaction based on the wallet address of the target user. In this transaction, the payer wallet address inAddr is the wallet address of the user initiating the transaction, and the payee wallet address outAddr is the wallet address of the target user. The user node of the user initiating the transaction broadcasts this transaction to the sharded blockchain network.

[0044] S104: Construct an unconfirmed transaction pool:

[0045] After receiving the transaction, the shard node parses and determines whether the transaction is relevant to itself. The determination method is as follows:

[0046] The shard node extracts the payer wallet address inAddr and the payee wallet address outAddr from the transaction, and then extracts the payer shard identifier inID and the payee shard identifier outID from them respectively. If both the payer shard identifier inID and the payee shard identifier outID are different from the shard ID of the shard node, it is not relevant to the current shard node; otherwise, it is relevant.

[0047] If the shard node determines that the transaction is not relevant to itself, it discards the transaction. If it is relevant, the shard node deposits the transaction into the unconfirmed transaction pool. The specific method is as follows: If both the payer shard identifier inID and the payee shard identifier outID of the transaction are the same as the shard ID of the current shard node, the transaction is deposited into the in-shard unconfirmed transaction pool; otherwise, the transaction is deposited into the cross-shard unconfirmed transaction pool.

[0048] S105: Package and pre-construct a block and report it:

[0049] Each shard node selects a number of transactions from the in-shard unconfirmed transaction pool and the cross-shard unconfirmed transaction pool for verification, packages the verified transactions into a pre-constructed block, and sends it to the committee node.

[0050] For the selection of transactions, the shard node can divide the priority levels for user nodes according to the actual situation of the shard to which it belongs. When selecting transactions, the higher the priority level of the user, the greater the probability of being selected, thus ensuring the transaction efficiency of important user nodes.

[0051] S106: Conduct the first-phase consensus on the pre-constructed block:

[0052] After receiving the pre-constructed block, the committee node divides it according to shards, and marks each pre-constructed block of shard S i as PB i,j, where \(i = 1, 2, \ldots, N\) and \(j = 1, 2, \ldots, M\) i , \(M\) i represents the number of shard nodes in the shard \(S\) i For the pre - constructed block \(PB\) of the shard \(S\) i perform an aggregation operation. The specific method is as follows: i,j Count the occurrence frequency of each transaction in \(M\)

[0053] pre - constructed blocks \(PB\). If the occurrence frequency of a certain transaction is less than \((M - 1) / 2\), the first - stage consensus of this transaction fails, and this transaction is discarded. Otherwise, the first - stage consensus of this transaction passes, and this transaction is put into the first - stage confirmed transaction pool \(PS\) of the shard \(S\) i pre - constructed blocks \(PB\) i,j If the occurrence frequency of a certain transaction is less than \((M - 1) / 2\), the first - stage consensus of this transaction fails, and this transaction is discarded. Otherwise, the first - stage consensus of this transaction passes, and this transaction is put into the first - stage confirmed transaction pool \(PS\) of the shard \(S\) i - 1) / 2, the first - stage consensus of this transaction fails, and this transaction is discarded. Otherwise, the first - stage consensus of this transaction passes, and this transaction is put into the first - stage confirmed transaction pool \(PS\) of the shard \(S\) i of the shard \(S\) i .

[0054] Figure 3 This is an example diagram of the first - stage consensus on the pre - constructed block in this embodiment. As Figure 3 shown, assume that shard 1 contains 5 shard nodes, and each shard node sends a pre - constructed block \(PB\) 1,1 、\(PB\) 1,2 、\(PB\) 1,3 、\(PB\) 1,4 、\(PB\) 1,5 . Each pre - constructed block contains several selected transactions. There are both intersecting transactions and non - intersecting transactions between the pre - constructed blocks of different nodes. Therefore, the following definitions can be made:

[0055] If a certain transaction is selected by \(n\) nodes, this transaction is the common selected transaction of these \(n\) nodes, and the transaction is called a pending transaction with a selection frequency of \(n\). The set composed of the common selected transactions of these \(n\) nodes is called the intersection \(T\) of the transactions of these \(n\) nodes n .

[0056] Denote the set composed of all pending transactions with a frequency of \(n\) as \(U\) n .

[0057] If the total number of shard nodes in a shard is \(M\) i , then the number of intersections of transactions composed of any \(n\) nodes is , and the union of these intersections is the set \(U\) of all pending transactions with a frequency of \(n\) n .

[0058] As Figure 3 shown, according to a specific selection strategy, it can be ensured that there is an intersection \(T\) of transactions selected by 5 nodes 5, since the total number of nodes is 5, the intersection of transactions composed of any 5 nodes is only 1. Therefore, all pending transaction sets with a frequency of 5 are U 5 = T 5 .

[0059] In the present invention, it is stipulated that the selection frequency of transactions must be higher than f to pass the verification, where f is the number of Byzantine nodes that can be accommodated in a single shard. Therefore, as long as the pending transaction set U n satisfies n > f, then all transactions therein can pass the verification.

[0060] In a shard, the number of Byzantine nodes f and the total number of nodes M i must satisfy the following inequality:

[0061] 2f + 1 ≤ M i

[0062] Therefore, when the total number of nodes is 5, the pending transaction set U n must satisfy the inequality to become a passing set:

[0063] f + 1 ≤ n ≤ 5

[0064] To achieve the maximum security guarantee, in the present invention, the number of Byzantine nodes f is set to the maximum value, that is, (M i - 1) / 2. In this embodiment, f = 2. The passing sets in this embodiment are U 3 = (Tx 6 ), U 4 = (Tx 1 , Tx 3 ), U 5 = (Tx 2 , Tx 4 , Tx 5 , Tx 7 ). Therefore, Figure 3 the transactions that can pass the verification in the shown example are transactions Tx 1 , Tx 2 , Tx 3 , Tx 4 , Tx 5 , Tx 6 , Tx 7 .

[0065] S107: Conduct the first-stage consensus on cross-shard transactions:

[0066] In the first-stage confirmation transaction pool PS i of shard S i , it contains intra-shard transactions and cross-shard transactions. In step S106, the consensus on transaction selection for nodes within each shard is mainly addressed. Next, the inter-shard transaction consensus for participating in cross-shard transactions is mainly processed.

[0067] For the N one - stage confirmed transaction pools PS i , the committee nodes count the occurrence frequency of each cross - shard transaction among them. If the occurrence frequency is not equal to 2, it means that the payer shard and the payee shard of this transaction did not pick up this cross - shard transaction simultaneously, which will lead to the splitting of the consensus of input and output in multiple consensus cycles and will destroy the atomicity of the transaction. Therefore, the first - stage consensus of this cross - shard transaction fails, and this transaction is discarded. Otherwise, the first - stage consensus of this cross - shard transaction passes. Denote the confirmed transaction pools of each shard after the first - stage consensus of the cross - shard transaction as FP i .

[0068] Figure 4 It is an example diagram of the one - stage confirmed transaction pools of each shard in this embodiment Figure 4 Only cross - shard transactions are shown in [diagram]. According to the transaction sharding method of the system in the present invention, cross - shard transactions will be sent to the two shards participating in the cross - shard transaction. For the payer shard, this transaction is a payment transaction, and for the payee shard, this transaction is a deposit transaction. A transaction ultimately performs a withdrawal operation for the payer and a deposit operation for the payee. Only when the payment transaction and the deposit transaction are carried out within the same consensus cycle can the atomicity of the transaction be guaranteed at the minimum cost. If the payer ID of the cross - shard transaction is equal to the shard ID of the passing set, a withdrawal operation is performed in this shard; if the payee ID is equal to the shard ID of the passing shard, a deposit operation is performed in this shard

[0069] If a cross - shard transaction exists in the passing sets of two shards, it is said that this cross - shard transaction meets the atomicity condition and can be verified and passed. As Figure 4 shown, in the one - stage confirmed transaction pool PS 1 of shard 1, there is a withdrawal transaction of transaction CTx 1 , and in the one - stage confirmed transaction pool PS 2 of shard 2, there is a deposit transaction of CTx 1 . Therefore, the withdrawal and deposit operations can be completed in one round of consensus cycle, and the atomicity of the transaction can be guaranteed. So the cross - shard transaction CTx 1 can be verified and passed; while the CTx 3 in the one - stage confirmed transaction pool PS 8 of shard 3 is a deposit transaction, and there is no corresponding withdrawal transaction in the passing set of this round of consensus. So such a cross - shard transaction does not meet the condition of satisfying atomicity. After removing the cross - shard transactions that do not meet the atomicity condition from the one - stage confirmed transaction pool PS i , the confirmed transaction pool FP i of this [shard] is obtained Figure 5 It is an example diagram of cross - shard transactions in the confirmed transaction pool in this embodiment

[0070] S108: Construct a consensus confirmation block:

[0071] Put all the transactions in the N confirmation transaction pools FP i into the confirmation block and calculate the block Hash once to obtain the consensus confirmation block CB. Then, split the consensus confirmation block CB by shard to obtain the consensus confirmation blocks CB i corresponding to each shard, and have each committee member node feedback to the corresponding shard node.

[0072] Figure 6 is an example diagram of the consensus confirmation block in this embodiment. As Figure 6 shown, there are 4 shards in this embodiment. First, perform the block Hash together to obtain the consensus confirmation block CB, and then split it to obtain the consensus confirmation blocks CB i corresponding to 4 shards.

[0073] S109: Two-phase consensus:

[0074] After receiving the consensus confirmation block CB i from the committee node, the shard node determines whether the number of received identical consensus confirmation blocks CB i is greater than a preset threshold (generally 2 / 3 of the number of committee nodes). If so, the two-phase consensus passes, and the consensus confirmation block CB i is added to the shard blockchain network for execution and storage. Otherwise, the two-phase consensus fails, and the current round of transaction consensus ends.

[0075] In the present invention, since the UTXO transaction is adopted, the transaction execution is to update the UTXO transaction pool according to the transactions included in the consensus confirmation block CB i . The specific method is as follows:

[0076] If the transaction is an intra-shard transaction, delete the corresponding UTXO (T in ) from the UTXO transaction pool and add a new UTXO (T out );

[0077] If the transaction is an inter-shard transaction, the processing of this transaction should involve at least two shards. These two shards perform the corresponding withdrawal or deposit operations, that is: if the current shard is the payer shard of this transaction, delete the corresponding UTXO (T in ) from the UTXO transaction pool. If the current shard is the payee shard of this transaction, add a new UTXO (T out ) to the UTXO transaction pool.

[0078] Although the above-described illustrative specific embodiments of the present invention have been described to facilitate the understanding of the present invention by those skilled in the art, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious, and all inventions created using the concept of the present invention are within the scope of protection.

Claims

1. A committee-based sharded blockchain network transaction synchronization consensus method, characterized in that, it includes the following steps: S1: Construct a sharded blockchain network, including user nodes, shard nodes, and committee nodes, where: User nodes are for facing users and generating and broadcasting transactions according to the actual transaction needs of users; Shard nodes are for receiving and verifying transactions in their respective shards, pre-building blocks, reaching consensus on confirmed blocks, and storing them. The number of shard nodes in each shard is determined according to actual needs; Committee nodes are for receiving and verifying pre-built blocks, constructing confirmed blocks, and returning confirmed blocks. The number of committee nodes is determined according to actual needs; S2: When a sharding node joins the sharded blockchain network, it sends an in-chain request to the committee node for registration. After agreeing to the in-chain request, the committee node sends an in-chain proof to the sharding node; the committee node sets the number of bits k of the binary address space according to actual needs, where 2 k is greater than or equal to the number of shards N, and generates a k-bit binary code for each shard as the ID of the shard; when the sharding node allocates wallet addresses to user nodes in the shard it belongs to, it uses the shard ID as part of the user's wallet address; S3: When a user needs to transfer funds to another user, the user node constructs a UTXO transaction based on the wallet address of the target user. In this transaction, the payer's wallet address inAddr is the wallet address of the user initiating the transaction, and the payee's wallet address outAddr is the wallet address of the target user; the user node of the user initiating the transaction broadcasts this transaction to the sharded blockchain network; S4: After receiving the transaction, the shard node parses and determines whether the transaction is relevant to itself. The determination method is as follows: The shard node extracts the payer's wallet address inAddr and the payee's wallet address outAddr from the transaction, and then extracts the payer's shard identifier inID and the payee's shard identifier outID respectively. If both the payer's shard identifier inID and the payee's shard identifier outID are different from the shard ID of the shard node, it is not relevant to the current shard node, otherwise it is relevant; If the shard node determines that the transaction is not relevant to itself, it discards the transaction. If it is relevant, the shard node deposits the transaction into the unconfirmed transaction pool. The specific method is: if both the payer's shard identifier inID and the payee's shard identifier outID are the same as the shard ID of the current shard node, deposit this transaction into the in-shard unconfirmed transaction pool, otherwise deposit this transaction into the cross-shard unconfirmed transaction pool; S5: Each shard node selects a number of transactions from the in-shard unconfirmed transaction pool and the cross-shard unconfirmed transaction pool for verification, packs the verified transactions into pre-built blocks, and sends them to the committee nodes; S6: After receiving the pre-built block, the committee node divides it according to shards, and marks each pre-built block of shard S i as PB i,j , where i = 1, 2, …, N, j = 1, 2, …, M i , and M i represents the number of shard nodes in shard S i ; conduct the first-phase consensus on the pre-built block PB i of shard S i,j , and the specific method is as follows: Count the occurrences of each transaction in M i pre-built blocks PB i,j If the occurrence frequency of a certain transaction is less than (M i -1) / 2, the first-phase consensus of this transaction fails, and this transaction is discarded. Otherwise, the first-phase consensus of this transaction passes, and this transaction is put into the first-phase confirmation transaction pool PS i of shard S i ; S7: For the N one-phase confirmed transaction pools PS i , the committee nodes count the occurrence frequency of each cross-shard transaction among them. If the occurrence frequency is not equal to 2, it means that the payer shard and the payee shard of this transaction did not pick up this cross-shard transaction at the same time, and the first-phase consensus of this cross-shard transaction fails. Discard this transaction. Otherwise, the first-phase consensus of this cross-shard transaction passes; record the confirmed transaction pools of each shard after the first-phase consensus of the cross-shard transaction as FP i ; S8: Put all the transactions in the N confirmation transaction pools FP i into the confirmation block and calculate the block hash value once to obtain the consensus confirmation block CB. Then, split the consensus confirmation block CB by sharding to obtain the consensus confirmation blocks CB i corresponding to each shard, and feedback them from each committee member node to the corresponding shard node; S9: After the sharding node receives the consensus confirmation block CB from the committee node i it determines whether the number of received identical consensus confirmation blocks CB i is greater than a preset threshold. If so, the two-phase consensus passes, and the consensus confirmation block CB i is added to the sharding blockchain network for execution and storage. Otherwise, the two-phase consensus fails and the consensus for this round of transactions ends.

2. The sharded blockchain network transaction synchronization consensus method according to claim 1, characterized in that, The generation of the shard ID in step S2 is implemented using the POW algorithm. The specific method is: The committee node publishes a random number, and the shard nodes of each shard respectively run the POW algorithm to calculate a hash value that meets the difficulty according to this random number, convert this hash value into a binary code, and use the last k bits of the binary code as the ID of the corresponding shard.

3. The sharded blockchain network transaction synchronization consensus method according to claim 1, characterized in that, The specific method for the shard node to select transactions in step S5 is: The shard node divides the priority levels for user nodes according to the actual situation of the shard to which it belongs. When selecting transactions, the higher the priority level of the user, the greater the probability of being selected.

4. The sharded blockchain network transaction synchronization consensus method according to claim 1, characterized in that, The threshold value in the step S9 is 2 / 3 of the number of committee nodes.

Images