A Round-Dependent Hierarchical Consensus Method and a Construction Method for Blockchain Consensus Protocol

Abstract

The present invention provides a round-dependent hierarchical consensus method and a method for constructing a blockchain consensus protocol. During the execution of the round-dependent hierarchical consensus protocol, the output of the current round not only ensures that honest nodes do not submit two different blocks, but also guides honest nodes on how to propose new blocks, select leader nodes, and vote on the values proposed by them in the next round of execution. Applying the round-dependent hierarchical consensus protocol to the blockchain consensus protocol enables the blockchain consensus protocol to avoid invoking the time-consuming BBA protocol and achieve: (1) a fixed constant round size; (2) if the output of the hierarchical consensus is 2, then honest nodes finally confirm the corresponding block and its parent block at the end of the current round of execution, reducing the block confirmation delay; (3) if the leader node is malicious, then the block that has not been finally confirmed by honest nodes in the current round has the opportunity to be finally confirmed by honest nodes at a future time, thereby improving the throughput. This solution is applicable to synchronous networks, and all operations can be deployed in practice, with strong practicality.

Description

Technical Field

[0001] The present invention belongs to the technical fields of computer technology and information security, and relates to a construction method of a round-dependent hierarchical consensus protocol and a method for constructing a high-performance (low-latency, high-throughput) blockchain consensus protocol using the same. Background Art

[0002] Reducing transaction confirmation latency and increasing throughput are two main challenges faced in the design of blockchain consensus protocols. Currently, the design of blockchain consensus protocols is mainly based on two architectures: (1) the Nakamoto type, i.e., selecting a leader node to sign a block based on a certain proof mechanism and having the whole network nodes complete the confirmation of the block; (2) the BFT (Byzantine Fault Tolerance) type, i.e., entrusting the signing and confirmation of the block to a set of nodes (committee). In the execution of the Nakamoto type of protocol, the extension of the chain and the confirmation of the block are executed in parallel, i.e., the size of a round does not depend on whether the corresponding block is finally confirmed. However, due to the difficulty of breaking the trade-off relationship between security and performance, high-performance solutions for this type of protocol can only be achieved under certain conditions, such as no double-spending transactions. The construction scheme of a blockchain consensus protocol based on BFT can achieve deterministic confirmation of a block, i.e., the successful execution of one round of the BFT protocol means that the corresponding block is immediately confirmed by all honest nodes in the network. However, the time for the successful execution of one round of the BFT protocol is vulnerable to the behavior of adversaries, making the size of a round of this type of protocol not fixed, thereby reducing the block confirmation rate. Therefore, achieving both a fixed constant round size and deterministic confirmation of a block will significantly improve the performance of the blockchain consensus protocol.

[0003] The hierarchical consensus protocol outputs the corresponding hierarchy {0, 1, 2} to represent the confidence in other nodes also outputting the same value while ensuring that two honest nodes do not submit different non-empty values. Specifically, if two honest nodes i, j respectively output v 1 , v 2 and the corresponding hierarchies g 1 , g 2 , then: (1) |g 1 - g 2 | ≤ 1; (2) if g 1 ≥ 0, g 2 ≥ 0, then v 1 = v 2 ; (3) if the leader node in the current round is honest and proposes a value v, then v 1 = v 2 = v, g 1 = g 2 = 2.

[0004] Currently, in blockchain consensus protocols, hierarchical consensus is only used as a tool to convert a multi-valued consensus (MVBA) protocol into a binary consensus (BBA) protocol, and the output of the current round of the protocol is determined by the output of the BBA protocol. Since the execution time of the BBA protocol is affected by adversary behavior, the round time of the blockchain protocol is not fixed, and even makes the BBA protocol the most time-consuming part of the entire blockchain protocol. Although the hierarchical consensus protocol can ensure that any two honest nodes confirm two identical non-empty blocks, that is, satisfy consistency, the main reason for still having to call the time-consuming BBA protocol is that the output of the current round of hierarchical consensus is only used to determine the output of the current round of the blockchain consensus protocol (it is possible that some honest nodes confirm a block and complete the extension of the local chain, while another part of the honest nodes confirm a null value). To enable honest nodes to enter the next round of protocol execution in the same state, that is, hold the same latest confirmed block, the protocol must call the BBA protocol to make honest nodes confirm a value (block or null value) simultaneously. Otherwise, even if the leader node of the current round is honest, liveness cannot be guaranteed. Summary of the Invention

[0005] An object of the present invention is to propose a construction method for a round-dependent hierarchical consensus protocol, which can be directly applied to the construction of blockchain consensus protocols to achieve a fixed constant round size and deterministic block confirmation, thereby improving the performance of blockchain consensus protocols in terms of both transaction confirmation latency and transaction throughput.

