Byzantine Fault Tolerant Consensus Method, Device and Medium Based on Node Behavior Analysis

Abstract

The present invention provides a Byzantine fault tolerance consensus method, device and medium based on node behavior analysis, which relates to the technical field of Byzantine fault tolerance consensus. The method includes: based on node behavior analysis, first evaluating the behavior of nodes and introducing weights, and then dividing the nodes into different groups according to their weights; during the consensus process, the primary node is selected from the first node group with higher performance, so as to increase the probability of excellent nodes being selected as the primary node; in each stage, different node groups are designated to be responsible for specific tasks; the present invention optimizes the consensus process, reduces network overhead, improves system throughput and reduces the delay of the consensus process, thereby improving the overall performance of the system.

Description

Technical Field

[0001] The present invention relates to the technical field of Byzantine fault tolerance consensus, and particularly to a Byzantine fault tolerance consensus method, device and medium based on node behavior analysis. Background Art

[0002] With the wide application of blockchain technology, the Practical Byzantine Fault Tolerance (PBFT) algorithm, as a classic consensus mechanism, has received attention due to its advantages in tolerating Byzantine faults. In the traditional implementation of the PBFT algorithm, the decentralization process is achieved by randomly selecting a primary node. In this process, each node has the opportunity to act as the primary node in the new view number. The key responsibility of the primary node is to receive requests from clients, assign sequence numbers to them, create pre-prepared information, and then broadcast this information to all replica nodes. Nevertheless, since the selection of the primary node is carried out in a fixed order, there is a possibility that a Byzantine node may be selected as the next primary node. If a Byzantine node knows the sequence of node rotation, it may launch a denial-of-service attack on neighboring nodes that are about to become the primary node, resulting in frequent view changes. Regardless of how a Byzantine node becomes the primary node, it will trigger the view replacement mechanism, which not only increases the network pressure, reduces the system's processing capacity, but also increases the latency of the consensus process, thus having a negative impact on the overall performance of the system. Summary of the Invention

[0003] In view of the above technical problems, the technical solution adopted by the present invention is as follows:

[0004] According to the first aspect of the present application, a Byzantine fault tolerance consensus method based on node behavior analysis is provided. The method includes the following steps:

[0005] S100, obtaining a plurality of parameters corresponding to each node on a target blockchain to obtain a node parameter list set B = (B1, B2,..., B i ,..., B n ), where i = 1, 2,..., N; among them, B i is the node parameter list corresponding to the ith node on the target blockchain, and N is the number of nodes on the target blockchain; B i = (L i , A i , U i , MDSR i ); L i is the node response time corresponding to the ith node, A i is the correct response rate corresponding to the ith node, U i is the node availability corresponding to the ith node, and MDSR i is the message transmission success rate corresponding to the ith node;

[0006] S200. Determine the weight corresponding to each node according to B to obtain the weight list S=(S1, S2, …, S i , …, S n ); where S i is the weight corresponding to A i ; S i =ω1×L i +ω2×A i +ω3×U i +ω4×MDSR i ; ω1 is the first preset weight, ω2 is the second preset weight, ω3 is the third preset weight, ω4 is the fourth preset weight; ω1 + ω2 + ω3 + ω4 = 1;

[0007] S300. Traverse S. If S i ≥λ1, then add S i to the preset first node group; where λ1 is the first preset weight threshold;

[0008] S400. If λ2 ≤ S i <λ1, then add S i to the preset second node group; where λ2 is the second preset weight threshold; λ1 and λ2 are determined according to S;

[0009] S500. If S i <λ2, then add S i to the preset third node group;

[0010] S600. Determine the node with the largest weight in the first node group as the main node;

[0011] S700. Execute the preset fault-tolerant consensus step.

[0012] According to another aspect of the present application, there is also provided a non-transitory computer-readable storage medium, in which at least one instruction or at least one program segment is stored, and at least one instruction or at least one program segment is loaded and executed by a processor to implement the above-mentioned Byzantine fault-tolerant consensus method based on node behavior analysis.

[0013] According to another aspect of the present application, there is also provided an electronic device, including a processor and the above-mentioned non-transitory computer-readable storage medium.

[0014] The present invention has at least the following beneficial effects:

[0015] The Byzantine fault-tolerant consensus method based on node behavior analysis of the present invention, based on node behavior analysis, first evaluates the behavior of nodes and introduces weights, and then divides them into different groups according to the weights of the nodes; during the consensus process, the primary node is selected from the first node group with higher performance, which can increase the probability of excellent nodes being selected as the primary node; different node groups are specified to be responsible for specific tasks in each stage, thereby optimizing the consensus process, reducing network overhead, increasing system throughput, and reducing the delay of the consensus process, and further improving the overall performance of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0017] Figure 1 It is a flowchart of the Byzantine fault-tolerant consensus method based on node behavior analysis provided by the embodiment of the present invention;

[0018] Figure 2 It is a schematic diagram of the algorithm consensus process provided by the embodiment of the present invention;

[0019] Figure 3 It is a comparison chart of the consensus algorithm delay provided by the embodiment of the present invention;

