Byzantine fault-tolerant consensus method and device for dealing with unpredictable communication failures

Abstract

The present invention provides a Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures, which includes four stages: communication status evaluation, request transmission, consensus transmission and recovery. First, the client sends a test instruction to all working nodes to evaluate the probability of communication failure of the current network and ensure that the network environment is acceptable. Then, the master node accepts and broadcasts the client request to all nodes to ensure that all nodes receive the request. Then, all normal nodes verify the consistency of the request through two broadcasts and reach a consensus. Finally, the consensus node broadcasts the result, notifies the client, and enables the honest nodes that did not participate in the consensus due to the communication failure to restore synchronization, ensure the synchronization of subsequent consensus rounds, and avoid the honest nodes from becoming unreliable nodes due to communication failures. This method improves the stability and fault tolerance of the system.

Description

Technical Field

[0001] The present invention relates to the fields of distributed computing and blockchain, and in particular to a Byzantine fault-tolerant consensus method for coping with unpredictable communication failures. Background Art

[0002] The Byzantine Fault Tolerance (BFT) consensus protocol is used to ensure that the system can reach a consistent decision even in the presence of malicious or faulty nodes. It is a key technology in modern parallel and distributed computing systems. The Byzantine Fault Tolerance consensus aims to ensure that the system can reach a consensus even in the presence of malicious nodes.

[0003] Related technical research shows that the existing Byzantine fault-tolerant consensus protocol has some obvious deficiencies in dealing with unpredictable communication failures. For example, the PBFT protocol assumes that the communication environment of the system is reliable, but in actual applications, complex network environments may cause message loss or delay. This situation will trigger the message retransmission and timeout mechanism of the protocol, adding additional delays and computing overhead, thereby reducing the fault tolerance and overall performance of the system (Castro M et al.) [1] ; HoneyBadgerBFT is a consensus protocol based on asynchronous assumptions, which takes into account the possibility that messages may be delayed or lost. Although this protocol can handle the uncertainty of messages, its complex algorithm implementation leads to high computational and communication overhead, which in turn affects the overall efficiency of the system (Miller A et al.) [2] .

[0004] [1]Castro M, Liskov B. Practical byzantine fault tolerance[C] / / OsDI.1999, 99(1999): 173-186.

[0005] [2]Miller A, Xia Y, Croman K, et al. The honey badger of BFTprotocols[C] / / Proceedings of the 2016 ACM SIGSAC conference on computer and communications security. 2016: 31-42. Summary of the invention

[0006] In response to the above problems, the present invention proposes a Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures. It effectively solves the limitations of existing consensus protocols in the event of communication failures. The present invention can ensure that the system reaches a consensus in an unpredictable communication failure environment through a four-stage protocol process (communication status evaluation, request transmission, consensus transmission and recovery), and ensure that honest nodes maintain node reliability in the state of communication failure, thereby ensuring consensus synchronization in subsequent rounds. The present invention proposes a new fault-tolerant threshold formula to quantify the impact of communication failures on the system's fault tolerance capabilities, thereby tolerating more Byzantine nodes. In addition, the present invention reduces unnecessary message retransmissions and computing overhead, improves the overall efficiency and performance of the system, and at the same time enhances adaptability and flexibility, making it more reliable in complex network environments.

[0007] A Byzantine fault-tolerant consensus method for coping with unpredictable communication failures, characterized by comprising the following stages:

[0008] Phase 1: Communications Status Assessment

[0009] The client sends a test command to all working nodes. The working node that receives the test command immediately responds to the client with its ID and the test command, so that the client knows the node status and communication environment. The client calculates the communication failure probability of the current network based on the received reply. If the loss rate is too high, the client waits until the loss rate reaches the standard, that is, the network environment is acceptable.

[0010] Phase 2: Request delivery phase:

[0011] After the communication status is evaluated, the network environment is acceptable. At this time, the master node will accept the request from the client, and then the master node will broadcast the request to all nodes. Nodes that successfully receive the request message can smoothly enter the next stage of the protocol.

[0012] The third stage: consensus transmission stage:

