Enhanced Byzantine consensus method, device and readable storage medium in a distributed system

Abstract

The present invention discloses an enhanced Byzantine consensus method, device and readable storage medium in a distributed system, and relates to the field of blockchain network communication technology. The method includes an initialization process and a consensus process. The initialization process includes grouping and determining the leader node leader; the consensus process includes a request phase, a pre-preparation phase, a preparation phase and a response phase; when the node receives the pre-preparation message broadcast by the master node, it determines that it is the leader node and verifies that the master node information is correct, and then continues the consensus and puts the pre-preparation message into a temporary storage pool; when the node receives the preparation message broadcast by the leader node, it determines that it is the leader node or the master node, and when it receives the preparation message broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool. The present invention can effectively reduce the communication overhead between nodes, improve system throughput, and enhance system reliability and anti-Byzantine fault tolerance.

Description

Technical Field

[0001] The present invention relates to the field of blockchain network communication technology, and in particular to an enhanced Byzantine consensus method, device and readable storage medium in a distributed system. Background Art

[0002] The consensus algorithm is a mechanism in a distributed network that ensures that all nodes agree on the data status. Due to the characteristics of distributed networks, the traditional centralized mechanism is no longer applicable. Nodes need to solve the data consistency problem through the consensus algorithm to ensure the validity of the data and the unity of the final state, thereby preventing fraud, double payment and other problems. The consensus algorithm not only determines the security of the network, but also directly affects the performance and scalability of the system.

[0003] There are three consensus algorithms used in the prior art: Raft consensus algorithm, practical Byzantine fault-tolerant consensus algorithm and weighted Byzantine fault-tolerant consensus. Among them, the Raft consensus algorithm includes two core parts: leader election and log replication. Nodes in the Raft algorithm can be in three states: leader, follower and candidate. The Raft consensus algorithm has the following disadvantages, which make it unsuitable as a consensus algorithm for large-scale distributed networks: 1. Scalability limitations: Raft is mainly suitable for clusters with small and medium-sized nodes. When the number of nodes increases, the complexity of the election process and the load of the leader will increase significantly, making Raft inefficient in large-scale clusters. 2. Low fault tolerance: Raft's fault recovery capability depends on the leader node. Once the leader node fails, it will cause a short pause in the system until a new leader is elected, and the system will be unable to provide services during this period. Although the election mechanism ensures the election of a new leader, this process will bring unreliability to the system. 3. Lack of Byzantine fault tolerance: Raft cannot deal with Byzantine errors (i.e., nodes may provide malicious or incorrect responses). Therefore, Raft cannot guarantee security and consistency in scenarios where malicious nodes exist, which limits its application in systems with a high number of Byzantine nodes. Practical Byzantine Fault Tolerance (PBFT) is a consensus algorithm used to achieve consensus in distributed systems, especially in the face of Byzantine faults (i.e., nodes may intentionally or faultily give wrong information). The main goal of PBFT is to provide a reliable mechanism to deal with possible malicious nodes. Although the PBFT algorithm implements the architecture in BASE theory to a certain extent, since PBFT was not originally designed specifically for distribution, its traditional client / server response form has limited its application in distributed systems and cannot meet complex application requirements, making the traditional PBFT algorithm unsuitable for direct application in peer-to-peer (P2P) networks in high-concurrency distributed environments. The innovation of the Weighted Byzantine Fault Tolerance (WBFT) consensus algorithm is that it believes that the confirmation phase (Commit) has little effect on the overall consensus result. This is because in the preparation phase, the nodes have verified and confirmed the validity of the proposal with each other, and have actually reached a consensus. Although the re-broadcast and confirmation in the confirmation phase increases the reliability of the system, it also brings additional communication overhead and delay.At the same time, WBFT introduces a weight mechanism. Each node will have a base weight and a running weight. The weight of the node represents the activity level and credibility of the node in the system. The management node will decide whether the node can participate in the consensus based on the weight of the node. Through the above optimization, the WBFT algorithm significantly improves the system performance. Although the security of the distributed system is improved, its shortcomings cannot be ignored. First, its efficiency is low, and the complex communication process leads to slow consensus; second, its scalability is poor, and the communication complexity increases sharply when the network scale expands; third, the weight distribution may lead to centralization risks, and the power of large nodes is too concentrated; in addition, the resource consumption is large, and the node performance requirements are high; weight distribution and flexibility are also problems, it is difficult to adjust the weight, and the system adaptability is weak. These shortcomings limit the widespread promotion of weighted Byzantine fault-tolerant consensus in practical applications. Summary of the invention

