A view switching method in a Byzantine fault-tolerant protocol

Abstract

The present invention discloses a view switching method in a Byzantine fault-tolerant protocol, comprising the following steps: when a node restarts from an offline state, it checks the storage state, finds the consensus message with the largest view number that reaches the Prepare state, and records its view number as #imgabs0#; based on the message, records the view numbers and states of other nodes; based on the message, verifies and updates its own minimum backtracking view; determines whether a node timeout has occurred, and if no timeout has occurred, returns to step 2 to enter the next round of normal consensus; if a timeout has occurred, checks the view numbers and message types of all nodes recorded in step 2, and switches views based on the number of nodes in the same view. The present invention ensures that even if multiple nodes are offline for a long time or multiple times, even if the view numbers are completely different, they can still return to the same view after a period of time and continue consensus.

Description

Technical Field

[0001] The present invention relates to the technical field of Byzantine fault-tolerant consensus protocols, and in particular to a view switching method in a Byzantine fault-tolerant protocol. Background Art

[0002] The Byzantine Fault Tolerant consensus protocol originates from the Byzantine Generals' Problem, which asks how multiple generals can reach consensus on a general conclusion when they can only communicate with each other and face the possibility of communication loss or defection. In modern computer networks, the Byzantine Fault Tolerant consensus problem is how multiple computer nodes can reach consensus on a proposal while communicating point-to-point, even if some nodes are offline or even malicious.

[0003] This problem was first raised by Lamport et al. in their paper The Byzantine General Problems, who concluded that when the number of offline or malicious nodes does not exceed 1 / 3 of the total, a communication protocol exists to guarantee the consistency of the final conclusion. However, this protocol is overly idealistic and relies on synchronization assumptions that do not exist in reality. In 1999, Miguel Castro and Barbara Liskov's paper Practical Byzantine Fault Tolerance (now commonly known as PBFT) proposed a more practical implementation of the Byzantine problem under the assumption of an asynchronous network. This includes the three normal phases of Pre-prepare, Prepare, and Commit, as well as the View-Change, View-Change-Ack, and New-View phases for handling errors. For details, see [http: / / www.w3school.com / practicalbyzantinefaulttolerance.html]. Figure 3 and Figure 4 .

[0004] The view switching phase of PBFT defines a mechanism for handling timeouts, that is, when some nodes fail to complete the normal process due to offline or malicious behavior. However, there is no clear protocol for restoring nodes that are temporarily offline and then recover to normal operation. Therefore, in 2002, Miguel Castro and Barbara Liskov's paper "Practical Byzantine Fault Tolerance and Proactive Recovery" supplemented the original protocol, defining a series of communication protocols for nodes that have recovered after being offline to help them return to full membership.

[0005] However, the aforementioned protocols are only suitable for situations where a small number of nodes recover after going offline and return to normal operation with the help of other nodes, and they incur additional communication costs. However, if a large number of nodes temporarily go offline and their recovery times are inconsistent, or if some other error condition causes the views of each node to diverge completely or largely, these communication protocols become ineffective. Every node in the system will be trapped in an infinite view-change phase, unable to reach consensus and therefore unable to return to the normal consensus process. Currently, BFT protocols and their variants are prevalent in blockchain systems. Once such errors occur, the entire consensus process can stall, significantly impacting the system. Therefore, we propose a method for view switching in Byzantine Fault Tolerance protocols to improve this. Summary of the Invention

[0006] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0007] The present invention provides a view switching method in a Byzantine fault-tolerant protocol, comprising the following steps:

[0008] Step 1: When the node restarts from offline state, check the storage state, find the consensus message with the largest view number that reaches the Prepare state, and record its view number as V min ;

[0009] Step 2: Based on the message, record the view number and status of other nodes;

[0010] Step 3: Verify and update your own minimum backtracking view based on the message;

[0011] Step 4: Determine if a node timeout has occurred. If no timeout has occurred, return to step 2 to enter the next round of normal consensus. If a timeout has occurred, check the view number and message type of all nodes recorded in step 2, and switch views based on the number of nodes in the same view.