[0006] Specifically, the round-dependent hierarchical consensus protocol of the present invention has two guiding functions: one is to guide the output of honest nodes in the current round to satisfy consistency; the other is to guide the execution of the next round of the protocol by honest nodes to satisfy liveness, including guiding the leader node to determine the proposed value, guiding honest committee members to determine the local leader node and vote for the corresponding proposed value. Since the round size of the hierarchical consensus protocol is not affected by adversary behavior, constructing a blockchain consensus protocol based on this type of round-dependent hierarchical consensus can achieve a fixed constant round size and effectively avoid calling the time-consuming BBA protocol. Further, (1) the relatively small fixed constant round size increases the number of honest leader nodes in the same period of time under the same fault tolerance conditions; (2) the nature of hierarchical consensus guarantees that if the leader node is honest, the corresponding proposed value will be finally confirmed by all honest nodes; (3) using the hierarchical determination of the output value of the current round of hierarchical consensus protocol to determine the execution of the next round of the protocol, including the proposal of new values and the determination of the leader node, can enable values in a temporary state to have the opportunity to be indirectly confirmed by honest nodes in the future. Based on the above properties, a low-latency and high-throughput blockchain consensus protocol can be constructed by the round-dependent hierarchical consensus protocol and the chain update function.

[0007] To achieve the above objectives, the present invention adopts the following technical solutions:

[0008] Symbol Explanation: Δ represents the upper bound of the communication delay between honest nodes, that is, the message sent by an honest node is received by all honest nodes within Δ time; r≥0 represents the number of rounds, and (r, s) is the s-th step of the r-th round, where s∈{1, 2, 3, 4}; T r,s represents the difficulty target for the s-th step of the r-th round to select committee members for (r, s), str r is the random number for the r-th round; represents the block at position k in the chain signed by node i in the r-th round, is the local chain of node i in the r-th round and ε represents a null value, where B 0 represents the genesis block; represents the grading status at position k of the local chain of node i in the r-th round, where B represents the block at position k of the local chain of node i, and g∈{0, 1, 2} represents the grading of the local status of node i in the r-th round; represents the output value of calculating the VRF (Verifiable Random Function) by node i in the s-th step of the r-th round and the proof (pk i , sk i ) represents the long-term key pair of node i, and represents the temporary key of node i in the s-th step of the r-th round represents the signature of node i on the message with the long-term key sk i in the s-th step of the r-th round, represents the signature of node i on the message with the temporary key in the s-th step of the r-th round; H(·) represents a collision-resistant hash function; n represents the committee size for each step, f is the upper bound of the corrupted nodes in the committee, and n = 3f + 1.

[0009] A round-dependent grading consensus method includes the following steps:

[0010] If the current round is r = 0, then all nodes i update their local chains to the genesis block B 0 , and the grading status is

[0011] All nodes i verify whether they are the leader nodes for the current round r≥1. If so, they sign and broadcast a new block according to the grading status of the previous round ;

[0012] All nodes verify whether they are committee nodes in the voting phase. If so, they select the local leader node and vote for the block signed by it;

[0013] All nodes receive voting information. If they receive ≥2f + 1 valid votes for a certain block, they pre-commit the block, and the committee nodes broadcast their pre-commit messages;

[0014] All nodes receive the set of pre-commit messages. If they receive ≥2f + 1 valid pre-commit messages for a certain block, they commit the block, and the committee nodes broadcast their commit messages and the set of received pre-commit messages;

[0015] All nodes receive the set of commit and pre-commit messages, and determine the local graded state based on the local commit messages and the received message set.

[0016] Furthermore, the round-dependent graded consensus protocol adopted by the above method consists of the algorithms BLOCK PROPOSAL (block proposal), VOTE (vote), PRE-COMMIT (pre-commit), COMMIT (commit), and GRADED STATE (graded state), where:

[0017] 1) Input the current round number r, the temporary key pair of node i Local chain The output of the previous round of the protocol And the set of transactions Tx pre-added to the block; if node i is a committee member in the r-th round, output the signed block message Among them, propose indicates that this message is a signed block message, represents the signed block message of node i;

[0018] 2) Input the temporary key pair of node i If node i is a committee member in step VOTE, output the signed vote message Among them, vote indicates that this message is a vote message, represents the voted block of node i;

[0019] 3) Input the temporary key pair of node i If node i is a committee member in step PER-COMMIT, output the signed pre-commit message Among them, precommit indicates that this message is a pre-commit message, represents the pre-commit message of node i;