[0013] To detect whether the master node is a Byzantine node, all normal nodes need to first perform a complete broadcast to confirm the validity of the request and confirm that the same request information has been received; all nodes that normally receive the broadcast perform the broadcast again so that all nodes that can normally receive and transmit messages can reach a consensus on the request.

[0014] Phase 4: Recovery Phase:

[0015] The nodes that successfully reach a consensus will broadcast to the client and all other nodes to inform the client of the consensus result of this round and ensure that the honest nodes that did not participate in the consensus due to network influence can receive enough recovery messages to complete the consensus reached, remain honest nodes and ensure the synchronization of subsequent rounds, thus solving the problem of node failure caused by the failure of the communication environment to correctly transmit messages.

[0016] Preferably, the acceptable standard for the network environment in the communication status evaluation phase is that the message loss rate is lower than a preset threshold.

[0017] Preferably, when the master node in the request transmission phase broadcasts the request to all nodes, a communication broadcast mechanism based on the majority agreement principle is adopted.

[0018] Preferably, the two complete broadcasts in the consensus transfer phase are respectively a request verification broadcast and a consensus confirmation broadcast, so as to ensure the consistency and validity of the request.

[0019] Preferably, the nodes that reach consensus in the recovery phase broadcast the consensus results to the client and all other nodes, notify the consensus results of this round and synchronize the honest nodes that failed to participate in the consensus due to communication failures, to ensure that the honest nodes that failed to participate in the consensus due to communication failures can synchronize the consensus that has been reached, and avoid becoming unreliable nodes.

[0020] The present invention also discloses a non-volatile storage medium, characterized in that the non-volatile storage medium includes a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the above method.

[0021] The present invention also discloses an electronic device, characterized in that it comprises a processor and a memory; the memory stores computer-readable instructions, and the processor is used to execute the computer-readable instructions, wherein the computer-readable instructions execute the above method when they are executed. Beneficial Effects

[0022] 1) This invention proposes a method for estimating the probability of current network communication failure by sending a test command before the consensus protocol starts. This method evaluates the network environment in real time before the consensus process starts to ensure that the system enters the consensus operation only after detecting that the communication environment meets certain reliability standards, thereby improving the stability and reliability of the system.

[0023] 2) Quantify the impact of communication failures on the system's fault tolerance. This paper designs a new Byzantine node tolerance threshold formula: ,in represents the probability of communication failure, Indicates the total number of nodes, Represents the number of Byzantine nodes. Combining the message loss rate and the proportion of Byzantine nodes in the system, a threshold that can achieve Byzantine fault tolerance under unpredictable message delivery failure conditions is proved, providing a quantitative assessment of network instability and its impact on Byzantine fault tolerance.

[0024] 3) Reduce unnecessary message retransmission and computational overhead. The present invention introduces two complete broadcasts in the request transmission and consensus transmission stages, so that it can ensure the validity and consistency of requests in different network environments, reduce the probability of consensus failure caused by network unreliability, and effectively reduce unnecessary message retransmission and computational overhead.

[0025] 4) Enhances the reliability and continuity of the system and prevents honest nodes from becoming unreliable due to communication failures. The present invention designs a method for broadcasting consensus results in the recovery phase. This method uses a broadcast mechanism to enable honest nodes that fail to participate in the consensus due to network problems to synchronize the consensus that has been reached. While the client is informed of the current consensus results, it can also prevent honest nodes from becoming unreliable nodes due to communication failures, ensuring the synchronization of subsequent consensus rounds and enhancing the reliability and continuity of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a flow chart of the Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures of the present invention, which graphically shows the brief process of the method of the present invention. In ①, the client broadcasts test information, and the working node with normal communication responds to the client. The client decides whether to enter ② based on the current communication status; in ②, the client passes the request to the master node of the current round, and the master node broadcasts the request to all working nodes; in ③, the working nodes broadcast confirmation request information to ensure the validity and consistency of the request, and broadcast the consensus on the request; in ④, the nodes with normal communication that have reached consensus normally broadcast the consensus results of this round, and the client receives the consensus results of this round. The loyal nodes that failed to reach consensus due to network influences synchronize the consensus results of this round after receiving a certain number of consensus result messages. DETAILED DESCRIPTION

