Blockchain consensus method based on speculative block generation

Abstract

A blockchain consensus method based on speculative block generation is used to initialize the blockchain system. Each node is required to register during initialization and generate a public-private key pair for threshold signatures. After all nodes establish an initial connection, during the process of system consensus, each honest node in the blockchain system participates in the consensus according to the speculative block generation and parallel voting mechanism, independently performing block generation, voting, verification, or rollback operations. Consensus is reached between nodes through multiple rounds of message propagation. The present invention decomposes the voting and block generation processes, independently votes on each block, and uses a parallel block generation and voting mechanism to achieve consensus. During normal operation, a fast block generation method using speculative block generation is used to avoid the time delay of waiting for the vote of the previous block. This overcomes the performance issues caused by waiting for voting results in traditional Byzantine consensus blockchain systems, allowing the system to generate new blocks without waiting for 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.

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] Existing blockchain Byzantine Fault Tolerance (BFT) consensus technology widely adopts the "proposal-vote" 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 the next block can be proposed. The system's throughput is limited by the two rounds of communication delay. Summary of the Invention

[0003] In response to the shortcomings of the existing technology that have more stringent restrictions on malicious nodes in the network, resulting in limited application scenarios, the present invention proposes a blockchain consensus method based on speculative block generation. By disassembling the voting and block generation processes, each block is voted on independently and a mechanism of parallel block generation and voting is adopted to complete consensus. During normal operation, a fast block generation method of speculative block generation is adopted to avoid the time delay of waiting for the vote of the previous block, overcome the performance problems caused by waiting for the voting results in the traditional Byzantine consensus blockchain system, and enable the system to 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 register 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 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 based on 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, 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 results.

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

[0009] In the consensus process, block generation and voting operations 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), thereby tracking 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, 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 current number of views by a large margin. The difference in the number of views is usually set to 10.

[0014] The fallback mechanism includes: each node sends a view switch 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 replica's switch certificate (TransQC) and a partial signature for the switch view number (the partial signature here is not a certificate; the certificate is generated by aggregating the partial signatures); the master node selects the highest view switch certificate (TransQC) as the highest certificate (highQC), aggregates the partial signatures to generate a view switch 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 by speculative means to achieve the fallback purpose.

[0015] The present invention relates to a system for implementing the above-mentioned 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 based on the number of views, and if it is a master node, generates a new block based on the parent block; the block verification unit performs block legitimacy judgment based on the received block, thereby deciding whether to vote; the certificate verification unit verifies the legitimacy of the certificate based on the received certificate and determines whether to vote; the vote generation unit partially signs the message based on its own key to obtain a voting message; and the vote collection unit aggregates the collected votes to obtain a quorum certificate.

[0016] Technical Effects

[0017] This 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 block. It also employs a parallel voting architecture, separating block generation and voting into parallel executions. This avoids the performance issues often associated with waiting for voting results in traditional blockchain systems. A fallback mechanism ensures that in the event of anomalies, the system can fall back to the most recent stable state and re-initiate consensus to ensure system security and activity. Compared to existing technologies, this invention significantly improves system throughput and reduces consensus latency. Through flexible block generation and voting strategies, it enables the blockchain system to adapt to varying network conditions. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 Schematic diagram of the embodiment effect;

[0019] Figure 2 This is the main flow chart of the present invention;

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

[0021] Figure 4 This is a schematic diagram of the four-stage model of the present invention;

[0022] Figure 5 A flowchart for block proposal and voting;

[0023] Figure 6 This is the sequence diagram for the fallback mechanism;

[0024] Figure 7 Schematic diagram of technical solutions corresponding to different situations of blockchain system;

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

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

[0027] like Figure 9 As shown, the blockchain system is an application scenario of this embodiment, that is, a distributed system with n nodes, where all nodes constitute a set of participants. 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 strictly follow the predetermined protocol. The messages transmitted between nodes are proposal messages, voting messages or certificate messages. This embodiment meets the adversary model of n=3f+1, that is, n≥3f+1 is satisfied to ensure 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 total network nodes cannot exceed 1 / 3, and the remaining nodes are correct nodes. Abnormal nodes completely deviate from the normal protocol execution process and take arbitrary actions within their capabilities, that is, Byzantine nodes.

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

[0029] 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 consensus.

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

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

[0032] 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), and 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 indicates that the corresponding block has the highest height, that is, the largest ViewNumber.

[0033] like Figure 8 As shown in FIG, a blockchain consensus method based on speculative block generation based on the above blockchain system includes:

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

[0035] Step 2, consensus stage: Figure 2 As shown, all participants in a blockchain system take turns as master nodes to produce blocks. Upon receiving a proposal, a new master node immediately creates a new block and broadcasts it to the network. Replica nodes then verify it and vote on it in four phases and three rounds. Once a master node receives votes from a preset proportion of nodes for a block, it generates a quorum certificate (QC) corresponding to that block. After multiple rounds of voting, the block is confirmed to be included in the blockchain. Specifically, after the master node of view v proposes its constructed block b, the master node of the next view, view v+1, upon receiving block b, constructs its own block b' and broadcasts it without waiting for other nodes to vote for block b. Upon receiving blocks b or b', the remaining nodes determine whether the block meets the voting conditions. If so, they send a voting message to their corresponding master node. After receiving the quorum votes, the master node aggregates and broadcasts the quorum certificate (QC). After multiple rounds of voting, the block is successfully confirmed.

[0036] In the optimistic scenario of a synchronized network with no Byzantine nodes, the time between blocks is only twice the network latency, and multiple rounds of voting proceed in parallel as the blockchain continues to grow.

[0037] The quorum certificate (QC) uses 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.

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

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