[0020] Figure 4 It is a comparison chart of the consensus algorithm throughput provided by the embodiment of the present invention;

[0021] Figure 5 It is a comparison chart of the consensus algorithm traffic provided by the embodiment of the present invention;

[0022] Figure 6 It is a schematic diagram of the influence of the consensus speed of different grouped nodes on the node performance provided by the embodiment of the present invention;

[0023] Figure 7 It is a schematic diagram of the influence of the consensus efficiency of different grouped nodes on the node performance provided by the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0024] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0025] It should be noted that based on the present disclosure, those skilled in the art should understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement the device and / or practice the method. In addition, this device can be implemented and this method can be practiced using other structures and / or functions in addition to one or more of the aspects described herein.

[0026] Next, reference will be made to Figure 1 the flowchart of the Byzantine fault tolerance consensus method based on node behavior analysis shown in the figure to introduce a Byzantine fault tolerance consensus method based on node behavior analysis.

[0027] The Byzantine fault tolerance consensus method based on node behavior analysis may include the following steps:

[0028] S100, obtaining a number of parameters corresponding to each node on the target blockchain to obtain a node parameter list set B = (B1, B2,..., B i ,..., B n ), where i = 1, 2,..., N; among them, B i is the node parameter list corresponding to the i-th node on the target blockchain, and N is the number of nodes on the target blockchain; B i = (L i , A i , U i , MDSR i ); L i is the node response time corresponding to the i-th node, A i is the correct response rate corresponding to the i-th node, U i is the node availability corresponding to the i-th node, and MDSR i is the message transmission success rate corresponding to the i-th node.

[0029] In this embodiment, based on node behavior analysis. The method first evaluates the behavior of the nodes and introduces a performance factor, and then divides the nodes into a first node group, that is, the high-performance group (High Performance Group, HPG), a second node group, that is, the medium-performance group (Medium Performance Group, MPG), and a third node group, that is, the low-performance group (Low Performance Group, LPG) according to the performance of the nodes. During the consensus process, the primary node is selected from the HPG node group, which can increase the probability of excellent nodes being selected as the primary node. Different node groups are specified to be responsible for specific tasks in each stage, thus optimizing the consensus process.

[0030] Furthermore, Li Determined by the following steps:

[0031] S110. Obtain the start time of the i-th node in the j-th consensus End time And the preset timeout

[0032] S111. According to And Determine where j = 1, 2, …, n; n is the number of consensus times.

[0033] In this embodiment, the node response time (Latency) is a key indicator to measure the time used by the node from receiving a request to returning a response. The score is calculated based on the average response time of the node in multiple consensus rounds. The specific formula is the ratio of the response time of each consensus round to the preset timeout. The shorter the response time, the higher the score of the node. Conversely, if the response time is close to or exceeds the timeout, the score will decrease. This scoring mechanism ensures the reaction speed of the node when participating in the consensus, reduces the overall system latency, and guarantees the timeliness and efficiency of the consensus process. The expression formula of the node response time (Latency) is as follows.

[0034]

[0035] In the formula: L i Is the average response time score of the i-th node, Is the start time of node i in the j-th consensus, Is the end time, Is the preset timeout, and n is the number of consensus times.

[0036] The response time is an important indicator of the node's performance. A too long response time may lead to an increase in the overall system latency, so the weight of this indicator is relatively high.

[0037] Furthermore, A i Can be determined by the following steps:

[0038] S120. Obtain the number of correct responses M of the i-th node in all consensus i , the total number of times N participating in the consensus i , the time weight number α j , and the correct response rate A in the j-th time period ij .

[0039] S121. According to M i , N i , α j And A ij , determine k is the number of time periods considered.

[0040] In this embodiment, the accuracy is an indicator for evaluating the response correctness of a node during the consensus process. It is scored by calculating the proportion of the number of correct responses of a node in all rounds of participation in the consensus to the total number of participations. A adjustment coefficient based on historical performance can be introduced into the scoring, taking into account the performance differences of the node in different time periods. In addition, the performance of the node in the recent several consensuses can be introduced as a weighting factor, so that nodes with better recent performance can obtain higher scores. This indicator aims to ensure that nodes make decisions that conform to the protocol specifications during the consensus process, thereby maintaining the security and consistency of the entire system. The expression formula of the accuracy is as follows.

[0041]

[0042] In the formula: A i is the comprehensive accuracy score of the i-th node, M i is the number of correct responses of the node in all consensuses, N i is the total number of participations in the consensus. α j is the time weight number, used to adjust the performance of the node in different time periods. The weight of the recent performance is higher, and the weight of the earlier performance is lower. A ij is the accuracy of the i-th node in the j-th time period, and k is the number of time periods considered.

[0043] Accuracy directly affects the correctness of the consensus. Incorrect responses will weaken the security of the system. Therefore, the weight of this indicator is also very high.

[0044] Furthermore, U i can be determined through the following steps:

[0045] S130, obtain the running time Uptime of the i-th node i , the total time Totaltime during the observation period i , the recovery time R after the l-th failure il , the weight β of the failure recovery time l and the historical failure times F i .

