Block chain consensus method based on speculation block output

Abstract

A block chain consensus method based on speculation block output comprises the steps that initialization of a block chain system is carried out, each node needs to be registered during initialization, a public and private key pair used for threshold signature is generated, and after initial connection is established among all the nodes, in the process that the system reaches consensus, the public and private key pair is generated; each honest node in the block chain system participates in the consensus according to a speculation block-out and parallel voting mechanism, block-out, voting, verification or rollback operation is independently carried out, and the consensus is achieved among the nodes through multiple rounds of message propagation. According to the method, voting and block discharging processes are disassembled, voting is independently carried out on each block, a consensus is completed by adopting a block discharging and voting parallel mechanism, and a quick block discharging mode of speculation block discharging is adopted during normal operation, so that the time delay of waiting for voting of a previous block is avoided, and the efficiency of voting is improved. The performance problem caused by waiting for a voting result in a traditional Byzantine consensus block chain system is overcome, so that the system can generate a new block without waiting for the voting result, and the security and activity of the block chain system are ensured while the block generation speed and the overall throughput of the system are remarkably improved.

Description

Technical Field

[0001] The present invention relates to a technology in the field of blockchain, specifically a blockchain consensus method based on speculative block generation. Background Art

[0002] The existing blockchain Byzantine Fault Tolerance (BFT) consensus technology widely adopts the "proposal-voting" mechanism. Even in the pipeline form, the interval between block proposals is at least two rounds of communication delay. That is, after proposing a block, it is necessary to wait for at least one round of votes to be collected before proposing the next block. The system's throughput limit is limited by two rounds of communication delays. Summary of the invention

[0003] In view of the deficiency of the prior art that the restrictions on malicious nodes in the network are more stringent, resulting in limited application scenarios, the present invention proposes a blockchain consensus method based on speculative block generation, which decomposes the voting and block generation processes, independently votes on each block and adopts a mechanism of parallel block generation and voting to complete consensus, and adopts a fast block generation method of speculative block generation during normal operation, thereby avoiding the time delay of waiting for the voting of the predecessor block, overcoming the performance problem caused by waiting for the voting results in the traditional Byzantine consensus blockchain system, so that the system can generate new blocks without waiting for the voting results, thereby significantly improving the block generation speed and the overall throughput of the system while ensuring the security and activity of the blockchain system.

[0004] The present invention is achieved through the following technical solutions:

[0005] The present invention relates to a blockchain consensus method based on speculative block generation, comprising:

[0006] Step 1: Initialize the blockchain system. Each node needs to be registered during initialization, generate a public-private key pair for threshold signature, and establish an initial connection between all nodes.

[0007] Step 2: In the process of reaching a consensus in the system, each honest node in the blockchain system participates in the consensus according to the speculative block generation and parallel voting mechanism, independently performs block generation, voting, verification or rollback operations, and reaches a consensus between nodes through multiple rounds of message propagation. Specifically, the master node proposes a new block according to the current state, and broadcasts the new block as a proposal message to all replica nodes. After receiving the proposal message, the replica nodes verify the legitimacy according to the voting rules and vote. The corresponding master node collects and aggregates votes, generates and broadcasts the quorum certificate (QC), and then collects votes again. After multiple rounds of voting, a consensus is reached on the new block. After receiving the proposal message, the next master node directly generates the next new block without waiting for the voting result.

[0008] The message refers to: block (Block), vote (Vote) or quorum certificate (QC).

[0009] In the consensus process, the block generation operation and the voting operation are carried out in parallel and each node in the blockchain system maintains state variables such as view number (ViewNumber), switch QC (TransQC) and lock QC (lockedQC), so as to track the current state of the system and important data during the execution process.

[0010] The block generation operation includes: fast block generation under normal circumstances and stable block generation under abnormal circumstances.

[0011] The voting operation is a four-stage three-round voting mode, including a preparation stage (Prepare), a pre-commit stage (PreCommit), a commit stage (Commit) and a decision stage (Decide).

[0012] In the consensus process described above, when the blockchain system detects an abnormal situation, a fallback mechanism is triggered and a new consensus is reached by using stable blocks.