[0004] In view of the above-mentioned deficiencies in the prior art, the present invention provides a method, device and readable storage medium for enhancing Byzantine consensus in a distributed system, which can effectively reduce the communication overhead between nodes, improve system throughput, and enhance system reliability and anti-Byzantine fault tolerance.

[0005] In a first aspect, the present invention provides an enhanced Byzantine consensus method in a distributed system, including an initialization process and a consensus process, wherein the initialization process includes the following steps:

[0006] S10: Group all nodes in the network, and number the master node as N0, and the replica nodes as Ni, where i is [1, N], N is the number of replica nodes, and N replica nodes are randomly and evenly divided into G node groups, G=3f+1, f is the number of Byzantine nodes; S20: In each node group, the leader node regularly sends heartbeat signals to the follower nodes to maintain its leadership;

[0007] S30: If the member node follower does not receive a heartbeat signal sent from the leader node leader within a preset time period, the member node follower changes its own state to a candidate node candidate and starts a leader election;

[0008] S40: the candidate node candidate broadcasts a campaign message to other nodes in the node group and invites them to vote for themselves;

[0009] S50: If the candidate node obtains more than half of the votes before the election timeout, it will become the new leader node leader;

[0010] The consensus process includes a request phase, a pre-preparation phase, a preparation phase, and a response phase;

[0011] In the request phase: the client node Client sends a transaction request msg to the master node;

[0012] In the pre-preparation stage: after receiving the transaction request msg sent by the client node Client, the master node broadcasts the pre-preparation message to all nodes;

[0013] In the preparation phase: after receiving the pre-preparation message broadcast by the master node, the node determines whether it is the leader node. If it is the leader node, it verifies whether the master node information is correct. When the master node information is verified to be correct, it continues the consensus and puts the pre-preparation message into the temporary storage pool, and then broadcasts the preparation message to other nodes;

[0014] In the response phase: when a node receives the prepare message broadcast by the leader node, it determines whether it is the leader node or the master node. If it is the leader node or the master node, after receiving the prepare message broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool, and then sends a receipt containing a timestamp to the client node Client.

[0015] Furthermore, in step S50, if the candidate node candidate obtains less than half of the votes after the election timeout, the candidate node candidate will continue to broadcast election messages and re-initiate the next round of election.

[0016] Furthermore, the method also includes: in the preparation stage, when the verification master node information is wrong, the pre-preparation message is not received and the consensus is directly abandoned.

[0017] Furthermore, the method further comprises: in the preparation phase, if it is not the leader node, placing the pre-preparation message into a temporary storage pool, and waiting for the preparation message broadcast by the leader node.

[0018] Furthermore, the method further includes: in the response phase, when the node does not receive the preparation information broadcast by more than 2f+1 nodes, the node will continue to wait until it receives the preparation information broadcast by more than 2f+1 nodes.

[0019] Furthermore, the method also includes: if it is not a leader node or a master node, after receiving a preparation message broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in a local storage pool.

[0020] Furthermore, the method further includes: if it is not a group leader node or a master node, when no preparation message broadcast by more than 2f+1 nodes is received, the node will continue to wait until it receives preparation information broadcast by more than 2f+1 nodes.

[0021] In a second aspect, the present invention provides an enhanced Byzantine consensus device in a distributed system, comprising: an initialization process module and a consensus process module;

[0022] The initialization process module includes:

[0023] The grouping unit is used to group all nodes in the network and number the master node as N0 and the replica nodes as Ni. The value of i is [1, N], where N is the number of replica nodes. The N replica nodes are randomly and evenly divided into G node groups, where G=3f+1 and f is the number of Byzantine nodes.

[0024] The heartbeat signal unit is used to periodically send heartbeat signals to the follower nodes in each node group to maintain its leadership position.

[0025] A state transition unit, configured to, if the member node follower does not receive a heartbeat signal sent from the group leader node within a preset time period, change its own state to a candidate node candidate and start leader election;

[0026] The broadcast campaign unit is used by the candidate node candidate to broadcast campaign messages to other nodes in the node group and invite them to vote for themselves;

[0027] The leader node unit is used to become the new leader node leader if the candidate node obtains more than half of the votes before the election timeout;

[0028] The consensus process module includes:

[0029] Request unit, used for the client node Client to send a transaction request msg to the master node;

[0030] The pre-preparation phase unit is used to broadcast the pre-preparation message to all nodes after the master node receives the transaction request msg sent by the client node Client;