[0046] S131, according to Uptime i , Totaltime i , R il , β l and F i , determine γ is the penalty coefficient for the number of failures.

[0047] In this embodiment, node availability, that is, the node availability rate, is used to measure the running state of a node within a specific observation period, that is, the proportion of time the node remains online during the time it is expected to be online. The scoring can incorporate the recovery speed of the node and its historical failure records. By introducing the recovery time after a node fails and a penalty term for the historical number of failures, nodes that frequently fail or have a long recovery time will have a lower score. This metric reflects the stability and reliability of the node, ensuring that during the consensus process, the node can continuously provide services without affecting the normal operation of the system due to frequent offline or failures. The expression formula for node availability (Availability) is as follows.

[0048]

[0049] In the formula: U i is the availability score of the i-th node, Uptime i is the running time of node i, Totaltime i is the total time within the observation period. R il is the recovery time of node i after the l-th failure, β l is the weight of the failure recovery time, F i is the historical number of failures of node i. is the penalty coefficient based on the recovery time. The longer the recovery time or the more the number of failures, the smaller this value. γ is the penalty coefficient for the number of failures. The more the number of failures, the larger this value.

[0050] The availability of nodes affects the stability and fault tolerance of the system. However, since the system allows some nodes to fail, the weight of this metric is relatively low.

[0051] Furthermore, MDSR i can be determined through the following steps:

[0052] S140. Obtain the number of times Pi that the i-th node successfully transmits messages, i the total number of message transmission attempts Q, i the message transmission delay penalty coefficient δ, the actual bandwidth utilization BW i and the maximum bandwidth utilization BW max .

[0053] S141. According to Pi, i Q, i δ, BW i and BW max , determine D imis the delay of the i-th node in the m-th transmission, where m = 1, 2, …, q.

[0054] In this embodiment, the Message Delivery Success Rate evaluates the ability of a node to successfully send and receive messages during the consensus process. The scoring can consider the delay of message transmission, bandwidth utilization, and the impact of network topology on message transmission. By introducing these factors, nodes with low transmission efficiency and poor bandwidth utilization will receive lower scores. This metric ensures that nodes have good communication capabilities in the network environment, thus guaranteeing the smooth transmission of consensus information among nodes and reducing the risk of consensus failure or delay caused by communication failures. The expression formula of the Message Delivery Success Rate is as follows.

[0055]

[0056] In the formula: MDSR i is the message delivery success rate score of the i-th node, P i is the number of times the node successfully transmits messages, Q i is the total number of message transmission attempts. δ is the message transmission delay penalty coefficient, is the average delay of node i in q transmissions. The greater the delay, the greater the penalty. BW i is the actual bandwidth utilization of the node, BW max is the maximum bandwidth utilization. The higher the utilization, the higher the score.

[0057] The success rate of message transmission is a basic requirement to ensure the smooth progress of the consensus process. However, considering the importance of other metrics, the weight of this metric is relatively low.

[0058] S200. Determine the weight corresponding to each node according to B to obtain the weight list S = (S1, S2, …, S i , …, S n ) corresponding to B; where S i is the weight corresponding to A i ; S i = ω1 × L i + ω2 × A i + ω3 × U i + ω4 × MDSR i ; ω1 is the first preset weight, ω2 is the second preset weight, ω3 is the third preset weight, ω4 is the fourth preset weight; ω1 + ω2 + ω3 + ω4 = 1.

[0059] In this embodiment, the evaluation of node performance, that is, the weight of the node, is based on four specific metrics: node response time (Latency), correct response rate (Accuracy), node availability (Availability), and message delivery success rate (Message Delivery Success Rate). Different weight values are set for each metric to determine the importance of different metrics. According to the weights and scores of each metric, they are weighted and summed to obtain the final node performance. In this embodiment, node availability is the node availability rate. The description of node-related performance evaluation metrics is shown in Table 1.

[0060] Table 1

[0061]

[0062] Since response time and correct response rate are crucial for ensuring system efficiency and correctness, they occupy relatively high weights. Although node availability and message delivery success rate are important, considering that the PBFT algorithm itself has a certain fault tolerance ability, their weights are relatively low. Therefore, the weight of the node response time score is assigned as 40%, the weight of the correct response rate score is 35%, the weight of the availability score is 15%, and the weight of the message delivery success rate score is 10%; that is, ω1 = 0.4, ω2 = 0.35, ω3 = 0.15, ω4 = 0.1.

[0063] Furthermore, assume that there are N nodes in the network. By quantifying the four metrics of node response time, correct response rate, availability, and message delivery success rate, the performance S of the node is obtained. i . Then, the voting weight V of the i-th node is calculated according to the following formula. i .

[0064]

[0065] Among them, V i is the voting weight of node i, and S i represents the performance of the behavior analysis node. n is the number of all nodes participating in the formula, and α is an adjustment coefficient. By adjusting the value of α, the distribution of the voting weight can be controlled. If α = 1, the score of the node linearly affects the voting weight; if α > 1, nodes with higher scores will obtain higher weights, while the weights of nodes with lower scores will be further reduced. The total voting weight is set to 100%, which ensures that the distribution of the voting weight is more intuitive and easy to understand. Algorithm 1 is the calculation process of the node voting weight.