[0012] As a preferred technical solution of the present invention, the method for verifying and updating one's own minimum traceable view is as follows: during the consensus process, for any view switch message received from other nodes, regardless of whether its view number is the same as its own, if there is a verifiable consensus process that reaches the Prepare state, it is also stored in the local record. If the view number of this process is greater than the value of its own minimum traceable view number, its own minimum traceable view number is updated.

[0013] As a preferred technical solution of the present invention, the method of switching views based on the number of nodes in the same view is as follows: if more than 2 / 3 of the nodes are in the same view and the consensus round succeeds, the view number of the node is synchronized with them and the process returns to step 2 to enter the next round of normal consensus.

[0014] If more than 2 / 3 of the nodes are in the same view, but the consensus round is unsuccessful, the node updates its own view number to their number plus 1, and returns to step 2 to enter the view switching phase;

[0015] If no more than 2 / 3 of the nodes are in the same view, then update your view number back to your minimum traceable view and trace your view number back to V min , and return to step 2 to enter the view switching stage.

[0016] As a preferred technical solution of the present invention, the Prepare state means that the node has collected proposals for the message sequence number of the consensus message and signatures from more than 2 / 3 of the nodes.

[0017] As a preferred technical solution of the present invention, the message type refers to the type of message defined in the Byzantine fault tolerance protocol.

[0018] As a preferred technical solution of the present invention, the method of recording the view numbers and states of other nodes is to record the view numbers and message types of all nodes in the system within each timeout period.

[0019] As a preferred technical solution of the present invention, the message includes a Pre-Prepare message, a Prepare message, a Commit message, a View-Change message, a View-Change-Ack message or a New-View message.

[0020] The beneficial effects of the present invention are:

[0021] The view switching method in this Byzantine fault-tolerant protocol can ensure that after multiple nodes have been offline for a long time or multiple times, even if the view numbers are completely different, they can still return to the same view after a period of time and continue to reach consensus; for a BFT system with a view switching phase and a total number of nodes n (the maximum number of faulty or malicious nodes allowed is f = [(n-1) / 3], rounded down), as long as at least 2f+1 non-malicious nodes are restored to a normal online state, then even if a round of consensus fails, the consensus content that has reached the Prepare state can still be synchronized through the View-Change message. Thus, the V of these non-malicious nodes is minIf there is still no consensus after several rounds, the view numbers of these non-malicious nodes will return to V min At this time, since there are 2f+1 nodes with the same number, even if the consensus still fails, V min If the corresponding master node is a malicious node or is still offline, the view numbers of these 2f+1 nodes will increase synchronously until one of them becomes the master node and reaches consensus, and the entire system will return to normal. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings:

[0023] Figure 1 This is a flow chart of a view switching method in a Byzantine fault-tolerant protocol of the present invention;

[0024] Figure 2 This is a schematic diagram of the PBFT consensus network formed by 7 nodes in Example 2;

[0025] Figure 3 This is the normal 4-phase consensus diagram of PBFT;

[0026] Figure 4 This is the view switching flowchart of PBFT. DETAILED DESCRIPTION

[0027] The preferred embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0028] Example 1: Figure 1 As shown, the view switching method in the Byzantine fault tolerance protocol of the present invention includes the following steps:

[0029] Step 1: When the node restarts from offline state, check the storage state, find the consensus message with the largest view number that reaches the Prepare state, and record its view number as V min For this consensus message, the Pre-Prepare message and 2f+1 legal Prepare messages with the same view number and message sequence number are collected. These messages include Pre-Prepare messages, Prepare messages, Commit messages, View-Change messages, View-Change-Ack messages, or New-View messages.

[0030] Step 2: Based on the message, record the view number and state of other nodes. Since every message in the BFT system must contain the view number and message type, when a node receives a message from another node, even if the message is incompatible with its own state and will be discarded, it can still record the corresponding data after checking its correctness. If multiple messages are received, the last one will prevail. After each timeout period, the data is cleared and collected again.