[0013] The abnormal situation is that the number of views of the block that has completed final confirmation lags behind the number of current views by a large amount, and the difference in the number of views is usually set to 10.

[0014] The rollback mechanism includes: each node sends a view switching message (View-Change message) to the master node it recognizes. The master node needs to first collect View-Change messages from (nf) replica nodes. The message will carry the switching certificate (TransQC) of the replica and a partial signature for the switching view number (the partial signature here is not a certificate, and the certificate is generated by aggregating partial signatures); the master node selects the highest view switching certificate (TransQC) as the highest certificate (highQC), aggregates partial signatures to generate a view switching certificate (ViewChangeQC), generates a new block with the block corresponding to highQC as the parent block and broadcasts it; after receiving the new block, the replica node abandons the block higher than the ViewNumber, that is, abandons the fast block previously generated in a speculative manner to achieve the rollback purpose.

[0015] The present invention relates to a system for implementing the above method, comprising: a block generation unit, a block verification unit, a vote generation unit, a vote collection unit and a certificate verification unit, wherein: the block generation unit determines whether it is a master node according to the number of views, and if it is a master node, generates a new block according to the parent block; the block verification unit performs block legitimacy judgment according to the received block, thereby deciding whether to vote; the certificate verification unit verifies the legitimacy of the certificate and determines whether to vote according to the received certificate; the vote generation unit partially signs the message according to its own key to obtain a voting message; the vote collection unit performs aggregation processing according to the collected votes to obtain a legal number certificate. Technical Effects

[0016] The present invention uses a speculative block generation mechanism to enable the blockchain system to directly generate new blocks without waiting for the voting results of the previous blocks. It adopts a parallel voting architecture to separate the block generation and voting processes and execute them in parallel, avoiding the performance problems caused by waiting for voting results in traditional blockchain systems. The fallback mechanism ensures that the system can fall back to the most recent stable state when an abnormal situation occurs, and re-initiate consensus to ensure the security and activity of the system. Compared with the prior art, the present invention significantly improves the system throughput, reduces consensus delay, and enables the blockchain system to adapt to different network states through flexible block generation and voting strategies. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a schematic diagram of the effect of the embodiment;

[0018] Figure 2 It is the main flow chart of the present invention;

[0019] Figure 3 A data diagram of the maintenance state required for the execution of the protocol;

[0020] Figure 4 It is a schematic diagram of the four-stage mode of the present invention;

[0021] Figure 5 Provide a flowchart for block proposal and voting;

[0022] Figure 6 It is the sequence diagram of the fallback mechanism;

[0023] Figure 7 Schematic diagram of technical solutions for different situations of blockchain system;

[0024] Figure 8 This is a schematic diagram of the overall system architecture of the blockchain system;

[0025] Fig. 9 This is a schematic diagram of the main topology module structure of the blockchain system. DETAILED DESCRIPTION

[0026] like Fig. 9 As shown, the blockchain system of the application scenario of this embodiment is a distributed system with n nodes, in which all nodes constitute a set of participants, and the power of each node is the same, and there is no need to distinguish the resources owned by the node. The nodes participating in the consensus are divided into normal nodes (honest nodes) and abnormal nodes (malicious nodes) according to whether they are strictly executed in accordance with the predetermined protocol. The messages transmitted between nodes are proposal messages, voting messages or certificate messages. This embodiment satisfies the adversary model of n=3f+1, that is, n≥3f+1 can guarantee the security and activity of the protocol, where: f represents the number of abnormal nodes. The proportion of abnormal nodes in the system to the nodes of the entire network cannot exceed 1 / 3, and the remaining nodes are correct nodes. The abnormal nodes completely deviate from the normal protocol execution process and take arbitrary actions within their capabilities, that is, Byzantine nodes.

[0027] The blockchain system described separates the block generation and voting processes in a parallel architecture. The subsequent block can be proposed directly after receiving the block without waiting for the previous block to complete the voting. The construction of the block and the voting are carried out in parallel, that is, the next block can be generated and the corresponding voting process can be executed while voting on the block.