[0027] Figure 1 As shown, the Byzantine fault-tolerant consensus method for coping with unpredictable communication failures proposed in the present invention mainly includes four stages: communication status evaluation stage, request transmission stage, consensus transmission stage and recovery stage.

[0028] Phase 1: Communication Status Assessment:

[0029] In this phase, the client needs to send a test command test to all working nodes. When the working node receives the test command, it immediately responds with a reply message containing its ID and test, so that the client can evaluate the communication environment. The specific steps are as follows:

[0030] 1) Send test command:

[0031] The client sends a message containing a test command test to all working nodes, requiring the working nodes to respond immediately after receiving the test command.

[0032] 2) Receiving node reply:

[0033] After receiving the test command, the working node will immediately respond with a reply message containing its node ID and the test command test, ensuring that the client can detect the online status of the node and the real-time status of the network environment.

[0034] 3) Calculate the message loss rate:

[0035] When the number of replies received by the client is greater than (F1 is the Byzantine node ratio, n is the total number of nodes), the client can calculate the message loss rate of the current network. In the present invention, the message loss rate is defined as the probability of a message being lost during transmission. We define the message loss rate based on the relationship between the signal-to-noise ratio, the bit error rate and the message loss rate as follows:

[0036]

[0037] Where L is the bit length of the message and b is the bit error rate.

[0038] 4) Network environment assessment:

[0039] According to the Byzantine node tolerance threshold formula proposed by this method Variant, if the calculated message loss rate Below the preset threshold,

[0040]

[0041] The current network environment is considered acceptable and the next request transmission phase can be carried out. If the message loss rate is too high, the client needs to wait for a while and resend the test command until the network environment reaches the acceptable standard.

[0042] The design of the communication status evaluation phase can effectively avoid consensus operations when the network environment is unstable, thereby improving the stability and reliability of the system.

[0043] Phase 2: Request delivery phase:

[0044] After the message delivery failure estimation phase is completed, if the network environment is evaluated as acceptable, the system will enter the request delivery phase. In this phase, the master node is responsible for receiving requests from the client and broadcasting the request to all nodes. The specific steps are as follows:

[0045] 1) Receive client request:

[0046] After the network environment is acceptable, the client broadcasts a message with the ID of the current round master node and the request content. After the node receives the message sent by the client, if the node is the master node of this round, it will prepare to broadcast the request message to all working nodes; if the node is not the master node of this round, it will ignore this request message.

[0047] 2) Broadcast request message:

[0048] The master node broadcasts the request message to all the working nodes in the system. After receiving the request message, each working node records the request message and prepares to enter the next stage of request validity processing.

[0049] In this way, the master node broadcasts the client's request information to all working nodes, laying the foundation for the next consensus transmission stage.

[0050] The third stage: consensus transmission stage:

[0051] The consensus transmission phase is an important phase to ensure that all nodes reach consensus on the request. In this phase, all loyal nodes first perform a complete broadcast to confirm the validity of the request; if it is a valid request, the loyal node will broadcast the Agree message for the request, and at the same time accept and process other Agree messages to determine whether consensus has been reached. The specific steps are as follows:

[0052] 1) Initial broadcast:

[0053] After receiving the request message, all normal nodes first verify the message by checking the message format and structure, timestamp or sequence number, etc. to ensure that it has not been tampered with and the source is reliable. Then, the node will broadcast the confirmation information of the request Request Confirm to other nodes.

[0054] 2) Message Verification:

[0055] When each node receives a request confirmation message Request Confirm broadcasted by other nodes, it records the request confirmation information; when the number of recorded request confirmation messages messages meets (f is the maximum number of Byzantine nodes that the system can withstand), the node determines that the request is valid and prepares to broadcast an Agree message for the request to reach a consensus.

[0056] 3) Secondary broadcast:

[0057] All loyal nodes that are not affected by communication failures broadcast Agree to all other nodes. The broadcast content includes the Agree status of the node to the request in this round. After receiving the Agree message from other nodes, the node records it and uses it as the basis for consensus in subsequent steps.