[0031] Step 3: Verify and update your own minimum backtracking view based on the message;

[0032] Step 4: Determine if a node timeout has occurred. If no timeout has occurred, return to step 2 to enter the next round of normal consensus. If a timeout has occurred, check the view number and message type of all nodes recorded in step 2, and switch views based on the number of nodes in the same view.

[0033] The synchronization view number in step 4 may have different definitions in different Byzantine fault-tolerant protocols. Based on the specific design of the Byzantine fault-tolerant protocol, the current node changes its view number to the same value as the normal view number of each node that completes consensus in this round.

[0034] The method for verifying and updating one's own minimum traceable view is that during the consensus process, for any view switch message received from other nodes, regardless of whether its view number is the same as its own, if there is a verifiable consensus process that reaches the Prepare state, it is also stored in the local record, and if the view number of the process is greater than its own minimum traceable view number value, its own minimum traceable view number is updated.

[0035] The method of switching views based on the number of nodes in the same view is as follows: if more than 2 / 3 of the nodes are in the same view and the consensus round succeeds, the node synchronizes its own view number with them and returns to step 2 to enter the next round of normal consensus phase;

[0036] If more than 2 / 3 of the nodes are in the same view, but the consensus round is unsuccessful, the node updates its own view number to their number plus 1, and returns to step 2 to enter the view switching phase;

[0037] If no more than 2 / 3 of the nodes are in the same view, then update your view number back to your minimum traceable view and trace your view number back to V min , and return to step 2 to enter the view switching stage.

[0038] The Prepare state means that the node has collected proposals for the message sequence number of the consensus message and signatures from more than 2 / 3 of the nodes.

[0039] The message type refers to the type of message defined in the Byzantine fault tolerance protocol.

[0040] The method for recording the view numbers and states of other nodes is to record the view numbers and message types of all nodes in the system within each timeout period.

[0041] The view switching method in this Byzantine fault-tolerant protocol can ensure that after multiple nodes have been offline for a long time or multiple times, even if the view numbers are completely different, they can still return to the same view after a period of time and continue to reach consensus; for a BFT system with a view switching phase and a total number of nodes n (the maximum number of faulty or malicious nodes allowed is f = [(n-1) / 3], rounded down), as long as at least 2f+1 non-malicious nodes are restored to a normal online state, then even if a round of consensus fails, the consensus content that has reached the Prepare state can still be synchronized through the View-Change message. Thus, the V of these non-malicious nodes is min If there is still no consensus after several rounds, the view numbers of these non-malicious nodes will return to V min At this time, since there are 2f+1 nodes with the same number, even if the consensus still fails, V min If the corresponding master node is a malicious node or is still offline, the view numbers of these 2f+1 nodes will increase synchronously until one of them becomes the master node and reaches consensus, and the entire system will return to normal.

[0042] Example 2 is a BFT network with a total number of nodes n=7. The maximum number of malicious nodes that can be tolerated is f=2. The PBFT consensus protocol is adopted. The 7 nodes are interconnected in pairs and send messages according to the PBFT protocol. When switching views, the specific steps are as follows:

[0043] The view number of each node at the initial startup is 0. When it is restarted for some reason, it finds the consensus message with the largest view number in the Prepare state from its storage and records its view number as V min ;

[0044] During each consensus round, each node may receive various messages from the other six nodes, including Pre-Prepare, Prepare, Commit, View-Change, View-Change-Ack, and New-View messages. According to the PBFT message definition, each message contains the current view number and message type. Therefore, when receiving a message from the other six nodes, the view number and message type are recorded. New messages from the same node within a consensus cycle can overwrite the state of existing messages, and these states are reset to zero at the beginning of each cycle.

[0045] In each round, if each node receives any View-Change message from the other 6 nodes, it checks the validity of its data, obtains its Prepare set, and updates it to its own storage. If there is a consensus message with a view number greater than its own V min , then update V min To the same, after a round of consensus, if the consensus is completed normally, the view number remains unchanged and is based on Figure 1 The next normal phase of PBFT is entered as shown. If the consensus fails to be completed normally, the view number needs to be changed.