[0020] 4) Input the temporary key pair of node i If node i is a committee member in step COMMIT, output the signed commit message and the set of received pre-commit messages Among them Among them, "commit" indicates that this message is a commit message, indicating that node i represents the commit message of the node;

[0021] 5) Input the current round number r, and output the local graded state of node i

[0022] Furthermore, the construction method of the above-mentioned round-dependent graded consensus protocol includes the following steps:

[0023] Step 1 BLOCK PROPOSAL (block proposal): The leader node proposes a candidate block based on the output of the previous round, and all nodes start a Δ-time timer vote-timer r,1 = Δ; where, vote-timer r,1 represents the timer for entering the voting stage;

[0024] Step 2 VOTE (vote): If vote-timer r,1 = 0, the committee members determine the local leader node based on the output of the previous round and sign a vote on the corresponding proposed value. All nodes start a Δ-time timer precommit-timer r,2 = Δ; where, precommit-timer r,2 represents the timer for entering the pre-commit stage;

[0025] Step 3 PRE-COMMIT (pre-commit): If precommit-timer r,2 = 0, each node determines whether to pre-commit this block or pre-commit the null value ε based on the received vote message set. The committee node outputs the pre-commit value, and all nodes start a Δ-time timer commit-timer r,3 = Δ; where, commit-timer r,3 represents the timer for entering the commit stage;

[0026] Step 4 COMMIT (commit): If commit-timer r,3 = 0, each node determines whether to commit this block or commit the null value ε based on the received pre-commit message set. The committee node outputs the commit value and the local pre-commit message set, and all nodes start a Δ-time timer state-timer r,4 = Δ; where, state-timer r,4 represents the timer for entering the graded state stage;

[0027] Step 5 GRADED STATE (graded state): If state-timer r,4= 0, each node updates its local state according to the received pre-commit and commit t message sets and the local commit value.

[0028] Preferably, step 1 specifically includes:

[0029] 1) Determine whether the output of the previous round is empty, that is, if then let be the latest non-empty state locally, that is,

[0030] 2) Run to determine whether it is the leader node. If then continue, otherwise execute step 2; where MEMBER SELECTION[r,1,pk i ,sk i ,T r,1 ,st r represents the committee member selection algorithm for step 1 of the r-th round. The input is the current round number r, step 1, the public-private key pair (pk i ,sk i ) of node i, the current difficulty target T r,1 and the random number st of the current round r r , and the output is If then is selected, otherwise

[0031] 3) Determine the position to propose a block according to as extended block or replacement block

[0032] 4) Broadcast the signed block and evidence Delete the temporary key where represents the block information signed by node i.

[0033] Preferably, step 2 specifically includes:

[0034] 1) All nodes receive the propose message set

[0035] 2) Run to determine whether it is a committee member of step 2. If then continue, otherwise execute step 3; where MEMBER SELECTION[r,2,pk i ,sk i ,T r,2 ,st rDenotes the committee member selection algorithm for the second step of the r-th round. The inputs are the current round number r, step 2, the public-private key pair (pk i , sk i ) of node i, the current difficulty target T r,2 and the random number st of the current round r r , and the output If then is selected, otherwise

[0036] 3) Run Select the local leader node from the set of leader nodes according to the output of the previous round where denotes the local leader node selection algorithm. The inputs are the current round r and the latest local grading status of node i and the output is the selected local leader node

[0037] 4) Sign and broadcast the vote and evidence for the new block proposed by the leader node Delete the temporary key where denotes the voting block of node i.

[0038] Preferably, step 3 specifically includes:

[0039] 1) All nodes receive the vote message set

[0040] 2) Run Verify the validity of the vote message set to ensure that all messages in the set are signed by the committee nodes in step 2 and each node signs only one valid vote message; where denotes the vote message verification algorithm. The input is the received vote message set and the output is the updated vote message set

[0041] 3) All nodes check the updated vote message set to see if there is a vote count for a certain block ≥ 2f + 1. If so, let the message otherwise let the message

[0042] 4) Run Judge whether it is a committee member in step 3. If then continue, otherwise execute step 4; where MEMBER SELECTION[r,3,pk i , sk i , Tr,3 ,st r represents the committee member selection algorithm for the 3rd step of the r-th round. The inputs are the current round number r, step 3, the public-private key pair (pk i ,sk i ) of node i, the current difficulty target T r,3 and the random number st of the current round r r , and the output If then is selected, otherwise

[0043] 5) Sign and broadcast the local pre-commit message and evidence Delete the temporary key Among them, represents the pre-commit message of node i;

[0044] Preferably, step 4 specifically includes:

[0045] 1) All nodes receive the pre-commit message set