[0031] The preparation unit is used to determine whether it is the leader node after receiving the pre-preparation message broadcast by the master node. If it is the leader node, it verifies whether the master node information is correct. When the master node information is verified to be correct, it continues the consensus and puts the pre-preparation message into the temporary storage pool, and then broadcasts the preparation message to other nodes;

[0032] The response unit is used to determine whether it is a leader node or a master node after receiving a prepare message broadcast by the leader node. If it is a leader node or a master node, after receiving prepare messages broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool, and then sends a receipt containing a timestamp to the client node Client.

[0033] In a third aspect, the present invention provides a readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the processor executes the steps of the above method.

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

[0035] When the network system of the present invention is started or needs to be regrouped, the master node will first determine the surviving nodes in the entire network system and randomly group the nodes, while ensuring that the number of nodes in each node group is the same, and then use the Raft consensus algorithm to select a leader for each node group. All nodes will participate in the improved PBFT consensus, but only the master node and the leader node can broadcast, and other replica nodes will only receive messages from the master node and complete the consensus after verification. By combining the Raft algorithm with the verification phase of PBFT, the leader node can quickly initiate and reach a consensus. Since the number of nodes participating in the global broadcast is reduced while the number of nodes participating in the consensus does not change, the number of message transmission rounds in the network is significantly reduced, the communication delay and communication overhead are reduced, and the consistency between the nodes of the network system is guaranteed.

[0036] The present invention optimizes the PBFT algorithm to obtain the Enhanced Byzantine Fault Tolerant Consensus (REBFT) algorithm, cancels the full network broadcast in the confirmation phase, and simplifies the original three-stage consensus process into two stages, that is, only retaining the pre-preparation and preparation stages. Therefore, the number of message transmissions is greatly reduced, and the communication complexity is also reduced to a lower level. By reducing unnecessary consensus steps and reducing the number of global broadcast nodes, by optimizing the consensus process to reduce the number of communications and introducing the design of node groups, a significant improvement in consensus performance and communication overhead is achieved, especially in the presence of a large number of nodes, the throughput of the system can be significantly improved, ensuring that efficient data processing capabilities can be maintained under high load conditions.

[0037] The REBFT algorithm in the present invention retains the anti-Byzantine characteristics of the PBFT algorithm, can handle attacks from malicious nodes or abnormal nodes, and ensure the consistency and security of the system. At the same time, unlike the PBFT algorithm, as long as any node becomes a Byzantine node, it will affect the system. Since only the group leader and the master node have the ability to broadcast globally, it means that as long as the group leader node does not become a Byzantine node, it will not affect the consensus performance of the system, effectively reducing the impact of the Byzantine node on the system, significantly improving the reliability of the system and the ability to resist Byzantine nodes, improving the reliability of the system in an insecure network, and significantly improving the robustness and security of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 It is a network architecture diagram for a method for enhancing Byzantine consensus provided by an embodiment of the present invention;

[0039] Figure 2 The embodiment of the present invention provides an application Figure 1 The network structure diagram after grouping in ;

[0040] Figure 3 It is a diagram of a node identity change process in an enhanced Byzantine consensus method provided by an embodiment of the present invention;

[0041] Figure 4 This is a workflow diagram of an enhanced Byzantine consensus method provided by an embodiment of the present invention;

[0042] Figure 5 is a probability density surface diagram of Byzantine node distribution provided by an embodiment of the present invention;

[0043] Figure 6 It is a flow chart of the optimized PBFT consensus algorithm provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0045] Example 1

[0046] An embodiment of the present invention provides an enhanced Byzantine consensus method in a distributed system, including an initialization process and a consensus process. Figure 1As shown, it is a network architecture diagram for the enhanced Byzantine consensus method provided by an embodiment of the present invention. The enhanced Byzantine consensus method (REBFT) consensus network combines the PBFT (Practical Byzantine FaultTolerance) network and the Raft consensus network to form a two-layer consensus network structure. The two-layer consensus network structure includes a master node, a node group, a leader node, a member node, and a client. The client communicates with the master node and implements data interaction.

[0047] In this embodiment, the initialization process includes the following steps S10 to S50. Specifically, the initialization process includes:

[0048] Step S10: Group all nodes in the network. Figure 2 As shown in the figure, when the system starts or needs to be regrouped, the primary node is numbered as N0, and the replica nodes are numbered as Ni, where the value of i is [1, N], and N is the number of replica nodes. Then, the N replica nodes are randomly and evenly divided into G node groups, where G=3f+1, and f is the number of Byzantine nodes.