[0028] The proposal message contains a block. If the block is a fast block, no other messages are required. If the block is a stable block, the corresponding proposal message also needs to carry highQC and ViewChangeQC. This message is used to propose a block to reach a consensus.

[0029] The voting messages include PrepareVote (voting on blocks), PreCommitVote (voting on PrepareQC), and CommitVote (voting on PreCommitQC) according to the different stages.

[0030] The certificate messages include a preparation certificate PrepareQC (a certificate generated by the aggregated quorum PrepareVote), a pre-commit certificate PreCommitQC (a certificate generated by the aggregated quorum PreCommitVote), and a commit certificate CommitQC (a certificate generated by the aggregated quorum CommitVote).

[0031] like Figure 3As shown, each node records and updates the protocol execution status, including: view number (ViewNumber), the locked certificate (lockedQC) of the replica, that is, the highest pre-commit certificate PreCommitQC that has voted for the commit vote (Commit-Vote), the switch certificate (TransQC) of the replica, that is, the highest prepare certificate PrepareQC that has voted for the pre-commit vote (PreCommit-Vote), the highest means that the height of the corresponding block is the highest, that is, the ViewNumber is the largest.

[0032] like Figure 8 As shown, a blockchain consensus method based on speculative blocks based on the above blockchain system includes:

[0033] Step 1, initialization phase: All nodes complete user registration before the protocol is executed. Each legitimate user will have a pair of key shares for signing and verification of the threshold signature system. Each node participates in the generation process of the blockchain. The nodes are divided into master nodes and replica nodes. The master node generates new blocks and broadcasts them to the replica nodes. The replica nodes verify the blocks and vote.

[0034] Step 2, consensus phase: Figure 2 As shown in the figure, all participants in the blockchain system take turns to be the master node to produce blocks. After receiving the proposal, the new master node immediately creates a new block and broadcasts it to the network. The replica nodes verify it and vote in four stages and three rounds. When the master node obtains the votes of the preset proportion of nodes for a block, it generates the quorum certificate (QC) corresponding to the block. After multiple rounds of voting, the block is confirmed to be added to the blockchain. Specifically, after the master node of view v proposes the block b it constructed, the master node of the next view, that is, v+1, can construct its own block b' and broadcast it after receiving block b, without waiting for the node to vote for block b; when the remaining nodes receive block b or b', they will determine whether the block meets the voting conditions. If so, they will send a voting message to their corresponding master node. After receiving the votes of the quorum, the master node aggregates and generates and broadcasts the quorum certificate (QC), and successfully confirms the block after multiple rounds of voting.

[0035] In the optimistic case where the network is synchronized and there are no Byzantine nodes, the time interval between block generation is only twice the network delay, and multiple rounds of voting proceed in parallel as the blockchain continues to grow.

[0036] The quorum certificate (QC) adopts a (t,n) threshold signature system, that is, when the master node collects t valid votes from different nodes on any message, it aggregates and generates a corresponding QC to indicate that t members out of n members agree with and vote for the message.

[0037] When an exception occurs and a rollback occurs, the replica node sends its locally stored TransQC (each node stores and maintains the value, which is mentioned in Section 31) and the shared signature for ViewNumber to the master node. After the master node collects at least nf valid view switching messages from different nodes, it selects the highest switching certificate TransQC as highQC, aggregates some signatures to generate a threshold signature ViewChangeQC for ViewNumber, thereby proving that most nodes agree to the view switch and recognize the node as the master node to produce blocks.

[0038] like Figure 4 As shown, the four-stage three-round voting in step 2 includes:

[0039] Preparation phase (Prepare): The corresponding master node expands the blockchain according to the block generation strategy, and puts the block into the proposal as a preparation message for broadcasting. After receiving the message, other replica nodes determine whether to accept the proposal according to the voting rules. If the block is accepted, the replica node sends a preparation vote with its partial signature to the corresponding leader, and enters the next view, which is proposed by the new master node. In this phase, there are different voting rules for different blocks. For fast blocks, the voting rules are stricter, requiring that the parent block of the block is indeed the block of the previous view and does not conflict with TransQC. The voting rules for stable blocks are that the block generation node of the block is the node specified in ViewChangeQC, and the block is extended from the corresponding block of lockedQC or the highQC view height it carries is greater than the current lockedQC. When the correct stable block is received, the node will abandon the block with a view number higher than the current stable block, that is, abandon the fast block generated by speculation before.