[0046] 2) Run to verify the validity of the pre-commit message set, ensuring that all messages in the set are signed by the committee nodes in step 3 and each node only signs one valid pre-commit message; among them, represents the pre-commit message verification algorithm, and the input is the received pre-commit message set The output is the updated pre-commit message set

[0047] 3) All nodes check the updated pre-commit message set to see if there is a vote count for a certain block ≥ 2f + 1. If so, let the message Otherwise, let the message

[0048] 4) Run to determine whether it is a committee member in step 4. If then continue, otherwise execute step 4; among them, MEMBER SELECTION[r,4,pk i ,sk i ,T r,4 ,st r represents the committee member selection algorithm for the 4th step of the r-th round. The inputs are the current round number r, step 4, the public-private key pair (pk i ,sk i ) of node i, the current difficulty target T r,4 and the random number st of the current round r r , and the output If then is selected, otherwise

[0049] 6) Issue the local commit message and evidence Broadcast And delete the temporary key Among them, represents the commit message of node i;

[0050] Preferably, step 5 specifically includes:

[0051] 1) Initialize the state of the k-th position of the local chain of node i to be empty

[0052] 2) If r = 0, then let All nodes set the grading of the genesis block B 0 to be 2;

[0053] 3) Otherwise, all nodes receive the set of commit messages broadcast by the committee members in step 4 and the set of pre-commit messages and determine the local state according to whether the proof of the local commit block is still valid (there are still ≥ 2f + 1 pairs of valid pre-commit values for the blocks in the set ), or only received a consistent set of pre-commit messages for the block or neither of the two is satisfied to be

[0054] The output of all honest nodes in step GRADED STATE satisfies the three properties of the graded consensus protocol, which can be guaranteed by the necessary and sufficient condition that there exists a valid non-empty commit value in the whole network defined by the present invention, that is:

[0055] If there exists a valid commit block B in the whole network k , if and only if after step COMMIT, all honest nodes receive a pre-commit message The set satisfies: there exists a subset

[0056] 1) The size of the subset is

[0057] 2) Each element in the subset satisfies: there are ≥ f + 1 valid pre-commit messages for the block B k , and ≤ f valid pre-commit messages for the null value ε.

[0058] Furthermore, the method for determining the signing block position in step BLOCK PROPOSAL is as follows:

[0059] If the output of the previous round of local grading status or step GRADED STATE is (B k , r - 1, 2), then sign and broadcast the new block B k+1 Expand block B k ; where k represents the position of the block in the chain;

[0060] If the output of the previous round of local grading status or step GRADED STATE is (B k , r - 1, 1), then sign the new block B k+1 Expand block B k , and broadcast block B k and B k+1 ;

[0061] If the output of the previous round of local grading status or step GRADED STATE is (B k , r - 1, 0), then sign and broadcast the new block B' k to replace block B k .

[0062] Furthermore, the committee nodes select local leader nodes and vote on the blocks signed by them, and ensure that honest leader nodes are selected by all honest committee nodes.

[0063] Furthermore, the selection of the leader node is determined by the output of the previous round of grading status or step GRADED STATE for the local leader node:

[0064] If the previous round of grading status is (B k , r - 1, 2) or (B k , r - 1, 1) and a valid commit message for B k has been received, then select the holder of the minimum VRF value from the subset of the received propose set whose signed block is B k+1 as the local leader node;

[0065] Otherwise, select the holder of the minimum VRF value from the subset of the received propose set whose signed block is B' k or the signed block B k+1 and broadcast (B k , B k+1 ) as the local leader node.

[0066] Furthermore, the committee nodes vote on the newly signed blocks of the local leader nodes.

[0067] Further, in steps PRE-COMMIT and COMMIT, all nodes are required to sign local pre-commit and commit messages, and only the corresponding committee members broadcast the messages.

[0068] Further, in step COMMIT, the committee nodes are required to broadcast the local commit messages and the set of pre-commit messages received simultaneously.

[0069] Further, the method for determining the local graded state in step GRADED STATE according to the local commit messages and the messages broadcast by the committee in step COMMIT received is as follows:

[0070] If the local committed block is B k and the evidence of its validity is still valid, then set the local graded state to (B k , r, 2);

[0071] If the local committed block B k is invalid or a null value ε is committed, but a set of consistent pre-commit messages regarding block B k is received, then set the local graded state to (B k , r, 1);

[0072] Otherwise, if the local pre-commit value is B k , then set the local graded state to (B k , r, 0); otherwise set the local graded state to the null value ε.