[0058] 4) Consensus reached:

[0059] After the secondary broadcast is completed, each node will count the number of Agree messages received. If the number of Agree messages received meets AGREE, (f is the maximum number of Byzantine nodes that the system can withstand), the node considers that consensus has been reached, the node marks the request as processed and prepares to enter the recovery phase.

[0060] Through the double broadcast mechanism, the system can effectively ensure the consistency and validity of the request message, effectively reach consensus, prevent interference from Byzantine nodes, and improve the reliability of consensus.

[0061] Phase 4: Recovery Phase:

[0062] The recovery phase is the last phase of the consensus process. Its purpose is to notify the client of the consensus result of this round, ensure that all nodes synchronize the latest consensus result, prevent honest nodes from becoming unreliable nodes due to communication failures, and ensure synchronization of subsequent consensus rounds. The specific steps are as follows:

[0063] 1) Broadcast of consensus results:

[0064] The nodes that successfully reach consensus will broadcast the consensus results to all other nodes in the system. The broadcast content includes the processing results of the request message and the consensus confirmation information.

[0065] 2) Client notification:

[0066] The nodes that reach consensus will send a consensus result notification to the client to ensure that the client can understand the processing status of the request in a timely manner.

[0067] 3) Not participating in normal node recovery:

[0068] Nodes that fail to participate in the consensus process due to network environment or other factors will record the consensus results broadcasted by other nodes after receiving them. ( is the number of Byzantine nodes), the consensus result is determined to be valid, and data synchronization is performed to ensure that its status is restored to be consistent with other nodes.

[0069] Through the design of the recovery phase, the client is notified of the processing results of the request in a timely manner, and the system can ensure the consistency of the status of all honest nodes, avoid honest nodes from becoming unreliable nodes due to communication failures, ensure the synchronization of subsequent consensus rounds, and enhance the reliability and continuity of the system.

[0070] The present invention proposes a Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures, and solves the defects in the above-mentioned prior art through a protocol process including four stages: communication status evaluation, request transmission, consensus transmission and recovery. In the communication status evaluation stage, the system performs real-time evaluation of the network environment by sending test instructions to ensure that consensus operations are performed only after the network reliability meets the standards, which significantly improves the stability of the system. In the request transmission and consensus transmission stages, the present invention effectively ensures the validity and consistency of the request through two broadcast mechanisms, avoids the interference of Byzantine nodes to a greater extent, and reduces unnecessary message retransmissions and computing overhead. In the recovery stage, the system broadcasts the consensus results so that nodes that do not participate in the consensus can synchronize the consensus that has been reached, avoiding becoming unreliable nodes due to communication failures. Through these technical means, the present invention successfully achieves high fault tolerance and system consistency in a complex network environment, thereby significantly improving the reliability and performance of the system and fully solving the deficiencies in the prior art.

[0071] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions only describe the principles of the present invention. The present invention may be subject to various changes and improvements without departing from the spirit and scope of the present invention. These changes and improvements fall within the scope of the present invention. The scope of protection claimed by the present invention is defined by the attached claims and their equivalents.

Claims