[0040] Pre-commit phase (PreCommit): When the master node receives (nf) prepare votes, it aggregates and generates PrepareQC and broadcasts it. The replica responds to the leader through the pre-commit vote. When a higher PrepareQC is received, the replica also needs to update the local TransQC.

[0041] Commit phase: Similar to the PreCommit phase, respond to the leader by submitting a vote, and set lockedQC to the new PreCommitQC when a higher PreCommitQC is received.

[0042] Decide phase: When the leader receives (nf) commit votes, it aggregates and generates CommitQC and broadcasts it. CommitQC indicates that the corresponding block has been finally confirmed, and each node will send a reply to the client and execute the corresponding command.

[0043] like Figure 5 As shown, the block generation operation includes: when the protocol is executed normally, the master node gives up waiting for the voting result QC of the predecessor block, and directly generates a new block based on the block of the previous view as the parent block, that is, a fast block, and the corresponding proposal message does not need to carry proof information; in abnormal circumstances, the master node selects TransQC with the highest view as highQC, and generates a new block with the block corresponding to highQC as the parent block, that is, a stable block. The corresponding proposal message needs to carry highQC and ViewChangeQC to prove its security. When a message is approved according to the voting rules, the replica node uses its private key to sign and generate the corresponding voting message.

[0044] When the protocol is executed normally, the present invention adopts a more aggressive speculative block generation strategy, namely, a fast block operation. The master node uses the block of the previous view as the parent block to generate a new block. The block generated in this case is called a fast block, and the corresponding proposal does not need to carry proof information. For fast blocks, the judgment of the voting rules is more stringent, requiring that the parent block of the block is indeed the block of the previous view and does not conflict with TransQC. However, due to factors such as network problems, there may be situations such as node downtime, which may lead to forks, etc., so it is still necessary to consider ensuring the security and activity of the system under the Byzantine fault tolerance model, so a fallback mechanism is introduced in the present invention. When a speculative block is denied due to network anomalies and other reasons, the system can quickly fall back to the last stable state and re-initiate consensus to ensure that the system will not cause forks or data inconsistencies due to the continuation of erroneous blocks. Figure 6 As shown, specifically including:

[0045] Step i: When a node waits for a message in a certain view for a timeout period, the system triggers the fallback mechanism. Each node sends a View-Change message to the master node it recognizes. Because it can be considered that the block generated by TransQC has been recognized by most nodes and does not need to be overturned, it is chosen to switch to the next view of the corresponding view of TransQC. When the network abnormality triggers the fallback mechanism, the corresponding block generation strategy and voting strategy will also be adjusted accordingly.

[0046] Step ii, the master node first collects View-Change messages from (nf) replica nodes, which carry the replica's TransQC and a partial signature of the switch view number; then the master node selects the TransQC with the highest view as highQC, aggregates the partial signatures of the switch view number to generate the certificate ViewChangeQC, and generates a new block with the block corresponding to highQC as the parent block. Because highQC is the highest, no block with a higher view can be successfully submitted, so it is safe to generate a new block based on the block corresponding to highQC; the ViewChangeQC indicates that (nf) replicas recognize it as the master node after View-Change to generate blocks.

[0047] Step iii, the leader node generates a stable block based on highQC, generates a proposal message for the block and broadcasts it. The corresponding proposal carries highQC and ViewChangeQC to prove its security. After the view switch occurs, the node needs to wait for a stable block. The voting rule for a stable block is that the block-producing node of the block is the node specified in ViewChangeQC, and the block is extended from the corresponding block of lockedQC or the highQC view height it carries is greater than the current lockedQC.