[0073] Another object of the present invention is to directly apply the proposed round-dependent graded consensus protocol to the design of a high-performance blockchain consensus protocol. Specifically, all nodes decide to directly confirm the corresponding block and indirectly confirm its parent block or not update the local state according to the output of the local step 5 in the current round. The present invention determines how to update the local state based on the output of the graded consensus protocol without the need to additionally call the BBA protocol. Therefore, the present invention reduces the round size of the blockchain consensus protocol to a fixed constant and ensures the security of the blockchain consensus protocol, namely consistency and liveness, by the nature of the graded consensus protocol.

[0074] A construction method of a high-performance (low latency, high throughput) blockchain consensus protocol proposed by the present invention, the steps of which include:

[0075] Node i executes the round-dependent graded consensus method described above to obtain the local graded state where, represents the grading of the local state of node i in the r-th round;

[0076] Node i decides to use the block B according to the local graded state k ​Add it and its parent block to the local chain or do not update the local chain.

[0077] Furthermore, the method for node i to update the local chain is as follows:

[0078] If and there exists then confirm block B k and its corresponding parent block; otherwise, confirm block B k ;

[0079] If then do not confirm any block, that is, do not update the local chain.

[0080] The present invention integrates the output of the current round of hierarchical consensus protocol into the execution of the next round of hierarchical consensus protocol, ensuring the secure operation of honest nodes in any two adjacent rounds, that is, ensuring consistency and liveness. Specifically, it includes the following two important aspects:

[0081] I. Construction of round-dependent hierarchical consensus protocol

[0082] The present invention consists of five algorithms: BLOCK PROPOSAL, VOTE, PRE-COMMIT, COMMIT, and GRADED STATE. The security is based on the (temporary key) digital signature algorithm and the security of VFR, and the assumption that the adversary controls less than 1 / 3 of the network resources and less than 1 / 3 of the resources in each step committee.

[0083] This hierarchical consensus protocol has the following properties: 1) The output of each round of the protocol satisfies the three basic properties of the hierarchical consensus protocol. 2) The output of each round of the protocol is used to guide the execution of the next round of the protocol, including proposing new blocks and voting for the proposed values of local leader nodes, ensuring that the three basic properties of the hierarchical consensus protocol are still satisfied when there are malicious leader nodes in multiple consecutive rounds with a certain probability.

[0084] II. Applying the round-dependent hierarchical consensus protocol to the BFT-based high-performance blockchain consensus protocol

[0085] The output of the round-dependent hierarchical consensus protocol can directly guide the node to update the local state, including directly confirming the block and indirectly confirming its parent block or not updating the local state, and the execution of the next round of the protocol, including how to propose new blocks and select local leader nodes.

[0086] The execution of this blockchain consensus protocol has the following properties: 1) The execution time of each round of the protocol is a fixed constant (4Δ); 2) If the leader node in the current round is honest, all honest nodes will eventually confirm the block it proposes, and the block confirmation delay is 4Δ; 3) If the leader node in the current round is malicious, the block it proposes has a chance to be indirectly confirmed by honest nodes at a future time, and the expected time of block confirmation delay is 28Δ; 4) The average time of block confirmation delay of this blockchain consensus protocol is 10.4Δ; 5) The expected throughput of this blockchain consensus protocol is 0.9 block / round. Description of the Drawings

[0087] Figure 1 It is a schematic construction diagram of a blockchain consensus protocol based on a round-dependent hierarchical consensus protocol.

[0088] Figure 2 It is an example diagram of the execution process of a blockchain consensus protocol based on a round-dependent hierarchical consensus protocol. Detailed Implementation Manner

[0089] To make the above features and advantages of the present invention more obvious and understandable, the technical solution of the present invention will be further described below through specific embodiments.

[0090] I. Elliptic Curve Signature Scheme

[0091] In the present invention, the leader node uses the elliptic curve signature scheme to sign the block. The node obtains the public-private key pair through the corresponding algorithm before participating in the consensus, and uses the public-private key pair to participate in the consensus. In particular, the public key represents the identity information of the node, and the obtained public-private key pair is also used to calculate the VRF.

[0092] 1) Gen(seed) → (pk, sk): Key generation algorithm, input the random seed seed, output the public-private key pair (pk, sk);

[0093] 2) Sig(sk; m) → σ: Signature algorithm, input the message m and the private key sk, output the signature σ;

[0094] 3) Ver(pk, m, σ) → {0, 1}: Signature verification algorithm, input the public key pk, the message m and the signature σ, if the signature σ is correct, return 1, otherwise return 0.

[0095] II. Generation of Temporary Keys

[0096] In the present invention, committee members use temporary keys to sign messages, which can effectively resist dynamic adversary attacks. Here, an identity-based signature scheme is used, and its key generation process is as follows:

[0097] 1) The trusted center generates the master public-private key pair (PMK, SMK);

[0098] 2) Given the identity information PK of node i and (r, s), the trusted center generates the private key corresponding to step (r, s) for node i using SMK where the temporary key corresponds to the identity information PK of node i.

