A Byzantine fault-tolerant consensus method with high-speed response to clients

Abstract

The present invention discloses a Byzantine fault-tolerant consensus method for a high-speed response client, comprising: after the master node receives the request sent by the client, it assigns a sequence number to it and sends a Pre-Prepare message to all replica nodes; the replica node optimistically executes the request and returns a Prepare message to the master node and the client; the master node aggregates it into PrepareQC and broadcasts it to all replica nodes. When the client judges that the optimistic execution results of all nodes are consistent, it is considered that the request is recognized by the blockchain cluster consensus; the replica node verifies that PrepareQC is legal and saves it, and sends a Commit message to the master node and the client; the master node aggregates it into CommitQC and broadcasts it again, and the client judges again whether the request is recognized by consensus; the replica node verifies CommitQC, and if it is legal, saves and submits the message to the client; if it is illegal, enters the view change stage. The present invention adopts the method of judging the optimistic execution result of the replica by the client, which effectively improves the speed at which the blockchain system responds to client requests.

Description

Technical Field

[0001] The present invention belongs to the fields of blockchain technology and Byzantine fault-tolerant consensus, and in particular relates to a Byzantine fault-tolerant consensus method with high-speed response to clients. Background Art

[0002] Essentially, blockchain technology enables different replica nodes to reach consensus on a public ledger in a distributed network environment without a trusted third party. Consensus algorithms are a core component of blockchain technology, and with the continuous development of blockchain technology, a variety of consensus algorithms have emerged within the industry.

[0003] In order to tolerate Byzantine errors, traditional blockchain consensus algorithms are designed with a multi-round consensus message interaction process. The client can only receive a response from the blockchain cluster if and only if the request is submitted by consensus by the majority of replica nodes in the blockchain cluster. However, if there are no errors in the system and the network does not timeout, the traditional consensus algorithm still needs to run multiple rounds of consensus before responding to the client, resulting in a slow system response. Summary of the Invention

[0004] In response to the problem that the existing consensus algorithm has insufficient response speed to the client when no errors occur in the blockchain cluster, the present invention provides a Byzantine fault-tolerant consensus method that responds to the client at high speed. This method uses the client to judge the optimistic execution results of the replica, thereby improving the response speed to the client.

[0005] The object of the present invention is achieved through the following technical solutions:

[0006] A Byzantine fault-tolerant consensus method with high-speed response to clients, specifically comprising the following steps:

[0007] (1) Establish secure P2P communication connections between all replica nodes of the blockchain cluster;

[0008] (2) Take a replica node as the master node, and the client sends a request to the master node;

[0009] (3) After receiving the request from the client, the master node assigns a sequence number to the transaction and broadcasts a Pre-Prepare message to all replica nodes in the blockchain cluster;

[0010] (4) After receiving the Pre-Prepare message from the master node, the replica node optimistically executes the transaction, that is, the replica node receives the sorted request and directly executes it; the replica node sends a Prepare message to the master node and the client;

[0011] (5) After receiving 2f+1 Prepare messages, the master node aggregates the 2f+1 Prepare messages into PrepareQC and broadcasts the PrepareQC message to all replica nodes, where f is the number of replica nodes with Byzantine errors. If the client collects 3f+1 consistent Prepare messages before the timer expires, it is considered that the transaction is optimistically executed by all replica nodes and the transaction will definitely be agreed upon in the future.

[0012] (6) After receiving the PrepareQC message from the master node, the replica node verifies whether the PrepareQC is valid. If it is valid, the replica node saves the PrepareQC and sends a Commit message to the master node and the client. If it is invalid, the replica node uses the received invalid message as evidence of the view change, broadcasts a view change message, and enters the view change phase.

[0013] (7) After receiving 2f+1 Commit messages, the master node aggregates the 2f+1 Commit messages into a CommitQC and broadcasts the CommitQC message to all replica nodes. At the same time, if the client collects 2f+1 consistent Commit messages before the timer expires, it is considered that the transaction is optimistically executed by all replica nodes, and the transaction will definitely be agreed upon in the future and proceed to the next step. If the client fails to collect 2f+1 consistent Commit messages from replicas before the timer expires, the client will retransmit the transaction, that is, repeat steps (2) to (7).

[0014] (8) After receiving the CommitQC message from the master node, the replica node verifies whether the CommitQC is legal. If it is legal, the replica node saves the CommitQC, formally submits the transaction, and pushes the commit message to the client through the message queue. If it is illegal, the replica node uses the illegal message as evidence of the view change, broadcasts the view change message, and enters the view change phase.

[0015] Furthermore, if the master node is a Byzantine node, the replica node and the client use the set timer to determine whether a timeout event occurs, perform a view change, and switch to the next master node in a rotation manner; during the view change process, each replica node sends the locally saved PrepareQC and CommitQC to the new master node, and the new master node re-consensuses the requests that should have been completed in the previous view based on the collected QC information, with O(n 2 )’s message communication complexity completes the view change process and ensures the consistency of the blockchain system.