[0066]

[0067]

[0068] S300, traverse S, if S i ≥λ1, then add S i to the preset first node group; where λ1 is the first preset weight threshold.

[0069] S400, if λ2≤S i <λ1, then add S i to the preset second node group; where λ2 is the second preset weight threshold; λ1 and λ2 are determined according to S.

[0070] S500, if S i <λ2, then add S i to the preset third node group.

[0071] Furthermore, λ1 and λ2 are determined through the following steps:

[0072] S410, obtain the average weight and weight volatility

[0073] S420, according to μ and σ, determine λ1 = μ + σ and λ2 = μ - σ.

[0074] In this embodiment, according to the performance of the nodes, the nodes are divided into three different groups, namely the first node group, the second node group and the third node group, corresponding to the high-performance group (HPG), the medium-performance group (MPG) and the low-performance group (LPG) in sequence. When grouping the nodes, we first calculate the performance S i mean μ and standard deviation σ of all nodes to determine the overall distribution characteristics of the node performance. N is the total number of nodes, and the formula is as follows.

[0075]

[0076] Based on the above statistics, we divide the nodes into three main groups: the High Performance Group (HPG), the Medium Performance Group (MPG), and the Low Performance Group (LPG). Specifically, nodes with a performance higher than the mean plus one standard deviation are classified into the high-performance group. These nodes perform excellently in the consensus process, can undertake the main voting tasks, and ensure the accuracy and efficiency of the consensus. Nodes with a performance between the mean minus one standard deviation and the mean plus one standard deviation are classified into the medium-performance group. These nodes' performance is close to the average level and are suitable for undertaking regular consensus tasks, providing necessary support and redundancy. Nodes with a performance lower than the mean minus one standard deviation are classified into the low-performance group. Due to their poor performance, these nodes may have a negative impact on the consensus process. Therefore, their role in key decisions should be restricted, and their voting weight should be reduced. Through this grouping method based on the mean and standard deviation, we can scientifically classify the nodes to optimize the consensus process, improve the system efficiency and stability, and ensure the overall security of the system. Specifically, as shown in Algorithm 2:

[0077]

[0078]

[0079] S600, determine the node with the largest weight in the first node group as the primary node.

[0080] In this embodiment, the primary node is selected from the High Performance Group (HPG). Since the nodes in the HPG group are significantly superior to other groups in terms of processing capacity, response time, correct response rate, and message transmission success rate, selecting a node from the HPG group as the primary node can make full use of its performance advantages. This can ensure that the primary node has higher efficiency and reliability in coordinating the consensus process and processing requests, thus accelerating the speed of consensus reaching and improving its accuracy. This selection mechanism helps to optimize the overall performance of the system.

[0081] In addition, to improve the robustness and flexibility of the system, a dynamic rotation mechanism is introduced in this embodiment. If the current primary node shows abnormal performance or becomes unavailable during operation, the system can quickly select the next excellent-performing node from the HPG group to replace the existing primary node. The dynamic adjustment mechanism not only ensures the stability of the primary node but also reduces the possible impact of a single node failure on the system consensus process. Through this mechanism, the system can maintain continuous high efficiency and robustness during operation.

[0082] To avoid the long-term centralization of the primary node and the potential risks it brings, the method in this embodiment also implements a rotation strategy for the primary node. At set time intervals or when specific events are triggered, the system selects different nodes from the HPG group as the new primary node. This strategy can effectively disperse the responsibilities of the primary node, reduce the likelihood of a certain node being attacked or failing, and enhance the system's anti-attack ability and overall reliability. Through the rotation mechanism, the method in this embodiment maintains the original decentralized design concept and avoids the risks of centralization.

[0083] S700, execute the preset fault-tolerant consensus steps.

[0084] Further, step S700 includes the following steps:

[0085] S710, in the Request phase, the primary node obtains the client's request and generates a REQUEST message REQ = <m, t, c, σ_c, extra>; where m is the request content, t is the timestamp, c is the client ID, σ_c is the client signature, and extra is the additional data.

[0086] S720, in the Pre-Prepare phase, the primary node generates a PRE-PREPARE message corresponding to the REQ and broadcasts the PRE-PREPARE message to other nodes within the first node group and each node within the second node group.

[0087] S730, in the Prepare phase, after each node within the second node group receives the PRE-PREPARE message, it verifies the PRE-PREPARE message, generates a PREPARE message, and broadcasts the PREPARE message to each node within the first node group, the second node group, and the third node group.

[0088] S740, in the Commit phase, after the nodes within the third node group receive the PREPARE message, they verify the PREPARE message, generate a COMMIT message, and broadcast the COMMIT message to all nodes.

[0089] S750, in the Reply phase, the proposed result reached through consensus is responsible for sending an acknowledgement reply to the client by the nodes within the first node group.