[0049] In this embodiment, the primary node is a node that receives client requests and starts the consensus process in the REBFT consensus network. The replica node is a node that can convert between the primary node and the primary node by introducing the concept of view, and the view acts as a logical clock. The Byzantine node is a node that may intentionally or faultily give wrong information in the REBFT consensus network.

[0050] Step S20: In each node group, the leader node periodically sends heartbeat signals to the follower nodes to maintain its leadership.

[0051] In this embodiment, leader node (Leader Node Of Group): In the REBFT consensus network, the leader of each group elected by the Raft consensus algorithm is responsible for broadcasting the preparation message. Follower node (MemberNode Of Group): In the REBFT consensus network, nodes other than the master node and the leader node participate in the consensus process but do not broadcast to all nodes.

[0052] The node identity change process in the enhanced Byzantine consensus method is as follows: Figure 3The node identity change process includes steps S30 to S50.

[0053] Step S30: If the member node follower does not receive a heartbeat signal sent from the group leader node leader within a preset time period, the member node follower changes its own state to a candidate node candidate and starts a leadership election.

[0054] Step S40: the candidate node candidate broadcasts a campaign message to other nodes in the node group and invites them to vote for themselves.

[0055] Step S50: If the candidate node candidate obtains more than half of the votes before the election times out, it will become the new leader node leader.

[0056] In addition, in step S50, if the candidate node candidate obtains less than half of the votes after the election timeout, the candidate node candidate will continue to broadcast election messages and re-initiate the next round of election.

[0057] like Figure 4 As shown, the consensus process includes a request phase (Request), a pre-preparation phase (Pre-Prepare), a preparation phase (Prepare) and a response phase (Reply).

[0058] In this embodiment, in the request phase: the client node Client sends a transaction request msg to the master node. In the pre-preparation phase: after the master node receives the transaction request msg sent by the client node Client, it broadcasts the pre-preparation message to all nodes.

[0059] In the preparation phase: when a node receives the pre-preparation message broadcast by the master node, it determines whether it is the group leader node. If it is the group leader node, it verifies whether the master node information is correct. When the master node information is verified to be correct, it continues the consensus and puts the pre-preparation message into the temporary storage pool, and then broadcasts the preparation message to other nodes.

[0060] In one embodiment, during the preparation phase, when the verification of the master node information is wrong, the pre-preparation message is not received and the secondary consensus is directly abandoned.

[0061] In another embodiment, during the preparation phase, if the node is not a leader node, the pre-preparation message is placed in a temporary storage pool and the node waits for the preparation message broadcast by the leader node.

[0062] Furthermore, in the response phase: when a node receives a preparation message broadcast by a leader node, it determines whether it is a leader node or a master node. If it is a leader node or a master node, after receiving preparation messages broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool, and then sends a receipt containing a timestamp to the client node Client.

[0063] In one implementation, when a node does not receive preparation information broadcast by more than 2f+1 nodes, the node will continue to wait until it receives preparation information broadcast by more than 2f+1 nodes.

[0064] In the response phase, the method also includes: if it is not a leader node or a master node, after receiving a preparation message broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool.

[0065] In addition, if it is not a group leader node or a master node, when it does not receive a preparation message broadcast by more than 2f+1 nodes, the node will continue to wait until it receives a preparation message broadcast by more than 2f+1 nodes.

[0066] It should be noted that the leader node includes the leader node of the first node group and the leader node of the second node group. The member nodes include the member nodes of the first node group and the member nodes of the second node group.

[0067] In one embodiment, the system has a total of nodes and Byzantine nodes, assuming that the nodes are divided into groups, each group size is , the probability of each node becoming a Byzantine node is , then the number of Byzantine nodes in each group follows the binomial distribution:

[0068] .

[0069] Then the number of Byzantine nodes in the entire system obeys: .

[0070] Therefore, the expectation of f is:

[0071] ;

[0072] The variance of f is:

[0073] ;

[0074] ;

[0075] ;

[0076] ;

[0077] ;

[0078] According to the law of large numbers, f can be approximated as a normal distribution:

[0079] .

[0080] According to the above inference, the probability density surface diagram of the Byzantine node distribution under different probabilities and different numbers of nodes is as follows: Figure 5 shown.