[0048] Step iv: After receiving the correct stable block, the replica node abandons the block higher than the ViewNumber, that is, abandons the fast block previously generated by speculative means, thereby achieving the purpose of fallback.

[0049] After specific practical experiments, using Amazon Cloud and configuring a four-node blockchain network located in different locations around the world, with a block size of 100 and a load of 0, the maximum throughput of the HotStuff consensus method was 900ops / sec, while the maximum throughput of this method was 140,000ops / sec; with a block size of 200 and a load of 600, the maximum throughput of the HotStuff consensus method was 1,800ops / sec, while the maximum throughput of this method was 190,000ops / sec.

[0050] Compared with the existing technology, this method adopts a parallel voting architecture to directly generate new blocks based on the blocks without waiting for the voting results, which can eliminate this waiting time. The master node can generate blocks more quickly, thereby reducing consensus delays and significantly improving the system throughput.

[0051] The above-mentioned specific implementation can be partially adjusted in different ways by those skilled in the art without departing from the principle and purpose of the present invention. The protection scope of the present invention shall be based on the claims and shall not be limited by the above-mentioned specific implementation. Each implementation scheme within its scope shall be subject to the constraints of the present invention.

Claims

1. A blockchain consensus method based on speculative block generation, characterized in that: include: Step 1: Initialize the blockchain system. Each node needs to be registered during initialization, generate a public and private key pair for threshold signature, and establish an initial connection between all nodes. Step 2: In the process of reaching a consensus in the system, each honest node in the blockchain system participates in the consensus according to the speculative block generation and parallel voting mechanism, independently performs block generation, voting, verification or rollback operations, and reaches consensus between nodes through multiple rounds of message propagation. Specifically, the master node proposes a new block according to the current state, and broadcasts the new block as a proposal message to all replica nodes. After receiving the proposal message, the replica nodes verify the legitimacy according to the voting rules and vote. The corresponding master node collects and aggregates votes, generates and broadcasts the quorum certificate (QC), and then collects votes again. After multiple rounds of voting, a consensus is reached on the new block. After receiving the proposal message, the next master node directly generates the next new block without waiting for the voting result; The message is: Block, Vote or Quorum Certificate (QC); The block generation operation includes: fast block generation under normal circumstances and stable block generation under abnormal circumstances; The voting operation is a four-stage three-round voting mode, including a preparation stage (Prepare), a pre-commit stage (PreCommit), a commit stage (Commit) and a decision stage (Decide).

2. The blockchain consensus method based on speculative block generation according to claim 1 is characterized in that: In the consensus process, the block generation operation and the voting operation are carried out in parallel and each node in the blockchain system maintains state variables such as view number (ViewNumber), switch QC (TransQC) and lock QC (lockedQC), so as to track the current state of the system and important data during the execution process.

3. The blockchain consensus method based on speculative block generation according to claim 1 or 2 is characterized in that: In the consensus process, when the blockchain system detects an abnormal situation, a rollback mechanism is triggered, and a consensus is reached again by means of stable blocks, which specifically includes: each node sends a view switching message (View-Change message) to the master node it recognizes, and the master node needs to first collect View-Change messages from (nf) replica nodes, which will carry the switching certificate (TransQC) of the replica and a partial signature for the switching view number; the master node selects the switching certificate (TransQC) of the highest view as the highest certificate (highQC), aggregates partial signatures to generate a view switching certificate (ViewChangeQC), generates a new block with highQC as the parent block and broadcasts it; after receiving the new block, the replica node abandons the block higher than the ViewNumber, that is, abandons the fast block previously generated by speculative means to achieve the purpose of rollback.

4. The blockchain consensus method based on speculative block generation according to claim 1 or 2 is characterized in that: The block generation operation includes: when the protocol is executed normally, the master node gives up waiting for the voting result QC of the predecessor block, and directly generates a new block based on the block of the previous view as the parent block, that is, a fast block, and the corresponding proposal message does not need to carry proof information; in abnormal circumstances, the master node selects TransQC with the highest view as highQC, and generates a new block with the block corresponding to highQC as the parent block, that is, a stable block. The corresponding proposal message needs to carry highQC and ViewChangeQC to prove its security. When a message is approved according to the voting rules, the replica node uses its private key to sign and generate the corresponding voting message.