[0090] The method in this embodiment introduces a node performance grouping mechanism in the consensus process, significantly improving the efficiency and performance of the system compared to the traditional PBFT algorithm. In traditional PBFT, all nodes participate in the generation and propagation of messages in each stage, resulting in high communication overhead and processing latency. The method in this embodiment optimizes the consensus process by dividing nodes into a High-Performance Group (HPG), a Medium-Performance Group (MPG), and a Low-Performance Group (LPG), and designating different node groups to be responsible for specific tasks in each stage. In the Request stage, the fast processing ability of HPG nodes reduces the latency of request generation and broadcasting. In the Pre-Prepare stage, HPG nodes generate proposals and improve the efficiency of proposal verification and transmission through the digest tree technology. The Prepare stage is responsible for MPG nodes, reducing the communication burden and accelerating the verification process through the partial threshold signature technology. In the Commit stage, LPG nodes are responsible for the final confirmation, reducing the burden on high-performance nodes and enhancing the fault tolerance of the system. Finally, in the Reply stage, HPG nodes quickly respond to client requests, improving the response speed and throughput of the system. Generally speaking, the method in this embodiment not only reduces the communication overhead and processing latency of the system through node grouping and hierarchical processing, but also enhances the adaptability and stability of the system under different performance conditions, significantly optimizing the performance of the traditional PBFT algorithm. The schematic diagram of the consensus process of the method in this embodiment is as Figure 2 shown.

[0091] The step process of the consensus algorithm of this embodiment is as follows:

[0092] Request stage: The client issues a request and sends it to the High-Performance Group (HPG) nodes in the network. Due to their high computing and network processing capabilities, HPG nodes are selected as the primary node, responsible for processing the client's request and generating a REQUEST message in the format of REQ = <m, t, c, σ_c, extra>, where m is the request content, t is the timestamp, c is the client ID, σ_c is the client signature, and extra is the additional data. After receiving the request, the primary node uses it as the basis for the proposal, generates a message containing the request, and prepares to enter the Pre-Prepare stage. Compared with traditional PBFT, ABA-PBFT reduces the processing latency and optimizes the initial proposal generation process by directly routing the request to high-performance nodes.

[0093] Pre-Prepare Phase: In the Pre-Prepare phase, the primary node of the HPG group is responsible for generating a proposal message and broadcasting it to other HPG nodes and Medium-Performance Group (MPG) nodes. HPG nodes first reach a preliminary consensus within themselves through an efficient internal communication protocol and are responsible for generating and broadcasting PRE-PREPARE messages in this phase. The message format is PRE-PREPARE = <v, n, d, σ_p, group, digest_tree>, where v is the view number, n is the sequence number, d is the digest of the request content, σ_p is the signature of the primary node, group identifies the node group (HPG), and digest_tree is the digest tree of the proposal. Due to the superior performance of HPG nodes, this phase can be completed quickly, significantly reducing the proposal generation time and network latency. After receiving the proposal, MPG nodes start to prepare for the verification work in the next phase. Different from the traditional PBFT where all nodes participate, ABA-PBFT centralizes the proposal generation and broadcasting to high-performance nodes, thus reducing the initial latency.

[0094] Prepare Phase: The Prepare phase is mainly responsible by MPG nodes. After receiving the PRE-PREPARE message broadcast from the HPG group, MPG nodes will verify it to ensure the correctness and consistency of the proposal. Each MPG node will independently check the proposal and generate and broadcast the corresponding PREPARE message. The message format is PREPARE = <v, n, d, i, σ_i, group>. Where i is the replica node ID, σ_i is the signature of the replica node, and group identifies the node group (MPG). These PREPARE messages will be broadcast to all MPG nodes as well as HPG and LPG nodes. Different from the traditional PBFT where all nodes participate, ABA-PBFT utilizes MPG nodes for efficient verification. MPG nodes can quickly reach a preliminary consensus while reducing the communication burden, improving the efficiency of the Prepare phase and laying the foundation for the next confirmation phase of the system.

[0095] Commit Phase: Nodes in the Low-Performance Group (LPG) start participating in consensus in this phase and assume the responsibility of finalizing the proposal. After receiving the PREPARE message from the MPG nodes, the LPG nodes will conduct secondary verification and generate and broadcast a COMMIT message in the format COMMIT = <v, n, d, i, σ_i, group>, where group identifies the node group (LPG). The intervention of LPG nodes ensures the final consistency and security of the proposal, which is particularly important when dealing with nodes with uneven performance. The COMMIT message is broadcast to all nodes, and the system can confirm that the proposal has been agreed upon after receiving sufficient COMMIT messages. Compared with the traditional PBFT where all nodes participate, ABA-PBFT reduces the burden on high-performance nodes by assigning the final confirmation task to low-performance nodes.

[0096] Reply Phase: The HPG nodes are responsible for sending confirmation replies to the clients for the proposal results reached through consensus. The message format is REPLY = <r, c, σ_r>, where r is the execution result of the client request and σ_r is the signature of the node for the execution result. Due to the high performance and low latency of the HPG nodes, the clients can quickly receive the final consensus results. The design of this phase ensures that the client requests are responded to quickly, and the throughput of the system is also improved. The sending of the REPLY message marks the end of this round of consensus process, and the system is ready to receive and process new client requests.