[0046] If you fail to complete the normal consensus process, you will first check the view numbers and message types of the other 6 nodes you have recorded during the week. If at least 5 of the 7 nodes, including yours, have the same view number, recorded as V0, and there are at least 5 commit messages for the same message and the same message sequence number during this period, then it is considered that others have completed the consensus, and you will change your view number to V0 and try to enter the next round of normal consensus.

[0047] If at least 5 out of 7 nodes including the user have the same view number, which is V0, and there are no at least 5 commit messages for the same message with the same message sequence number in this cycle, then it is considered that others have also failed to succeed in this round of consensus, and the user's view number is changed to V0, and the user is assigned a new view number according to the consensus rule. Figure 4 The process shown enters the next round of view switching process.

[0048] If the view numbers of at least 5 nodes are not the same among the 7 nodes including the node itself, the views of the nodes are considered out of sync and the node's view number is changed to V. min , and according to Figure 4 The process shown enters the next round of view switching process.

[0049] The above embodiments illustrate how the disclosed method of the present invention operates. Those skilled in the art will appreciate that the examples provided here are merely examples of a set of nodes for a Byzantine fault-tolerant protocol. Any Byzantine fault-tolerant protocol with a view switching process, and any consensus network composed of any legal number of nodes, can employ the method described in the present invention to perform view switching.

[0050] Finally, it should be noted that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art will be able to modify the technical solutions described in the aforementioned embodiments or substitute equivalents for some of the technical features. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A view switching method in a Byzantine fault-tolerant protocol, characterized in that: It includes the following steps: Step 1: When the node restarts from offline state, check the storage state, find the consensus message with the largest view number that reaches the Prepare state, and record its view number as ; Step 2: Record the view number and status of other nodes according to the message; Step 3: Verify and update your own minimum backtracking view based on the message; Step 4: Determine if a node timeout has occurred. If no timeout has occurred, return to step 2 and enter the next round of normal consensus. If a timeout has occurred, check the view number and message type of all nodes recorded in step 2, and switch views based on the number of nodes in the same view.

2. A view switching method in a Byzantine fault tolerant protocol according to claim 1, characterized in that: The method for verifying and updating one's own minimum traceable view is that during the consensus process, for any view switch message received from other nodes, regardless of whether its view number is the same as its own, if there is a verifiable consensus process that reaches the Prepare state, it is also stored in the local record, and if the view number of the consensus process is greater than its own minimum traceable view number value, its own minimum traceable view number is updated.

3. The view switching method in a Byzantine fault tolerant protocol according to claim 1, wherein: The method of switching views based on the number of nodes in the same view is as follows: if more than 2 / 3 of the nodes are in the same view and the consensus round succeeds, the node synchronizes its own view number with them and returns to step 2 to enter the next round of normal consensus phase; If more than 2 / 3 of the nodes are in the same view, but the consensus round is unsuccessful, the node updates its own view number to their number plus 1, and returns to step 2 to enter the view switching phase; If no more than 2 / 3 of the nodes are in the same view, then the node updates its own view number to its minimum traceable view and returns to step 2 to enter the view switching phase.

4. The view switching method in a Byzantine fault tolerant protocol according to claim 2, characterized in that: The Prepare state refers to the collection of proposals for the message sequence number of the consensus message and signatures from more than 2 / 3 of the nodes.

5. The view switching method in a Byzantine fault tolerant protocol according to claim 1, characterized in that: The message type refers to the type of message defined in the Byzantine fault tolerance protocol.

6. The view switching method in a Byzantine fault tolerant protocol according to claim 1, characterized in that: The method for recording the view numbers and states of other nodes is to record the view numbers and message types of all nodes in the system within each timeout period.

7. The view switching method in a Byzantine fault tolerant protocol according to claim 1, characterized in that: The messages include a Pre-Prepare message, a Prepare message, a Commit message, a View-Change message, a View-Change-Ack message or a New-View message.

Images