[0016] Furthermore, a pipeline parallel execution mode is adopted. The master node will sign the Pre-Prepare message with sequence number n, the PrepareQC message with sequence number n-1, and the CommitQC message with sequence number n-2 and send them to the replica node, thereby converting the process of serial execution of different rounds into multiple rounds of parallel execution, thereby improving the throughput of the blockchain system.

[0017] Furthermore, the blockchain cluster adopts an efficient recovery strategy for lagging replica nodes. For replica nodes that lag too far behind, the ledger status is first restored. Through snapshot recovery and block recovery, the lagging replica nodes can be restored to the checkpoint height consistent with other replica nodes. Then, the consensus status is restored to obtain the legitimate PrepareQC and CommitQC held by other replica nodes. Subsequently, the replica node can participate in the latest round of consensus process and respond to the client at high speed.

[0018] Furthermore, a replica node blacklist management mechanism is adopted to effectively reduce the impact of Byzantine nodes on the activity of the blockchain system. When a replica node holds evidence of Byzantine behavior of the master node, the master node is recorded in the blacklist. The blacklist records the numbers of no more than f replica nodes. When a view change occurs, if the new master node is not on the blacklist, a normal consensus switch is performed. If the new master node number is on the blacklist, the view round is skipped, the view number is increased by 1 again, and then the judgment is made.

[0019] Furthermore, in step (5), if the client collects 3f+1 consistent Prepare messages before the timer expires, the client determines that the transaction will definitely be able to reach consensus in the future, and there is no need to judge the messages collected in step (7). The judgment ends in advance, and the client performs operations after completing the consensus, but the transaction still continues to complete the subsequent steps of the consensus protocol; if the client fails to collect 3f+1 consistent copies of Prepare messages before the timer expires, the client needs to judge whether the transaction can reach consensus according to the collection results of step (7);

[0020] In step (7), if the transaction is judged to be able to reach consensus in the future, the transaction ends here and the client performs operations after reaching consensus, but the transaction still continues to complete the subsequent steps of the consensus protocol.

[0021] The beneficial effects of the present invention are as follows:

[0022] The present invention solves the problem of insufficient response speed of traditional consensus algorithms to clients when no errors occur in the blockchain cluster. The blockchain replica node optimistically executes the sorting message of the master node and quickly responds to the client with the optimistic execution result, effectively improving the speed at which the blockchain system responds to client requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is an algorithm flow chart of the Byzantine fault-tolerant consensus method of the present invention that responds to clients at high speed.

[0024] Figure 2 This is a flow chart of the pipelined parallel execution of the Byzantine fault-tolerant consensus method of the present invention that responds to clients at high speed. DETAILED DESCRIPTION

[0025] The present invention will be described in detail below based on the accompanying drawings and preferred embodiments. The purpose and effects of the present invention will become more apparent. The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.

[0026] like Figure 1 As shown in the figure, in the Byzantine fault-tolerant consensus method that responds to clients at high speed, the client initiates the request and only needs three rounds of message communication at the fastest for the request to be considered to have been agreed upon. After the replica node in the blockchain cluster receives the client request from the master node, the replica node optimistically executes the request and returns the result to the client. Unlike the existing Byzantine fault-tolerant consensus protocol, there is no need to wait for all consensus rounds to be completed before returning the result. When the client determines that the optimistic execution results of all replica nodes are consistent, it can be considered that the request has finally been agreed upon by the blockchain cluster. The method specifically includes the following steps:

[0027] (1) Establish secure P2P communication connections between all replica nodes of the blockchain cluster.

[0028] (2) Take a replica node as the master node, and the client sends a request to the master node.

[0029] (3) After receiving the request from the client, the master node of the blockchain cluster assigns a serial number to the transaction and broadcasts a Pre-Prepare message to all replica nodes in the blockchain cluster.

[0030] (4) After receiving the Pre-Prepare message from the master node, the replica node in the blockchain cluster optimistically executes the transaction. That is, the replica node receives the sorted request and directly executes it. The replica node sends a Prepare message to the master node and client of the blockchain cluster. If a replica node is a Byzantine node, it only receives the Pre-Prepare message and does not reply to it.