[0097] In summary, the algorithm of this embodiment demonstrates significant advantages in optimizing each stage of the consensus process by introducing a node-performance-based grouping mechanism. Compared with traditional PBFT, in the Request phase, the High-Performance Group (HPG) quickly processes requests; in the Pre-Prepare phase, the proposal digest tree is used to improve data transmission and verification efficiency; in the Prepare phase, the Medium-Performance Group (MPG) nodes participate in efficient verification, reducing communication overhead; in the Commit phase, the Low-Performance Group (LPG) nodes conduct final confirmation, reducing the burden on high-performance nodes; and in the Reply phase, the HPG nodes accelerate client response. This hierarchical optimization not only effectively reduces communication latency and processing overhead but also improves the throughput and fault tolerance of the system. The design concept of the algorithm in this embodiment incorporates node performance differences into the consensus mechanism, making it more adaptable and stable under different network conditions, providing new ideas and solutions for the research of consensus algorithms in blockchain and distributed systems.

[0098] The Byzantine fault-tolerant consensus method based on node behavior analysis in this embodiment is based on node behavior analysis. First, the behavior of nodes is evaluated and weights are introduced, and then the nodes are divided into different groups according to their weights; during the consensus process, the primary node is selected from the first node group with higher performance, which can increase the probability of excellent nodes being selected as the primary node; in each stage, different node groups are designated to be responsible for specific tasks, thereby optimizing the consensus process, reducing network overhead, increasing system throughput, and reducing the latency of the consensus process, and further improving the overall performance of the system.

[0099] To verify the effectiveness of the method in this embodiment, the following experiments and analyses are carried out:

[0100] To prove the performance of the ABA-PBFT algorithm in this embodiment, we carried out a comparative analysis simulation experiment of it with the classical PBFT algorithm and the Raft algorithm in terms of efficiency and security. The simulation test environment used in this paper is: Windows11 operating system, 12th Gen Intel(R) Core(TM) i9-12900H 2.50GHz processor, 16.0GB of on-board RAM, the system type is 64-bit operating system, processor based on x64, and the algorithm implementation language is Golang. This chapter will conduct experimental analysis on the ABA-PBFT algorithm from multiple aspects such as consensus latency and security, and organize and compare the experimental data through MATLAB R2023B to verify the superiority of this solution.

[0101] 1. Consensus latency

[0102] In the blockchain system, the time interval from when a node submits a request to reaching a consensus is called the consensus latency. This indicator is used to measure the performance of the algorithm. The shorter the latency, the faster the system confirms transactions, thereby significantly reducing the risk of transaction failure or data conflict. Although the latency cannot be completely eliminated, the goal is to shorten it to the lowest possible level. Its calculation formula is:

[0103] T consensus = T msg_round *N rounds ;

[0104] In the formula: T consensus represents the latency; T msg_round represents the time of each round of message passing; N rounds represents the number of rounds in the consensus process.

[0105] In order to explore the performance of the ABA-PBFT algorithm under different network scales, the experiment was designed with the number of nodes as the independent variable, gradually increasing from 3 nodes to 10 nodes, and completed tests of nearly 1000 transactions in this environment.

[0106] The experimental results are as follows Figure 3 shown. By introducing a grouping mechanism based on node performance to select the primary node, this optimization strategy significantly reduces the failure rate during the consensus process. At the same time, by implementing the participation of node groups in phases, the consensus process becomes more reliable, effectively reducing the number of nodes required for each round of consensus, thus significantly shortening the overall system latency. Specifically, this optimization mechanism not only improves the stability and efficiency of the consensus process but also directly leads to a decrease in the latency value, indicating that the ABA-PBFT algorithm has made substantial progress in terms of scalability and performance optimization.

[0107] 2. Throughput

[0108] Throughput is a key metric for measuring the system's ability to process the volume of transactions per unit time, which reflects the overall performance level of the system. The higher the throughput, the more transactions or requests the system can process within a specific time, indicating the system's processing capacity and efficiency. Its calculation formula is as follows

[0109]

[0110] In the formula: Throughput represents throughput, N transations represents the total number of successfully processed transactions or messages within a specific time window T window and T window is the length of the time window in seconds.

[0111] To systematically evaluate the throughput performance of the algorithm under different scales, we designed a series of experiments where the number of nodes was used as the key variable, gradually increasing from 3 to 10. As Figure 4 shown, as the number of nodes increases, the throughput of both the PBFT and ABA-PBFT consensus algorithms shows a decreasing trend. This phenomenon reflects that in a distributed system, an increase in the number of nodes will lead to an increase in coordination and synchronization costs, thus having a negative impact on the system's processing capacity. However, although both algorithms face the problem of decreasing throughput, the ABA-PBFT algorithm shows higher throughput under the same number of nodes. This indicates that ABA-PBFT exhibits better performance and higher efficiency when dealing with a large number of node participations.

[0112] 3. Communication Overhead

[0113] Communication overhead refers to the communication volume generated by nodes in the network during the consensus process. Since nodes need to communicate with each other to ensure data consistency among nodes during the consensus process, communication overhead is an important metric for measuring the efficiency of the consensus algorithm. In this subsection, the communication overhead required for a single consensus of the PBFT algorithm and the ABA-PBFT algorithm is compared.