[0099] III. Verifiable Pseudorandom Function

[0100] In the present invention, at each step of the protocol execution, the node determines whether it is a member of the committee for the current step by locally calculating the VRF value, which can effectively resist dynamic adversary attacks.

[0101] 1) Gen(1 λ ) → (pk, sk): Key generation algorithm, which takes the security parameter λ as input and outputs the public-private key pair (pk, sk);

[0102] 2) VRF sk (x) → (h, π): VRF calculation algorithm, which takes the private key sk and the message x as input and outputs the VRF value h and the validity verification evidence π;

[0103] 3) Ver pk (x, h, π) → {0, 1}: Verification algorithm, which takes the public key pk, the message x, the VRF value h and the validity verification evidence π as input and outputs 1 if the VRF value h is correctly calculated, otherwise outputs 0.

[0104] The verifiable pseudorandom function (VRF) has the following properties:

[0105] 1) Uniqueness: There does not exist (pk, x, h 1 , h 2 , π 1 , π 2 ) that satisfies Ver pk (x, h 1 , π 1 ) = Ver pk (x, h 2 , π 2 ) = 1 unless h 1 = h 2 ;

[0106] 2) Provability: If VRF sk (x) = (h, π), then Ver pk (x, h, π) = 1;

[0107] 3) Pseudorandomness: For any probabilistic polynomial-time algorithm A = (A E , A J)When the input is 1 λ it executes s(λ) steps in total and does not query x. The adversary A breaks the pseudorandomness with probability, where negl(λ) represents a negligible function with respect to λ:

[0108]

[0109] IV. Round-Dependent Hierarchical Consensus Protocol

[0110] Suppose node i is currently in round r ≥ 0, holding the long-term key pair (pk i , sk i ) and the temporary key pair The round-dependent hierarchical consensus protocol mainly includes algorithms: BLOCK PROPOSAL (MEMBER SELECTION for committee selection), VOTE (LOCAL LEADER ELECTION for local leader selection), PRE-COMMIT, COMMIT, GRADED STATE, and CHECK VALIDITY.

[0111] 1) If r = 0, then node i sets the local chain to and the graded state to

[0112] 2) Otherwise:

[0113] 2.1)

[0114] 2.1.1) Node i verifies whether If so, then set where

[0115] 2.1.2) Node i calculates If then set Node i is the leader node in round r; otherwise

[0116] 2.1.3) If then set Otherwise, if then sign the candidate block Extend the block and set If then sign the block Extend the block and set If then sign the block to replace the block And let Finally, delete the temporary key And broadcast the message

[0117] 2.2)

[0118] 2.2.1) Node i receives the propose message set

[0119] 2.2.2) Node i calculates If Then let Node i is a committee member; otherwise

[0120] 2.2.3) If Then let Otherwise

[0121] Node i verifies the validity of the received proposal set and deletes the messages signed by non - leader nodes or a leader node multiple times;

[0122] If Or And has received a valid proposal for the block Intersection oaij it message, then let:

[0123]

[0124] Otherwise let:

[0125]

[0126] Let

[0127] 2.2.4) If Then let Otherwise let

[0128] 2.2.5) Delete the temporary key And broadcast the vote message

[0129] 2.3)

[0130] 2.3.1) Node i receives the vote message set

[0131] 2.3.2) Node i verifies the validity of the received vote set and deletes the messages issued by non-committee members or a committee member multiple times;

[0132] 2.3.3) Set If there are ≥ 2f + 1 votes for the block in it, then let Otherwise, let

[0133] 2.3.4) Node i calculates If then let Node i is a committee member; otherwise

[0134] 2.3.5) If then delete the temporary key and broadcast the pre-commit message

[0135] 2.4)

[0136] 2.4.1) Node i receives the pre-commit message set

[0137] 2.4.2) Node i verifies the validity of the received vote set and deletes the messages issued by non-committee members or a committee member multiple times;

[0138] 2.4.3) Set If there are ≥ 2f + 1 pre-commit messages for the block in it, then let Otherwise, let

[0139] 2.4.4) Node i calculates If then let Node i is a committee member; otherwise

[0140] 2.4.5) If then delete the temporary key issued and broadcast the message

[0141] 2.5)

[0142] 2.5.1) Node i receives the commit message set and the pre-commit message set

[0143] 2.5.2) If For the set is valid, then if Let Otherwise. Let

[0144] 2.5.3) If For the set is invalid or and there exists a set of consistent pre-commit messages for the block in, then if Let Otherwise, let

[0145] 2.5.4) If and there does not exist a consistent set for the block in:

[0146] If then if Let Otherwise, let

[0147] Otherwise, let

[0148] V. Application of the present invention in blockchain consensus protocols

[0149] The blockchain consensus protocol mainly includes a round-dependent hierarchical consensus protocol and the algorithm STATUS, including the following steps:

[0150] 1) Node i executes the hierarchical consensus protocol and obtains the output

[0151] 2)

[0152] 2.1) If then if Let Otherwise, let where node i holds and r'≤r”<r, represents the rightmost block of the chain and represents the pointer of the block i.e., the hash value of its parent block, and || means linking the block to the chain;

[0153] 2.2) Otherwise, let

[0154] The blockchain consensus protocol constructed by the present invention can be used in relevant application scenarios of public blockchains and consortium blockchains. In particular, in a consortium blockchain, the selection of committee members at each step is no longer based on the rights and interests of participating nodes, but is completed by the corresponding participating party access mechanism, such as the identity information of participating nodes. Typical application scenarios include fields / scenarios with high requirements for trust, security, and persistence, such as finance, asset registration, voting, management, and the Internet of Things. For example, when applying blockchain technology to the financial industry, it can eliminate the third-party intermediary link and achieve direct peer-to-peer docking, thus greatly reducing costs while quickly completing transaction payments. However, when the consensus protocols adopted by existing blockchain technologies are applied to meet the actual demands of massive business concurrency and high-frequency transactions, problems in performance have become increasingly prominent, seriously affecting the industrial development and practical effective application of blockchain technology. For example, the Bitcoin consensus protocol can process a maximum of 7 transactions per second, and the confirmation of each transaction requires waiting for 6 blocks, that is, at least 1 hour. By using the method of the present invention, it is possible to: (1) reduce the execution time of each round of the consensus protocol to a fixed constant 4Δ, where Δ is the upper bound of the message sending delay between honest nodes in the actual network; (2) if the leader node in the current round is honest, the block signed by it will be finally confirmed by all honest nodes at the end of the execution of this round of the protocol; (3) within a continuous period of time and in the same adversary environment, increase the number of honest leader nodes, and thus increase the number of block confirmations. Generally speaking, by using the method of the present invention, it is possible to reduce the block confirmation delay, improve the system transaction throughput, and meet the actual demands in large-scale application scenarios.

[0155] The above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Those of ordinary skill in the art can modify or equivalently replace the technical solutions of the present invention. The protection scope of the present invention shall be subject to what is described in the claims.

Claims