[0081] Compared with the traditional Raft consensus algorithm, which does not have the ability to prevent Byzantine nodes, i.e. nodes from doing evil or dishonest behaviors, the PBFT algorithm has the ability to resist Byzantine nodes. This embodiment combines the relevant processes of the Raft consensus algorithm and the PBFT consensus algorithm, and thus has a certain ability to resist Byzantine attacks.

[0082] Further, it is assumed that there are n nodes in total in this embodiment, which are divided into g groups, and each group has s nodes.

[0083] Total number of communications for the PBFT consensus process:

[0084] The PBFT consensus algorithm consists of three phases: Pre-Prepare, Prepare, and Commit. The specific communication overhead analysis is as follows:

[0085] In the pre-prepare phase, the master node sends pre-prepare messages to the other n−1 nodes, for a total of (n−1) messages.

[0086] In the prepare phase, each node except the master node sends prepare messages to the other n−1 nodes, for a total of (n−1)×(n−1) messages.

[0087] In the confirmation phase, each node sends prepare messages to the other n−1 nodes, for a total of n×(n−1) messages.

[0088] The total communication overhead is:

[0089] .

[0090] Total number of communications in the Raft consensus process: In the traditional Raft consensus algorithm, when the Leader node receives a transaction request, it sends a message to all Follower nodes, the number of communications is (n-1) times, and then the Follower node returns confirmation information to the Leader node, the number of communications is (n-1) times.

[0091] The total communication overhead is:

[0092] .

[0093] 3. Total number of REBFT consensus process communications:

[0094] The REBFT consensus process mainly includes the Raft consensus algorithm to implement group leader election. Each group performs the Raft algorithm separately, so the total number of communications during the Raft consensus phase is:

[0095] .

[0096] Then all nodes participate in the PBFT process, which includes two consensus phases, Pre-Prepare and Prepare. In the Pre-Prepare phase, the master node broadcasts the pre-prepare information to all nodes, and the number of communications in this phase is (n-1). In the Prepare phase, the leader node broadcasts to other nodes, and the number of communications in this phase is g×(n-1). In summary, the number of communications in executing PBFT consensus is:

[0097] .

[0098] The total number of communications for all processes is:

[0099] .

[0100] In this embodiment, the number of REBFT communications is compared with the number of PBFT communications. It can be seen that the event complexity of the REBFT algorithm is Reduced to ,The number of communications of the PBFT algorithm increases exponentially with the increase of the number of nodes, while the number of communications of the REBFT algorithm increases slowly under the same node changes. Therefore, the REBFT algorithm significantly reduces the number of communications in a single consensus compared with the traditional PBFT, and the advantage of REBFT in the number of communications will be more significant when the number of nodes increases. In this embodiment, by grouping nodes and electing group leader nodes, the REBFT algorithm reduces the need for full-node broadcasts, thereby significantly reducing communication overhead. In the traditional PBFT algorithm, each node needs to send messages to all other nodes, while in REBFT, only the group leader node and the master node perform full-node broadcasts, which reduces the number of message transmissions. Experimental verification: After experiments, compared with the traditional PBFT algorithm, REBFT significantly reduces the consensus delay, so that the system can still maintain a low delay in large-scale networks. The experimental results show that REBFT reduces the consensus delay by 82.72% on average, giving it an advantage in high concurrency situations. For example, in a network of 50 nodes, the consensus delay of REBFT is less than 20% of that of PBFT. This shows that in the environment of large-scale node networks, the REBFT algorithm can ensure high consistency while also having significant advantages in communication efficiency.

[0101] The REBFT algorithm reduces the complexity of message passing by optimizing the consensus process, thereby improving the overall throughput of the system. This optimization is particularly evident in large-scale networks, because as the number of nodes increases, the overhead of the traditional PBFT algorithm grows exponentially. Experimental verification: After experiments, compared with traditional PBFT, the throughput of the PBFT algorithm decreases rapidly as the number of nodes increases, while the throughput of the REBFT consensus algorithm is still several times that of PBFT even when a large number of nodes participate in the consensus. For example, in a test environment with 32 nodes, the average throughput of REBFT is 3 times that of PBFT. The above results show that the REBFT algorithm has good throughput when there are more nodes, and is more suitable for distributed networks with higher throughput requirements than the PBFT consensus algorithm.

[0102] The REBFT algorithm takes the existence of Byzantine nodes into consideration when designing it. Through an improved consensus mechanism, the stability and consistency of the system can be maintained even in the presence of malicious nodes. Experimental verification: Under different Byzantine node probabilities, the REBFT algorithm shows better performance than the PBFT algorithm. In a 24-node network with a high Byzantine node probability, the throughput of the REBFT algorithm is more than ten times that of PBFT under the same conditions, and the consensus delay is only 15% of that of PBFT.