[0114] Since it is designed based on the PBFT algorithm, the number of groups M (M≥4) required for ABA-PBFT consensus, and the number of consensus nodes n (n≥5) within the group. Therefore, the total number of system nodes is N = M * n. As Figure 5 shown, by simulating each algorithm consensus process, the communication overhead required for nodes in the system to complete a PBFT consensus and an ABA-PBFT consensus can be obtained respectively.

[0115] Obviously, compared with the traditional PBFT algorithm, the ABA-PBFT algorithm significantly reduces the communication cost in the consensus process. As the number of nodes increases, the advantage of ABA-PBFT in reducing communication pressure becomes more prominent, showing higher efficiency and better scalability.

[0116] 4. Security

[0117] The higher the node performance of the grouped nodes, the easier it is to distinguish the overall level of different groups, thereby improving the governance efficiency and decision-making quality of the entire network. Randomly select nodes with different speeds in three groups and record their node performance under the system, as shown. After the experiment starts, as the consensus speed of different nodes increases, the corresponding node performance will also improve, reflecting the rationality of the node evaluation system, as Figure 6 shown.

[0118] Consensus efficiency usually refers to the number of transactions or operations that the system can process and confirm within a unit time. It measures the overall processing ability of nodes for system transactions. Randomly select different nodes in three groups and record their node performance after processing different numbers of transactions per unit time, as Figure 7 shown. After the experiment starts, as the number of transaction pens increases, its node performance also improves.

[0119] The Group Byzantine Fault Tolerance Consensus Mechanism Based on Node Behavior Analysis (ABA-PBFT) in this embodiment aims to overcome problems faced by the traditional PBFT algorithm in practical applications, such as improper selection of the primary node, large system communication overhead, and excessive consensus latency. By systematically analyzing the behavior of nodes and constructing a voting weight evaluation model, ABA-PBFT can effectively evaluate and distinguish the performance of nodes and divide them into different performance groups. On this basis, the primary node is randomly selected from the High-Performance Group (HPG), optimizing the primary node selection and consensus execution process of PBFT, significantly reducing the system communication overhead and consensus latency. The simulation experiment results show that ABA-PBFT is superior to the traditional PBFT algorithm in key performance indicators such as consensus latency and throughput, proving its effectiveness and reliability in preventing Byzantine attacks and improving system stability. The innovation of this paper lies in introducing behavior analysis into the consensus mechanism and grouping according to node performance to improve the existing PBFT algorithm. This idea provides an important reference for the future research on optimizing blockchain consensus mechanisms. Through this research, the security and stability of the blockchain system have been further improved, and at the same time, new ideas and methods have been provided for the design and implementation of decentralized systems, with important theoretical significance and practical application value.

[0120] In addition, although the steps of the methods in this disclosure are described in a specific order in the drawings, this does not require or imply that these steps must be performed in that specific order, or that all the shown steps must be performed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step for execution, and / or one step may be decomposed into multiple steps for execution, etc.

[0121] An embodiment of the present invention also provides a non-transitory computer-readable storage medium, which can be set in an electronic device to store at least one instruction or at least one segment of a program related to a method in the method embodiment. The at least one instruction or the at least one segment of the program is loaded and executed by the processor to implement the method provided in the above embodiment.

[0122] The program product can adopt any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the readable storage medium include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0123] A computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which readable program code is carried. Such a propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. The readable signal medium may also be any readable medium other than a readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device.

[0124] The program code contained on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0125] The program code for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and also including conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's device, executed as a stand-alone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., by using an Internet service provider to connect through the Internet).

[0126] Embodiments of the present invention also provide an electronic device, including a processor and the foregoing non-transitory computer-readable storage medium.

[0127] The electronic device is merely an example and should not impose any limitation on the functions and scope of use of the embodiments of the present application.

[0128] The electronic device is presented in the form of a general-purpose computing device. The components of the electronic device may include but are not limited to: the foregoing at least one processor, the foregoing at least one memory, and a bus connecting different system components (including the memory and the processor).

[0129] Wherein, the memory stores program code, and the program code can be executed by the processor, so that the processor executes the steps in the various embodiments described in this specification.

[0130] The memory may include a readable medium in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0131] The memory may also include program / utility with a set (at least one) of program modules, and such program modules include, but are not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include the implementation of a network environment.

[0132] The bus may represent one or more of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus structures.