1. A Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures, characterized in that: The following phases are included: Communication status evaluation phase: The client sends a test command to all normal working nodes. The normal nodes that receive the test command immediately reply with a response containing their ID and the test command. Byzantine nodes may not reply or send a false reply to interfere. The client calculates the message loss rate of the current network based on the received reply. 1) Send test command: The client sends a message containing a test command test to all working nodes, requiring the working nodes to respond immediately after receiving the test command; 2) Receiving node reply: After receiving the test command, the working node will immediately respond with a reply message containing its node ID and the test command test, ensuring that the client can detect the online status of the node and the real-time status of the network environment; 3) Calculate the message loss rate: When the number of replies received by the client is greater than When F1 is the Byzantine node ratio and n is the total number of nodes, the client can calculate the message loss rate of the current network; the message loss rate is defined as the probability of a message being lost during transmission. The message loss rate is defined as follows based on the relationship between the signal-to-noise ratio, bit error rate and message loss rate: ； Where L is the bit length of the message and b is the bit error rate; 4) Network environment assessment: Byzantine node tolerance threshold formula , if the calculated message loss rate Below the preset threshold, ； If the message loss rate is too high, the client needs to wait for a while and resend the test command until the network environment reaches the acceptable standard. Request transmission phase: When the network environment is acceptable, the master node receives the request from the client and broadcasts the request to all nodes; Consensus transmission phase: All non-Byzantine nodes first perform a complete broadcast to confirm the validity of the request and confirm that the same request information has been received; all nodes that normally receive the broadcast perform the broadcast again, so that all nodes that can normally receive and transmit messages reach a consensus on the request; Recovery phase: The node that reaches consensus broadcasts to the client and all other nodes to inform the client of the consensus result of this round and ensure that the nodes that did not participate in the consensus due to network influence can receive enough recovery messages to complete the consensus reached and ensure the synchronization of the consensus in subsequent rounds.

2. A Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures according to claim 1, characterized in that: The acceptable standard for the network environment in the communication status evaluation phase is that the message loss rate is lower than a preset threshold.

3. According to claim 1, a Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures is characterized in that: When the master node in the request transmission phase broadcasts the request to all nodes, it adopts a communication broadcast mechanism based on the principle of majority consent.

4. A Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures according to claim 1, characterized in that: The two complete broadcasts in the consensus transmission phase are the preparatory broadcast and the consensus confirmation broadcast, which are used to ensure the consistency and validity of the request.

5. A Byzantine fault-tolerant consensus method for dealing with unpredictable communication failures according to claim 1, characterized in that: The nodes that reach consensus in the recovery phase broadcast the consensus results to the client and all other nodes to notify the consensus results of this round and synchronize the nodes that did not participate in the consensus.

6. A Byzantine fault-tolerant consensus device that can handle unpredictable communication failures, characterized by: Communication status evaluation phase module: The client sends a test command to all working nodes. The working nodes that receive the test command immediately reply with a reply containing their ID and the test command. The client calculates the message loss rate of the current network based on the received reply. 1) Send test command: The client sends a message containing a test command test to all working nodes, requiring the working nodes to respond immediately after receiving the test command; 2) Receiving node reply: After receiving the test command, the working node will immediately respond with a reply message containing its node ID and the test command test, ensuring that the client can detect the online status of the node and the real-time status of the network environment; 3) Calculate the message loss rate: When the number of replies received by the client is greater than When F1 is the Byzantine node ratio and n is the total number of nodes, the client can calculate the message loss rate of the current network; the message loss rate is defined as the probability of a message being lost during transmission. The message loss rate is defined as follows based on the relationship between the signal-to-noise ratio, bit error rate and message loss rate: ； Where L is the bit length of the message and b is the bit error rate; 4) Network environment assessment: Byzantine node tolerance threshold formula , if the calculated message loss rate Below the preset threshold, ； If the message loss rate is too high, the client needs to wait for a while and resend the test command until the network environment reaches the acceptable standard. Request transmission phase module: When the network environment is acceptable, the master node receives the request from the client and broadcasts the request to all nodes; Consensus transmission phase module: All normal nodes first perform a complete broadcast to confirm the validity of the request and confirm that the same request information has been received; all nodes that normally receive the broadcast perform the broadcast again, so that all nodes that can normally receive and transmit messages can reach a consensus on the request; Recovery phase module: The node that reaches consensus broadcasts to the client and all other nodes to inform the client of the consensus result of this round and ensure that the nodes that did not participate in the consensus due to network influence can receive enough recovery messages to complete the consensus reached and ensure the synchronization of the consensus in subsequent rounds.

7. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored program, wherein the program controls the device where the non-volatile storage medium is located to execute the method according to any one of claims 1 to 5 when the program is executed.

8. An electronic device, characterized in that: It comprises a processor and a memory; the memory stores computer-readable instructions, and the processor is used to execute the computer-readable instructions, wherein the computer-readable instructions execute the method described in any one of claims 1 to 5 when executed.

Images