1. A round-dependent hierarchical consensus method, characterized in that, the following steps are adopted to execute the hierarchical consensus protocol: If the current round is r = 0, then all nodes i update their local chains to the genesis block B 0 , and the hierarchical status is All nodes \(i\) verify whether they are the leader nodes in the current round \(r\geq1\). If so, they sign and broadcast a new block according to the grading status of the previous round ; where represents the grading status of the local chain of node \(i\) at position \(k\) in the \((r - 1)\)-th round; where \(B\) represents the block at position \(k\) of the local chain of node \(i\), and \(g\in\{0,1,2\}\) represents the grading of the local status of node \(i\) in the \((r - 1)\)-th round; All nodes verify whether they are committee nodes in the voting phase. If so, select the local leader node and vote for the block signed by it; All nodes receive voting information. If ≥2f + 1 valid votes for a certain block are received, pre-commit the block, and the committee nodes broadcast their pre-commit messages; where f represents the upper bound of the corrupted nodes in the committee at each stage; All nodes receive the pre-commit message set. If ≥2f + 1 valid pre-commit messages for a certain block are received, commit the block, and the committee nodes broadcast their commit messages and the received pre-commit message set; All nodes receive the commit and pre-commit message sets, and determine the local hierarchical status according to the local commit message and the received message sets; The hierarchical consensus protocol consists of algorithm B LOCK P ROPOSAL 、V OTE 、P RE -C OMMIT 、C OMMIT and G RADED S TATE and B LOCK P ROPOSAL represents block proposal, V OTE represents voting, P RE -C OMMIT represents pre-commit, C OMMIT represents commit, and G RADED S TATE represents the hierarchical status, where: 1) Input the current round number r and the temporary key pair of node i Local chain Output of the previous round of the protocol And the set of transactions Tx pre-added to the block; if node i is a committee member in the r-th round, output the signed block message Among them, propose indicates that this message is a signed block message, represents the output of the pseudo-random function that can be verified by node i by calculating VRF, represents the signed block message of node i, represents that node i uses the temporary key to sign the message; 2) The temporary key pair of input node i If node i is a committee member in step VOTE, output the signed voting message where vote indicates that this message is a voting message represents the output of the VRF calculated by node i represents the voting block of node i represents that node i uses the temporary key to sign the message 3) The temporary key pair of input node i If node i is a committee member in step P ER -C OMMIT then output the signed pre-commit message where pre-commit indicates that the message is a pre-commit message, represents the output of node i calculating VRF, represents the pre-commit message of node i, represents that node i uses the temporary key to sign the message; 4) The temporary key pair of input node i If node i is a committee member in step COMMIT, output the signed commit message and the set of received pre-commit messages where where commit indicates that the message is a commit message represents the output of node i calculating VRF represents the commit message of node i represents that node i uses the temporary key to sign the message; 5) Input the current round number r and output the local grading status of node i Among them, the BLOCK PROPOSAL algorithm includes: 1) Determine whether the output of the previous round is empty, that is, if then let be the latest non-empty state locally, that is 2) Run Determine whether it is the leader node. If then continue; otherwise, execute step 2. Among them, M EMBER S ELECTION [r, 1, pk i , sk i , T r,1 , st r represents the committee member selection algorithm for the first step of the r-th round. The input is the current round number r, step 1, the public-private key pair (pk i , sk i ) of node i, the current difficulty target T r,1 and the random number st of the current round r r , and the output If then is selected; otherwise 3) According to determine that the position of the proposed block is Expand the block or Replace the block 4) Broadcast-signed blocks and evidence Delete the temporary key Among them represents the block information signed by node i In step B LOCK P ROPOSAL The method for determining the position of the issued block is as follows: If the local grading status of the previous round or the output of step G RADED S TATE is (B k , r - 1, 2), then sign and broadcast the new block B k+1 Extended block B k ; where k represents the position of the block in the chain; If the local grading status or the output of step G in the previous round RADED S TATE is (B k , r - 1, 1), then issue a new block B k+1 Expand block B k , and broadcast block B k and B k+1 ; If the local grading status or the output of step G in the previous round RADED S TATE is (B k , r - 1, 0), then issue and broadcast a new block B' k to replace block B k ; The committee nodes select a local leader node and vote on the block signed by it, and ensure that the honest leader node is selected by all honest committee nodes. The selection of the local leader node is determined by the grading status of the previous round or the output of step G RADED S TATE to determine the local leader node: If the grading status of the previous round is (B k , r-1, 2) or (B k , r-1, 1) and a valid submission message of B k has been received, then select the holder of the minimum VRF value from the subset of the proposed blocks to be B in the received propose set k+1 as the local leader node; Otherwise, select the issued block B' from the received propose set k or the issued block B k+1 and broadcast the holder of the minimum VRF value in the subset of (B k , B k+1 ) as the local leader node; At step G RADED S TATE The method for determining the local grading status according to the local commit message and the message broadcast by the committee in step COMMIT received is as follows: If the local committed block B k and its validity evidence is still valid, then set the local grading status to (B k , r, 2); If the local submission block B k is invalid or the submitted null value ε is received, but a set of consistent pre - submission messages about block B k is received, then set the local grading status to (B k , r, 1); Otherwise, if the local pre-submission value is B k , then set the local grading status to (B k , r, 0); otherwise, set the local grading status to the null value ε.

2. The round-dependent hierarchical consensus method according to claim 1, characterized in that, the committee nodes vote for the newly signed block of the local leader node.

3. The round-dependent hierarchical consensus method according to claim 1, characterized in that, At step P RE -C OMMIT and C OMMIT require all nodes to issue local pre-commit and commit messages, only the corresponding committee members broadcast messages, and at step COMMIT, require committee nodes to broadcast local commit messages and the set of pre-commit messages received at the same time.

4. The round-dependent hierarchical consensus method according to claim 1, characterized in that, for determining the local hierarchical status, first define the necessary and sufficient conditions for the existence of a valid committed block in the whole network, and its main content is: If there is a valid committed block Bk in the entire network, if and only if after step C OMMIT all honest nodes receive a pre-commit message The set satisfies: there exists a subset 1) Subset has a size of 2) Subset Each element in satisfies: there are ≥ f + 1 valid pre-commit messages for block B k and ≤ f valid pre-commit messages for null value ε.

5. A method for constructing a high-performance blockchain consensus protocol, characterized in that, it includes the following steps: Node i executes the round-dependent hierarchical consensus method described in any one of claims 1 to 4 to obtain the local hierarchical state wherein represents the grading of the local state of node i in the r-th round; Node i decides whether to add block B and its parent block to the local chain or not update the local chain according to its local grading status; The method for node i to update the local chain is as follows: k ​ If and there exists r' < r, then confirm block B k and its corresponding parent block, otherwise, confirm block B k ; If then no blocks are confirmed, i.e., the local chain is not updated.

Images