[0103] In response to many challenges in the PBFT consensus algorithm, such as high communication overhead, high time complexity, and insufficient scalability, this embodiment proposes a new consensus algorithm, REBFT, which combines the PBFT consensus algorithm with the Raft consensus algorithm. This method combines the low time complexity of the Raft algorithm while retaining the PBFT full-node broadcast mechanism, and significantly improves the consensus efficiency while ensuring system consistency, security, and anti-Byzantine node capabilities. REBFT optimizes PBFT by reducing unnecessary consensus steps and reducing the number of global broadcast nodes, thereby achieving significant improvements in consensus performance and communication overhead. Experimental results show that REBFT has significantly improved consensus latency and throughput compared to traditional PBFT, especially in large-scale network scenarios where Byzantine nodes may exist, REBFT exhibits superior performance.

[0104] Specifically, when the system starts or needs to be regrouped, the master node will first determine the surviving nodes in the entire system and then randomly group the nodes, while ensuring that the number of nodes in each node group is the same, and then use the Raft consensus algorithm to select a leader for each node group. All nodes will participate in the improved PBFT consensus, but only the master node and the leader node can broadcast, and other replica nodes will only receive messages from the master node and complete the consensus after verification. This reduces the number of nodes participating in the global broadcast while the number of nodes participating in the consensus does not change, which reduces communication overhead and ensures consistency between system nodes.

[0105] This embodiment cancels the confirmation (commit) phase of PBFT. This is because in the preparation phase, the nodes have verified each other and confirmed the validity of the proposal, and have actually reached a consensus. Although the re-broadcast and confirmation in the confirmation phase increases the reliability of the system, it also brings additional communication overhead and delay. Therefore, the REBFT algorithm cancels the full network broadcast in the confirmation phase and simplifies the original three-stage consensus process into two stages, that is, only retaining the pre-preparation and preparation phases. In this way, the number of message transmissions is greatly reduced, and the communication complexity is reduced from the original O(n²) to a lower level. After canceling the commit phase, the optimized PBFT consensus algorithm process is as follows: Figure 6 shown.

[0106] When the system starts, the master node will first determine the surviving nodes in the entire system and then randomly group the nodes, while ensuring that the number of nodes in each node group is the same, and then use the Raft consensus algorithm to select a leader for each node group. Only the master node and the leader node can broadcast. This is to reduce the number of nodes participating in the broadcast, thereby reducing the number of system communications and improving the overall performance of the system. At the same time, all nodes will participate in the PBFT consensus algorithm to maximize the consistency and reliability of the system. The Raft algorithm has the advantages of high consistency and low time complexity. Since its time complexity is O(n), it is used to complete the election of the leader, and then the leader node is allowed to participate in the global broadcast in the PBFT algorithm, which significantly reduces the number of nodes participating in the global broadcast and reduces the overall complexity of the algorithm. At the same time, since only the leader node and the master node participate in the broadcast, when there are Byzantine nodes in the system, as long as the leader node does not become a Byzantine node, it will not affect the consensus performance of the system. This improves the reliability of the system under an insecure network and significantly improves the robustness and security of the system.

[0107] Example 2

[0108] An embodiment of the present invention also provides an enhanced Byzantine consensus device in a distributed system, which may include an initialization process module and a consensus process module.

[0109] The initialization process module includes: a grouping unit, a heartbeat signal unit, a state transition unit, a broadcast election unit and a group leader node unit.

[0110] The grouping unit is used to group all nodes in the network, and number the master node as N0, and the replica nodes as Ni, where the value of i is [1, N], N is the number of replica nodes, and the N replica nodes are randomly and evenly divided into G node groups, G=3f+1, and f is the number of Byzantine nodes.

[0111] The heartbeat signal unit is used for the leader node in each node group to periodically send heartbeat signals to the follower nodes in the group to maintain its leadership position.

[0112] The state transition unit is used to change the state of the member node follower to a candidate node candidate and start leadership election if the member node follower does not receive a heartbeat signal sent from the group leader node leader within a preset time period.

[0113] The broadcast campaign unit is used for the candidate node candidate to broadcast campaign messages to other nodes in the node group and invite them to vote for themselves.

[0114] The group leader node unit is used to become the new group leader node leader if the candidate node candidate obtains more than half of the votes before the election times out.

[0115] The consensus process module includes: a request unit, a pre-preparation phase unit, a preparation unit and a response unit.