[0031] (5) After receiving 2f+1 Prepare messages, the master node in the blockchain cluster aggregates the 2f+1 Prepare messages into PrepareQC and broadcasts the PrepareQC message to all replica nodes, where f is the number of replica nodes that have Byzantine errors. At the same time, if there are no errors in the blockchain cluster and the network conditions are good, the client does not need to wait for multiple rounds of consensus interactions. When the client collects 3f+1 consistent replica Prepare messages before the timer expires, it can be considered that the transaction is optimistically executed by all replica nodes and the transaction will definitely be agreed upon in the future. The client does not need to judge the collected messages in the following step (7) and can end the judgment in advance. The client can perform other operations after the consensus is completed, but the transaction will continue to complete the subsequent steps of the consensus protocol. If the client fails to collect 3f+1 consistent replica Prepare messages before the timer expires, the client needs to judge whether the transaction can reach consensus according to the collection results of step (7). For application scenarios such as data storage, this consensus mechanism can have a high-speed response capability to meet the timeliness requirements.

[0032] (6) After receiving the PrepareQC message from the master node, the replica node in the blockchain cluster verifies whether the PrepareQC is legal. If it is legal, the replica node saves the PrepareQC and sends a Commit message to the master node and the client. If it is illegal, the replica node uses the illegal message as evidence of the view change, broadcasts the view change message, and enters the view change phase.

[0033] (7) After the master node in the blockchain cluster receives 2f+1 Commit messages, it aggregates the 2f+1 Commit messages into a CommitQC and broadcasts the CommitQC message to all replica nodes. At the same time, if the client collects 2f+1 consistent Commit messages from replica nodes before the timer expires, it can be considered that the transaction is optimistically executed by all replica nodes in the blockchain cluster, and the transaction will definitely be agreed upon in the future. The transaction ends here, and the client can perform other operations after the consensus is completed, but the transaction still continues to complete the subsequent steps of the consensus protocol, that is, enter step (8). If the client fails to collect 2f+1 consistent Commit messages from replica nodes before the timer expires, the client will retransmit the transaction, that is, repeat steps (2) to (7).

[0034] (8) After receiving the CommitQC message from the master node, the replica node in the blockchain cluster verifies whether the CommitQC is legal. If it is legal, the replica node saves the CommitQC, formally commits the transaction, and pushes the commit message to the client through the message queue. If it is illegal, the replica node uses the illegal message as evidence of the view change, broadcasts the view change message, and enters the view change phase. The client can know whether the transaction is formally submitted based on the push status, meeting the needs of real-time computing scenarios.

[0035] If the master node of the blockchain cluster is a Byzantine node, the replica nodes and clients can use the set timer to determine whether a timeout event has occurred. If a timeout event occurs, the view is changed and the next master node is switched in a rotation manner. During the view change process, each replica node sends the locally saved PrepareQC and CommitQC to the new master node. The new master node re-consensuses on the requests that should have been completed in the previous view based on the collected QC information, using O(n 2 ) to complete the view change process and ensure the consistency and security of the blockchain system.

[0036] like Figure 2 As shown, the present invention adopts a pipelined parallel execution approach. Assuming a client sends three requests with sequence numbers n-2, n-1, and n, the blockchain cluster's master node will sign the Pre-Prepare message with sequence number n, the PrepareQC message with sequence number n-1, and the CommitQC message with sequence number n-2, and send them to the replica nodes. This converts the serial execution of different rounds into multiple parallel rounds, improving the throughput of the blockchain system.

[0037] Because the premise of the three-stage high-speed response is that the client collects all replies, if a replica node goes down or the network times out, the client will not be able to collect all replies. The present invention designs an efficient recovery strategy for lagging nodes. For nodes that lag behind too much, the ledger status can be restored first. Through snapshot recovery and block recovery, the lagging node can be restored to the checkpoint height consistent with other nodes, and then the consensus status can be restored to obtain the legal PrepareQC and CommitQC held by other nodes. Subsequently, the node can participate in the latest round of consensus process and respond to the client at high speed, ensuring the availability and robustness of the system.

[0038] A blacklist management mechanism effectively reduces the impact of Byzantine nodes on the activity of the blockchain system. When a replica node holds evidence of malicious behavior by a master node, it adds the master node to the blacklist. The blacklist contains no more than f node numbers, where f is the number of replica nodes experiencing Byzantine errors. When a view change occurs, if the new master node is not on the blacklist, a normal consensus transition occurs. If the new master node number is on the blacklist, the view round is skipped, the view number is incremented by 1, and the next view change is repeated. This method effectively reduces the probability that the new master node is a Byzantine node during a view change, thereby improving the activity of the blockchain system.

[0039] Those skilled in the art will understand that the foregoing descriptions are merely preferred embodiments of the invention and are not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art will still be able to modify the technical solutions described in the foregoing examples or substitute equivalents for some of the technical features therein. Any modifications, equivalent substitutions, etc. made within the spirit and principles of the invention shall be included within the scope of protection of the invention.

Claims