[0133] The electronic device may also communicate with one or more external devices (such as a keyboard, a pointing device, a Bluetooth device, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device, and / or may communicate with any device that enables the electronic device to communicate with one or more other computing devices (such as a router, a modem, etc.). Such communication may be carried out through an input / output (I / O) interface. Moreover, the electronic device may also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through a network adapter. The network adapter communicates with other modules of the electronic device through the bus. It should be understood that although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, etc.

[0134] Through the description of the above embodiments, those skilled in the art can easily understand that the exemplary embodiments described herein can be implemented by software or by a combination of software and necessary hardware. Therefore, the technical solutions according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which may be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

[0135] The embodiments of the present invention also provide a computer program product, which includes program code. When the program product runs on an electronic device, the program code is used to cause the electronic device to execute the steps in the methods according to various exemplary embodiments of the present invention described above in this specification.

[0136] Although some specific embodiments of the present invention have been described in detail by way of examples, those skilled in the art should understand that the above examples are for illustrative purposes only and not for limiting the scope of the present invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the present invention.

Claims

1. A Byzantine fault-tolerant consensus method based on node behavior analysis, characterized in that: The method comprises the following steps: S100, obtain several parameters corresponding to each node on the target blockchain to obtain a node parameter list set B = (B1, B2, ..., B i , …, B n ), i=1, 2, …, N; where B i is the node parameter list corresponding to the i-th node on the target blockchain, and N is the number of nodes on the target blockchain; B i =(L i , A i , U i , MDSR i );L i is the node response time corresponding to the i-th node, A i is the correct response rate corresponding to the i-th node, U i is the node availability rate corresponding to the i-th node, MDSR i is the message transmission success rate corresponding to the i-th node; S200, according to B, determine the weight corresponding to each node to obtain the weight list S corresponding to B = (S1, S2, ..., S i , …, S n ); where S i A i The corresponding weight; S i =ω1×L i +ω2×A i +ω3×U i +ω4×MDSR i ; ω1 is the first preset weight, ω2 is the second preset weight, ω3 is the third preset weight, and ω4 is the fourth preset weight; ω1+ω2+ω3+ω4=1; S300, traverse S, if S i ≥λ1, then S i Add to the preset first node group; wherein λ1 is the first preset weight threshold; S400, if λ2≤S i <λ1, then S i Add to the preset second node group; wherein λ2 is the second preset weight threshold; λ1 and λ2 are determined according to S; S500, if S i <λ2, then S i Add to the preset third node group; S600, determining the node with the largest weight in the first node group as the master node; S700, execute the preset fault-tolerant consensus steps.

2. According to the Byzantine fault-tolerant consensus method based on node behavior analysis according to claim 1, it is characterized in that: Step S700 includes the following steps: S710, in the Request phase, the master node obtains the client's request and generates a REQUEST message REQ=<m,t,c,σ_c,extra> ; Where m is the request content, t is the timestamp, c is the client ID, σ_c is the client signature, and extra is the additional data; S720, in the Pre-Prepare stage, the master node generates a PRE-PREPARE message corresponding to REQ, and broadcasts the PRE-PREPARE message to other nodes in the first node group and each node in the second node group; S730, in the Prepare stage, after receiving the PRE-PREPARE message, each node in the second node group verifies the PRE-PREPARE message, generates a PREPARE message, and broadcasts the PREPARE message to each node in the first node group, the second node group, and the third node group; S740, in the Commit phase, after receiving the PREPARE message, the nodes in the third node group verify the PREPARE message, generate a COMMIT message and broadcast the COMMIT message to all nodes; S750, in the Reply phase, the nodes in the first node group are responsible for sending a confirmation reply to the client based on the proposal result reached through consensus.

3. The Byzantine fault-tolerant consensus method based on node behavior analysis according to claim 1, characterized in that: L i Determine by following these steps: S110, obtain the start time of the i-th node in the j-th consensus , End time and the preset timeout period ; S111, according to , and ,Sure ; Where j=1, 2,…, n; n is the number of consensuses.

4. The Byzantine fault-tolerant consensus method based on node behavior analysis according to claim 1, characterized in that: A i Determine by following these steps: S120, obtain the number of correct responses M of the i-th node in all consensuses i , the total number of consensus participations N i , time weight times α j , the correct response rate A in the jth time period ij ; S121, according to M i 、N i , α j and A ij ,Sure ; k is the number of time periods considered.

5. The Byzantine fault-tolerant consensus method based on node behavior analysis according to claim 1, characterized in that: MDSR i Determine by following these steps: S140, obtaining the number of times the i-th node successfully transmits a message P i , the total number of message transmission attempts Q i , message transmission delay penalty coefficient δ, actual bandwidth utilization BW i and maximum bandwidth utilization BW max ; S141, according to P i , Q i ,δ,BW i and BW max ,Sure ;D im is the delay of the i-th node in the m-th transmission, m=1, 2,…, q.

6. The Byzantine fault-tolerant consensus method based on node behavior analysis according to claim 1, characterized in that: λ1 and λ2 are determined by the following steps: S410, obtain the average weight corresponding to S and weighted volatility ; S420, according to μ and σ, determine λ1=μ+σ and λ2=μ-σ.

7. The Byzantine fault-tolerant consensus method based on node behavior analysis according to claim 1, characterized in that: ω1>ω2>ω3>ω4.

8. A non-transitory computer-readable storage medium, wherein at least one instruction or at least one program is stored in the storage medium, characterized in that: The at least one instruction or the at least one program is loaded and executed by the processor to implement the Byzantine fault-tolerant consensus method based on node behavior analysis as described in any one of claims 1-7.

9. An electronic device, characterized in that: Includes a processor and the non-transitory computer-readable storage medium of claim 8.

Images