[0116] The request unit is used for the client node Client to send a transaction request msg to the master node;

[0117] The pre-preparation phase unit is used to broadcast the pre-preparation message to all nodes after the master node receives the transaction request msg sent by the client node Client;

[0118] The preparation unit is used to determine whether the node is a leader node after receiving the pre-preparation message broadcast by the master node. If it is a leader node, verify whether the master node information is correct. When the master node information is verified to be correct, continue the consensus and put the pre-preparation message into a temporary storage pool, and then broadcast the preparation message to other nodes;

[0119] The response unit is used to determine whether the node is a leader node or a master node after receiving a preparation message broadcast by the leader node. If it is a leader node or a master node, after receiving preparation messages broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool, and then sends a receipt containing a timestamp to the client node Client.

[0120] In detail, each module of the enhanced Byzantine consensus device in the distributed system provided in the embodiment of the present invention adopts the same technical means as the enhanced Byzantine consensus method in the distributed system provided in the above-mentioned embodiment 1 when in use, and can produce the same technical effects, which will not be repeated here.

[0121] Example 3

[0122] An embodiment of the present invention further provides a storage medium, on which a computer program is stored. When the computer program is executed by a processor, the processor executes the steps of the method described in Example 1.

[0123] The storage medium is a readable storage medium, which may include a flash memory, a mobile hard disk, a multimedia card, a card-type memory (eg, an SD or DX memory, etc.), a magnetic memory, a disk, an optical disk, etc.

[0124] In summary, when the network system of the embodiment of the present invention is started or needs to be regrouped, the master node will first determine the surviving nodes in the entire network system and randomly group the nodes, while ensuring that the number of nodes in each node group is the same, and then use the Raft consensus algorithm to select a leader for each node group. All nodes will participate in the improved PBFT consensus, but only the master node and the leader node can broadcast, and other replica nodes will only receive messages from the master node and complete the consensus after verification. By combining the Raft algorithm with the verification phase of PBFT, the leader node can quickly initiate and reach a consensus. Since the number of nodes participating in the global broadcast is reduced while the number of nodes participating in the consensus does not change, the number of message transmission rounds in the network is significantly reduced, communication delays and communication overhead are reduced, and consistency between network system nodes is ensured.

[0125] The embodiment of the present invention optimizes the PBFT algorithm to obtain the Enhanced Byzantine Fault Tolerant Consensus (REBFT) algorithm, cancels the full network broadcast in the confirmation phase, and simplifies the original three-stage consensus process into two stages, that is, only retains the pre-preparation and preparation stages. Therefore, the number of message transmissions is greatly reduced, and the communication complexity is also reduced to a lower level. By reducing unnecessary consensus steps and reducing the number of global broadcast nodes, by optimizing the consensus process to reduce the number of communications and introducing the design of node groups, a significant improvement in consensus performance and communication overhead is achieved, especially in the presence of a large number of nodes, the throughput of the system can be significantly improved, ensuring that efficient data processing capabilities can be maintained under high load conditions.

[0126] The REBFT algorithm in the embodiment of the present invention retains the anti-Byzantine characteristics of the PBFT algorithm, can handle attacks from malicious nodes or abnormal nodes, and ensure the consistency and security of the system. At the same time, unlike the PBFT algorithm, as long as any node becomes a Byzantine node, it will affect the system. Since only the group leader and the master node have the ability to broadcast globally, it means that as long as the group leader node does not become a Byzantine node, it will not affect the consensus performance of the system, effectively reducing the impact of the Byzantine node on the system, significantly improving the reliability of the system and the ability to resist Byzantine nodes, improving the reliability of the system in an insecure network, and significantly improving the robustness and security of the system.

[0127] In the embodiments provided by the present invention, it should be understood that the disclosed equipment, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division, and there may be other division methods in actual implementation. The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, the functional modules in the various embodiments of the present invention may be integrated in a processing unit, or each unit may exist physically separately, or two or more units may be integrated in one unit. The above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional modules.