1. A Byzantine fault-tolerant consensus method with high-speed response to clients, characterized in that: The specific steps include: (1) Establish secure P2P communication connections between all replica nodes of the blockchain cluster; (2) Take a replica node as the master node, and the client sends a request to the master node; (3) After receiving the request from the client, the master node assigns a sequence number to the transaction and broadcasts a Pre-Prepare message to all replica nodes in the blockchain cluster; (4) After receiving the Pre-Prepare message from the master node, the replica node optimistically executes the transaction, that is, the replica node receives the sorted request and directly executes it; the replica node sends a Prepare message to the master node and the client; (5) After receiving 2f+1 Prepare messages, the master node aggregates the 2f+1 Prepare messages into PrepareQC and broadcasts the PrepareQC message to all replica nodes, where f is the number of replica nodes with Byzantine errors. If the client collects 3f+1 consistent Prepare messages before the timer expires, it is considered that the transaction is optimistically executed by all replica nodes and the transaction will definitely be agreed upon in the future. (6) After receiving the PrepareQC message from the master node, the replica node verifies whether the PrepareQC is legal. If it is legal, the replica node saves the PrepareQC and sends a Commit message to the master node and the client. If it is illegal, the replica node will use the received illegal message as evidence of view change, broadcast the view change message, and enter the view change phase; (7) After receiving 2f+1 Commit messages, the master node aggregates the 2f+1 Commit messages into a CommitQC and broadcasts the CommitQC message to all replica nodes. At the same time, if the client collects 2f+1 consistent Commit messages before the timer expires, it is considered that the transaction is optimistically executed by all replica nodes, and the transaction will definitely be agreed upon in the future and proceed to the next step. If the client fails to collect 2f+1 consistent Commit messages from replicas before the timer expires, the client will retransmit the transaction, that is, repeat steps (2) to (7). (8) After receiving the CommitQC message from the master node, the replica node verifies whether the CommitQC is legal. If it is legal, the replica node saves the CommitQC, formally commits the transaction, and pushes the commit message to the client through the message queue; If it is illegal, the replica node will use the received illegal message as evidence of view change, broadcast the view change message, and enter the view change phase.

2. The Byzantine fault-tolerant consensus method for high-speed response clients according to claim 1 is characterized in that: If the master node is a Byzantine node, the replica node and the client use the set timer to determine whether a timeout event has occurred, change the view, and switch to the next master node in a rotation manner; During the view change process, each replica node sends the locally saved PrepareQC and CommitQC to the new master node. The new master node re-consensuses the requests that should have been completed in the previous view based on the collected QC information, and completes the request in O(n 2 )’s message communication complexity completes the view change process and ensures the consistency of the blockchain system.

3. The Byzantine fault-tolerant consensus method for high-speed response clients according to claim 1 is characterized in that: Using a pipeline parallel execution mode, the master node will sign the Pre-Prepare message with sequence number n, the PrepareQC message with sequence number n-1, and the CommitQC message with sequence number n-2 and send them to the replica node, thereby transforming the process of serial execution of different rounds into multiple rounds of parallel execution, thereby improving the throughput of the blockchain system.

4. The Byzantine fault-tolerant consensus method for high-speed response clients according to claim 1 is characterized in that: The blockchain cluster adopts an efficient recovery strategy for lagging replica nodes. For replica nodes that lag too far behind, the ledger status is restored first. Through snapshot recovery and block recovery, the lagging replica nodes can be restored to the checkpoint height consistent with other replica nodes. Then, the consensus status is restored and the legal PrepareQC and CommitQC held by other replica nodes are obtained. Subsequently, the replica node can participate in the latest round of consensus process and respond to the client at high speed.

5. The Byzantine fault-tolerant consensus method for high-speed response clients according to claim 1 is characterized in that: A replica node blacklist management mechanism is adopted to effectively reduce the impact of Byzantine nodes on the activity of the blockchain system. When a replica node holds evidence of Byzantine behavior in the master node, the master node will be recorded in the blacklist. The blacklist records the numbers of no more than f replica nodes. When a view change occurs, if the new master node is not on the blacklist, a normal consensus switch is performed. If the new master node number is on the blacklist, the view round is skipped, the view number is increased by 1 again, and then the judgment is made.

6. The Byzantine fault-tolerant consensus method for high-speed response clients according to claim 1, characterized in that: In step (5), if the client collects 3f+1 consistent Prepare messages before the timer expires, the client determines that the transaction will definitely be able to reach consensus in the future, and there is no need to judge the messages collected in step (7). The judgment ends in advance, and the client performs the operations after completing the consensus, but the transaction continues to complete the subsequent steps of the consensus protocol; if the client fails to collect 3f+1 consistent copies of Prepare messages before the timer expires, the client needs to judge whether the transaction can reach consensus according to the collection results of step (7); In step (7), if the transaction is judged to be able to reach consensus in the future, the transaction ends here and the client performs operations after reaching consensus, but the transaction still continues to complete the subsequent steps of the consensus protocol.

Images