[0040] Prepare phase: The corresponding master node expands the blockchain according to the block generation strategy and includes the block in the proposal as a prepare message for broadcast. After receiving the message, other replica nodes determine whether to accept the proposal based on the voting rules. If the block is accepted, the replica node sends a prepare 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, different voting rules are used for different blocks. The voting rules are more stringent for fast blocks, requiring that the parent block of the block is indeed a block in the previous view and does not conflict with TransQC. The voting rules for stable blocks require that the block's block generation node is the node specified in ViewChangeQC, and that the block is extended from the corresponding block of lockedQC or that 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 previously generated using speculative methods.

[0041] 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 pre-commit votes. When a higher PrepareQC is received, the replica also needs to update the local TransQC.

[0042] 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.

[0043] Decide phase: When the leader receives (nf) commit votes, it aggregates and generates CommitQC and broadcasts it.

[0044] 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.

[0045] 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 for the parent block based on the block of the previous view, that is, a quick 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.

[0046] Under the condition that the protocol is executed normally, the present invention adopts a more radical speculative block strategy, namely, fast block operation, in which 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 its 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 is a possibility that nodes may crash, 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 rejected 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. As Figure 6 As shown, specifically including:

[0047] Step i: When a node waits for a message in a certain view for a certain period of time (timeout), the system triggers a fallback mechanism. Each node sends a View-Change message to its recognized master node. Because it can be assumed that the block generated by TransQC has been approved by the majority of nodes and does not need to be overturned, it chooses to switch to the next view of the corresponding TransQC view. When a network anomaly triggers the fallback mechanism, the corresponding block generation strategy and voting strategy will also be adjusted accordingly.

[0048] In step ii, the master node first collects View-Change messages from (nf) replica nodes. These messages carry the replica's TransQC and a partial signature of the switch view number. The master node then selects the TransQC with the highest view as the 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. This ViewChangeQC indicates that (nf) replicas recognize it as the master node for block production after the View-Change.

[0049] Step iii: The leader node generates a stable block based on highQC, generates a proposal message for the block, and broadcasts it. The proposal carries highQC and ViewChangeQC to prove its security. After a view switch occurs, the node must wait for a stable block. The voting rules for a stable block are that the block's producer is the node specified in ViewChangeQC, the block is extended from the corresponding block of lockedQC, or the highQC view height it carries is greater than the current lockedQC.

[0050] Step iv: After receiving the correct stable block, the replica node abandons the block with a value higher than the ViewNumber, that is, abandons the fast block generated by speculative means before, thus achieving the purpose of fallback.

[0051] 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 900 ops / sec, while the maximum throughput of this method was 140,000 ops / sec; with a block size of 200 and a load of 600, the maximum throughput of the HotStuff consensus method was 1,800 ops / sec, while the maximum throughput of this method was 190,000 ops / sec.

[0052] Compared with existing technologies, this method adopts a parallel voting architecture to directly generate new blocks based on blocks without waiting for 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.

[0053] The above-mentioned specific implementation can be partially adjusted in different ways by those skilled in the art without departing from the principles and purpose of the present invention. The scope of protection of the present invention shall be based on the claims and shall not be limited by the above-mentioned specific implementation. All implementation schemes 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 must register during initialization, generate a public-private key pair for threshold signature, and establish an initial connection between all nodes. Step 2: In the process of reaching consensus, 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 based on 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, 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 results. 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, block generation and voting operations 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), thereby tracking 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 2 is characterized in that: During the consensus process, when the blockchain system detects an abnormal situation, a fallback mechanism is triggered, and a new consensus is reached using a stable block method. Specifically, each node sends a view switch 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 replica's switch certificate (TransQC) and a partial signature of the switch view number; the master node selects the switch certificate (TransQC) of the highest view as the highest certificate (highQC), aggregates the partial signatures to generate a view switch 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 ViewNumber, that is, abandons the fast block previously generated by speculative means to achieve the fallback purpose.

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 previous block, and directly generates a new block for the parent block based on the block of the previous view, that is, a quick block, and the corresponding proposal message does not need to carry proof information; in abnormal circumstances, the master node selects the 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: Prepare phase: The corresponding master node extends the blockchain according to the block generation strategy and puts the block into the proposal as a prepare message for broadcast. 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 prepare 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. 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 previously by speculation. 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. 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; Decide phase: When the leader receives (n−f) commit votes, it aggregates and generates a 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 3 is characterized in that: The fallback mechanism specifically includes: Step i: When a node waits for a message in a certain view for a period of time (timeout), the system triggers the fallback mechanism. Each node sends a View-Change message to its recognized master node. Because it can be assumed that the block generated by TransQC has been approved by the majority of nodes and does not need to be overturned, it chooses to switch to the next view of the corresponding TransQC view. 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. This message carries the replica's TransQC and a partial signature of the view switching number. The master node then 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. Therefore, it is safe to generate a new block based on the block corresponding to highQC. The aforementioned partial signature generation certificate ViewChangeQC indicates that (nf) copies recognize it as the master node after View-Change to produce 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's producer node 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 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 the method of any one of claims 1 to 6, comprising: The block generation unit, block verification unit, vote generation unit, vote collection unit and certificate verification unit, among which: the block generation unit determines whether it is a master node based on the number of views. If it is a master node, it generates a new block based on the parent block. The block verification unit determines the legitimacy of the block based on the received block to decide whether to vote. The certificate verification unit verifies the legitimacy of the certificate based on the received certificate and determines whether to vote. The vote generation unit partially signs the message based on its own key to obtain a voting message. The vote collection unit aggregates the collected votes to obtain a quorum certificate.

Images