[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. An enhanced Byzantine consensus method in a distributed system, characterized in that: Including initialization process and consensus process, the initialization process includes the following steps: S10: Group all nodes in the network, and number the master node as N0, and the replica nodes as Ni, where i is [1, N], N is the number of replica nodes, and the N replica nodes are randomly and evenly divided into G node groups, G=3f+1, and f is the number of Byzantine nodes; S20: In each node group, the leader node periodically sends heartbeat signals to the follower nodes to maintain its leadership position; S30: If the member node follower does not receive a heartbeat signal sent from the leader node leader within a preset time period, the member node follower changes its own state to a candidate node candidate and starts a leader election; S40: the candidate node candidate broadcasts a campaign message to other nodes in the node group and invites them to vote for themselves; S50: If the candidate node obtains more than half of the votes before the election timeout, it will become the new leader node leader; The consensus process includes a request phase, a pre-preparation phase, a preparation phase, and a response phase; In the request phase: the client node Client sends a transaction request msg to the master node; In the pre-preparation stage: after receiving the transaction request msg sent by the client node Client, the master node broadcasts the pre-preparation message to all nodes; In the preparation phase: after receiving the pre-preparation message broadcast by the master node, the node determines whether it is the leader node. If it is the leader node, it verifies whether the master node information is correct. When the master node information is verified to be correct, it continues the consensus and puts the pre-preparation message into the temporary storage pool, and then broadcasts the preparation message to other nodes; In the response phase: when a node receives the prepare message broadcast by the leader node, it determines whether it is the leader node or the master node. If it is the leader node or the master node, after receiving the prepare message broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool, and then sends a receipt containing a timestamp to the client node Client.

2. The enhanced Byzantine consensus method in a distributed system according to claim 1, characterized in that: In step S50, if the candidate node candidate obtains less than half of the votes after the election timeout, the candidate node candidate will continue to broadcast election messages and re-initiate the next round of election.

3. The enhanced Byzantine consensus method in a distributed system according to claim 1, characterized in that: The method also includes: in the preparation stage, when the verification of the master node information is wrong, the pre-preparation message is not received and the consensus is directly abandoned.

4. The enhanced Byzantine consensus method in a distributed system according to claim 1, characterized in that: The method further comprises: in the preparation phase, if the node is not a group leader node, placing a pre-preparation message into a temporary storage pool, and waiting for a preparation message broadcast by the group leader node.

5. The enhanced Byzantine consensus method in a distributed system according to claim 1, characterized in that: The method further includes: in the response phase, when the node does not receive the preparation information broadcast by more than 2f+1 nodes, the node will continue to wait until it receives the preparation information broadcast by more than 2f+1 nodes.

6. The enhanced Byzantine consensus method in a distributed system according to claim 1, characterized in that: The method also includes: if it is not a group leader node or a master node, after receiving the preparation message broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool.

7. The enhanced Byzantine consensus method in a distributed system according to claim 6, characterized in that: The method further includes: if it is not a group leader node or a master node, when no preparation message broadcast by more than 2f+1 nodes is received, the node will continue to wait until it receives preparation information broadcast by more than 2f+1 nodes.

8. An enhanced Byzantine consensus device in a distributed system, characterized in that: Includes initialization process module and consensus process module; The initialization process module includes: The grouping unit is used to group all nodes in the network and number the master node as N0 and the replica nodes as Ni. The value of i is [1, N], where N is the number of replica nodes. The N replica nodes are randomly and evenly divided into G node groups, where G=3f+1 and f is the number of Byzantine nodes. The heartbeat signal unit is used to periodically send heartbeat signals to the follower nodes in each node group to maintain its leadership position. A state transition unit, configured to, if the member node follower does not receive a heartbeat signal sent from the group leader node within a preset time period, change its own state to a candidate node candidate and start leader election; The broadcast campaign unit is used by the candidate node candidate to broadcast campaign messages to other nodes in the node group and invite them to vote for themselves; The leader node unit is used to become the new leader node leader if the candidate node obtains more than half of the votes before the election timeout; The consensus process module includes: Request unit, used for the client node Client to send a transaction request msg to the master node; The pre-preparation phase unit is used to broadcast the pre-preparation message to all nodes after the master node receives the transaction request msg sent by the client node Client; The preparation unit is used to determine whether it is the leader node after receiving the pre-preparation message broadcast by the master node. If it is the leader node, it verifies whether the master node information is correct. When the master node information is verified to be correct, it continues the consensus and puts the pre-preparation message into the temporary storage pool, and then broadcasts the preparation message to other nodes; The response unit is used to determine whether it is a leader node or a master node after receiving a prepare message broadcast by the leader node. If it is a leader node or a master node, after receiving prepare messages broadcast by more than 2f+1 nodes, the node determines that the consensus is valid and stores it in the local storage pool, and then sends a receipt containing a timestamp to the client node Client.

9. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor executes the steps of the enhanced Byzantine consensus method as described in any one of claims 1 to 7.

Images