5. The blockchain consensus method based on speculative block generation according to claim 1 is characterized in that: The four-stage three-round voting includes: Preparation phase (Prepare): The corresponding master node expands the blockchain according to the block generation strategy, and puts the block into the proposal as a preparation message for broadcasting. After receiving the message, other replica nodes determine whether to accept the proposal according to the voting rules. If the block is accepted, the replica node sends a preparation vote with its partial signature to the corresponding leader and enters the next view, which is proposed by the new master node. In this phase, there are different voting rules for different blocks. For fast blocks, the voting rules are stricter, requiring that the parent block of the block is indeed the block of the previous view and does not conflict with TransQC. The voting rule for stable blocks is that the block generation node of the block is the node specified in ViewChangeQC, and the block is extended from the corresponding block of lockedQC or the highQC view height it carries is greater than the current lockedQC. After receiving the correct stable block, the node will abandon the block with a view number higher than the current stable block, that is, abandon the fast block generated by speculation before; Pre-commit phase (PreCommit): When the master node receives (nf) prepare votes, it aggregates and generates PrepareQC and broadcasts it. The replica responds to the leader through the pre-commit vote. When receiving a higher PrepareQC, the replica also needs to update the local TransQC. Commit phase: Similar to the PreCommit phase, respond to the leader by submitting a vote, and set lockedQC to the new PreCommitQC when a higher PreCommitQC is received; Decision phase (Decide): When the leader receives (nf) commit votes, it aggregates and generates CommitQC and broadcasts it. CommitQC indicates that the corresponding block is finally confirmed. Each node will send a reply to the client and execute the corresponding command.

6. The blockchain consensus method based on speculative block generation according to claim 1 is characterized in that: The fallback mechanism specifically includes: Step i: When a node waits for a message in a certain view for a timeout period, the system triggers the fallback mechanism. Each node sends a View-Change message to the master node it recognizes. Because it can be considered that the block generated by TransQC has been recognized by most nodes and does not need to be overturned, it is chosen to switch to the next view of the corresponding view of TransQC. When the network abnormality triggers the fallback mechanism, the corresponding block generation strategy and voting strategy will also be adjusted accordingly; Step ii, the master node first collects View-Change messages from (nf) replica nodes, which carry the replica's TransQC and a partial signature of the view switching number; then the master node selects the TransQC with the highest view as highQC, aggregates the partial signatures of the view switching number to generate the certificate ViewChangeQC, and generates a new block with the block corresponding to highQC as the parent block. Because highQC is the highest, no block with a higher view has been successfully submitted, so it is safe to generate a new block based on the block corresponding to highQC; the ViewChangeQC indicates that (nf) replicas recognize it as the master node after View-Change to generate blocks; Step iii, the leader node generates a stable block based on highQC, generates a proposal message for the block and broadcasts it. The corresponding proposal carries highQC and ViewChangeQC to prove its security. After the view switch occurs, the node needs to wait for a stable block. The voting rule for a stable block is that the block-producing node of the block is the node specified in ViewChangeQC, and the block is extended from the corresponding block of lockedQC or the highQC view height it carries is greater than the current lockedQC. Step iv: After receiving the correct stable block, the replica node abandons the block higher than the ViewNumber, that is, abandons the fast block previously generated by speculative means, thereby achieving the purpose of fallback.

7. A blockchain consensus system based on speculative block generation that implements any of the methods described in claims 1-6, comprising: The block generation unit, the block verification unit, the vote generation unit, the vote collection unit and the certificate verification unit, wherein: the block generation unit determines whether it is a master node according to the number of views, and if it is a master node, it generates a new block according to the parent block; the block verification unit determines the legitimacy of the block according to the received block, thereby deciding whether to vote; the certificate verification unit verifies the legitimacy of the certificate according to the received certificate and determines whether to vote; the vote generation unit partially signs the message according to its own key to obtain the voting message; the vote collection unit aggregates the collected votes to obtain the quorum certificate.

Images