Byzantine fault-tolerant consensus method and device based on node behavior analysis and medium

Abstract

The invention provides a Byzantine fault-tolerant consensus method and device based on node behavior analysis and a medium, and relates to the technical field of Byzantine fault-tolerant consensus, and the method comprises the steps: based on node behavior analysis, firstly evaluating the behaviors of nodes, introducing weights, and then dividing the nodes into different groups according to the weights of the nodes; in the consensus process, the main node is selected from the first node group with higher performance, so that the probability that the excellent node is selected as the main node can be improved; assigning different node groups to be responsible for specific tasks in each stage; according to the method, the consensus process is optimized, the network overhead is reduced, the system throughput is improved, the consensus process delay is reduced, and the overall performance of the system is further improved.

Description

Technical Field

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

[0002] With the widespread application of blockchain technology, Practical Byzantine Fault Tolerance (PBFT), as a classic consensus mechanism, has attracted attention for its advantages in tolerating Byzantine faults. In the traditional implementation of the PBFT algorithm, the decentralization process is achieved by randomly selecting a master node. In this process, each node has the opportunity to serve as a master node in a new view number. The key responsibilities of the master node are 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 master nodes is carried out in a predetermined order, there is also a possibility that a Byzantine node will be selected as the next master node. If a Byzantine node masters the sequence of node rotation, it may launch a denial of service attack on the neighboring node that is about to serve as the master node, resulting in frequent view changes. Regardless of how a Byzantine node serves as a master node, the view replacement mechanism will be triggered, which not only increases the pressure on the network and reduces the system's processing capacity, but also increases the delay of the consensus process, thereby negatively affecting 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:

[0004] According to a first aspect of the present application, a Byzantine fault-tolerant consensus method based on node behavior analysis is provided, the method comprising the following steps:

[0005] 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;

[0006] 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;

[0007] 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;

[0008] 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;

[0009] S500, if S i <λ2, then S i Add to the preset third node group;

[0010] S600, determining the node with the largest weight in the first node group as the master node;

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

[0012] According to another aspect of the present application, a non-transitory computer-readable storage medium is also provided, in which at least one instruction or at least one program is stored, and the at least one instruction or at least one program 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, an electronic device is provided, 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 first evaluates the behavior of the nodes and introduces weights, and then divides the nodes into different groups according to their weights; in the consensus process, the master node is selected from the first node group with higher performance, which can increase the probability of excellent nodes being selected as master nodes; in each stage, different node groups are designated to be responsible for specific tasks, thereby optimizing the consensus process, reducing network overhead, improving system throughput, and reducing consensus process delays, thereby 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 briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

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

[0018] Figure 2 A schematic diagram of the algorithm consensus process provided by an embodiment of the present invention;

[0019] Figure 3 A comparison chart of consensus algorithm latency provided by an embodiment of the present invention;

[0020] Figure 4 A comparison chart of the consensus algorithm throughput provided by an embodiment of the present invention;

[0021] Figure 5 A comparison chart of consensus algorithm communication volume provided by an embodiment of the present invention;

[0022] Figure 6 A schematic diagram showing the impact of the consensus speed of nodes in different groups on node performance provided by an embodiment of the present invention;

[0023] Figure 7 A schematic diagram of the impact of the consensus efficiency of nodes in different groups on node performance provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0024] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within 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 an 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 a device and / or practice a method. In addition, other structures and / or functionalities other than one or more of the aspects described herein can be used to implement this device and / or practice this method.

[0026] The following will refer to Figure 1 The flowchart of the Byzantine fault-tolerant consensus method based on node behavior analysis shown in the figure introduces a Byzantine fault-tolerant consensus method based on node behavior analysis.

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

[0028] 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.

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

[0030] Furthermore, Li Determine by following these steps:

[0031] S110, obtain the start time of the i-th node in the j-th consensus End time And the preset timeout period

[0032] S111, according to and Sure Wherein, j=1, 2, ..., n; n is the number of consensuses.

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

[0034]

[0035] Where: L i is the average response time score of the ith node, is the start time of node i in the jth consensus, It's the end time. is the preset timeout period, and n is the number of consensuses.

[0036] Response time is an important indicator of node performance. Too long response time may lead to increased latency in the entire system, so this indicator has a higher weight.

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

[0038] 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 .

[0039] S121, according to M i 、N i , α j and A ij ,Sure k is the number of time periods considered.

[0040] In this embodiment, the correct response rate (Accuracy) is an indicator for evaluating the correctness of the response of the node in the consensus process. It is scored by calculating the ratio of the number of correct responses to the total number of participations in all rounds of consensus. The score can introduce an adjustment coefficient based on historical performance, taking into account the performance differences of nodes in different time periods. In addition, the performance of the node in the most recent consensus can be introduced as a weighting factor, so that the node with better performance recently can get a higher score. This indicator is designed to ensure that the node makes decisions that comply with the protocol specifications during the consensus process, thereby maintaining the security and consistency of the entire system. The correct response rate (Accuracy) is expressed as follows.

[0041]

[0042] Where: A i is the comprehensive correct response rate 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 consensus participations. j is the time weighted number, which is used to adjust the performance of the node in different time periods. The most recent performance has a higher weight, and the earlier performance has a lower weight. A ij is the correct response rate of node i in the jth time period, and k is the number of time periods considered.

[0043] Accuracy directly affects the correctness of consensus, and incorrect responses will weaken the security of the system, so the weight of this indicator is also high.

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

[0045] S130, obtain the running time Uptime of the i-th node i , the total time during the observation periodTotaltime i , the recovery time after the first failure is R il , the weight of the fault recovery time β l and the number of historical failures F i .

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

[0047] In this embodiment, node availability, i.e., node availability rate, is used to measure the operating status of a node during a specific observation period, i.e., the proportion of a node that remains online during the time it is expected to be online. The scoring can introduce the node's recovery speed and historical failure records. By introducing the node's recovery time after a failure and the penalty item for the number of historical failures, the score of nodes that frequently fail or have a long recovery time is reduced. This indicator reflects the stability and reliability of the node, ensuring that during the consensus process, the node can continue to provide services and that the normal operation of the system is not affected by frequent offline or failures.

[0048] The node availability expression formula is as follows.

[0049]

[0050] Where: U i is the availability score of the ith node, Uptime i is the running time of node i, Totaltime i is the total time of the observation period. il is the recovery time of node i after the lth failure, β l is the weight of the fault recovery time, F i is the number of historical failures of node i. is the penalty coefficient based on the recovery time. The longer the recovery time is or the more failures occur, the smaller the value is. γ is the penalty coefficient for the number of failures. The more failures occur, the larger the value is.

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

[0052] Furthermore, MDSR i This can be determined by the following steps:

[0053] 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 .

[0054] S141, according to P i , Q i ,δ,BW i and BW max ,Sure D imis the delay of the i-th node in the m-th transmission, m=1, 2,…, q.

[0055] 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 score can take into account the delay in message transmission, bandwidth utilization, and the impact of the network topology on message transmission. By introducing these factors, nodes with low transmission efficiency and poor bandwidth utilization receive lower scores. This indicator ensures that the node has good communication capabilities in the network environment, thereby ensuring that consensus information is smoothly transmitted between nodes and reducing the risk of consensus failure or delay due to communication failures. The expression formula for the Message Delivery Success Rate is as follows.

[0056]

[0057] Where: MDSR i is the message transmission success rate score of the i-th node, P i is the number of times a node successfully transmits a message, 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. i is the actual bandwidth utilization of the node, BW max It is the maximum bandwidth utilization. The higher the utilization, the higher the score.

[0058] The success rate of message transmission is a basic requirement to ensure the smooth progress of the consensus process, but considering the importance of other indicators, this indicator has a lower weight.

[0059] 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.

[0060] In this embodiment, the evaluation of node performance, i.e., the weight of the node, is based on four specific indicators, namely, 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 indicator to determine the importance of different indicators. According to the weights and scores of each indicator, 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 indicators is shown in Table 1.

[0061] Table 1

[0062]

[0063] Since response time and correct response rate are the key to ensure system efficiency and correctness, they have a higher weight. Although node availability and message transmission success rate are important, their weights are relatively low considering that the PBFT algorithm itself has a certain fault tolerance. Therefore, the node response time score weight is 40%, the correct response rate score weight is 35%, the availability score weight is 15%, and the message transmission success rate score weight is 10%; that is, ω1=0.4, ω2,=0.35, ω3,=0.15, ω4=0.1.

[0064] Furthermore, assuming that there are N nodes in the network, the performance of the node S is obtained by quantifying the four indicators of node response time, correct response rate, availability, and message transmission success rate. i Then, the voting weight V of the ith node is calculated according to the following formula: i .

[0065]

[0066] Among them, V i is the voting weight of node i, S i Indicates the performance of the behavior analysis node. n is the number of all nodes participating in the formula, and α is the adjustment coefficient. By adjusting the α value, the distribution of voting weights can be controlled. If α=1, the node score linearly affects the voting weight; if α>1, nodes with higher scores will receive 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 voting weights is more intuitive and easy to understand.

[0067] Algorithm 1 is the calculation process of node voting weight.

[0068]

[0069]

[0070] 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.

[0071] 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.

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

[0073] Further, λ1 and λ2 are determined by the following steps:

[0074] S410, obtaining the average weight corresponding to S and weighted volatility

[0075] S420: According to μ and σ, determine λ1=μ+σ and λ2=μ-σ.

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

[0077]

[0078]

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

[0080]

[0081]

[0082] S600: Determine the node with the largest weight in the first node group as the master node.

[0083] In this embodiment, the master node is selected from the high performance group (HPG). Since the nodes of the HPG group are significantly better than those of other groups in terms of processing power, response time, correct response rate, and message transmission success rate, selecting the nodes of the HPG group as the master node can fully utilize its performance advantages. This ensures that the master node has higher efficiency and reliability in coordinating the consensus process and processing requests, thereby speeding up the consensus and improving its accuracy. This selection mechanism helps to optimize the overall performance of the system.

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

[0085] In order to avoid the long-term centralization of the master node and the potential risks it brings, the method in this embodiment also implements a master node rotation strategy. At a set time interval or when a specific event is triggered, the system will select a different node from the HPG group as the new master node. This strategy can effectively disperse the responsibilities of the master node, reduce the possibility of a node being attacked or failing, and enhance the system's anti-attack capability and overall reliability. Through the rotation mechanism, the method in this embodiment maintains the original design intention of decentralization and avoids the risk of centralization.

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

[0087] Furthermore, step S700 includes the following steps:

[0088] 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.

[0089] 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.

[0090] S730, in the Prepare phase, after each node in 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 in the first node group, the second node group, and the third node group.

[0091] 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.

[0092] 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.

[0093] The method in this embodiment introduces a node performance grouping mechanism in the consensus process, which significantly improves 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 at all stages, resulting in high communication overhead and processing delay. The method in this embodiment optimizes the consensus process by dividing the nodes into high performance groups (HPG), medium performance groups (MPG) and low performance groups (LPG), and assigning different node groups to be responsible for specific tasks in each stage. In the Request stage, the fast processing capability of the HPG node reduces the delay of request generation and broadcasting. In the Pre-Prepare stage, the HPG node generates proposals and improves the efficiency of proposal verification and transmission through the summary tree technology. The Prepare stage is the responsibility of the MPG node, which reduces the communication burden and speeds up the verification process through the partial threshold signature technology. In the Commit stage, the LPG node is responsible for the final confirmation, which reduces the burden on high-performance nodes and improves the fault tolerance of the system. Finally, in the Reply stage, the HPG node quickly responds to client requests, improving the response speed and throughput of the system. In general, the method in this embodiment not only reduces the communication overhead and processing delay of the system through node grouping and hierarchical processing, but also enhances the adaptability and stability of the system under different performance conditions, and significantly optimizes the performance of the traditional PBFT algorithm. The consensus flow diagram of the method in this embodiment is shown in Figure 2 shown.

[0094] The steps of the consensus algorithm in this embodiment are as follows:

[0095] Request phase: The client makes a request and sends it to the High Performance Group (HPG) node in the network. HPG nodes are selected as primary nodes due to their high computing and network processing capabilities. They are responsible for processing client requests 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 phase. Compared with traditional PBFT, ABA-PBFT reduces processing delays and optimizes the initial proposal generation process by routing requests directly to high-performance nodes.

[0096] Pre-Prepare phase: In the Pre-Prepare phase, the master node of the HPG group is responsible for generating proposal messages and broadcasting them to other HPG nodes and medium performance group (MPG) nodes. HPG nodes first reach preliminary consistency 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 master node, group identifies the node group (HPG), and digest_tree is the digest tree of the proposal. Due to the superior performance of the HPG node, this phase can be completed quickly, significantly reducing the proposal generation time and network latency. After receiving the proposal, the MPG node begins to prepare to enter the next phase of verification. Unlike the participation of all nodes in traditional PBFT, ABA-PBFT concentrates proposal generation and broadcasting on high-performance nodes, thereby reducing initial latency.

[0097] Prepare phase: The Prepare phase is mainly responsible for the MPG node. After receiving the PRE-PREPARE message broadcast from the HPG group, the MPG node will verify it to ensure the correctness and consistency of the proposal. Each MPG node will independently check the proposal, generate and broadcast the corresponding PREPARE message, and the message format is PREPARE = ​​<v,n,d,i,σ_i,group>. Among them, 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. Unlike the participation of all nodes in traditional PBFT, ABA-PBFT uses MPG nodes for efficient verification. MPG nodes can quickly reach a preliminary consensus while reducing the communication burden, which improves the efficiency of the Prepare phase and lays the foundation for the next confirmation phase of the system.

[0098] Commit phase: Low performance group (LPG) nodes begin to participate in consensus at this phase and assume the responsibility of final confirmation of the proposal. After receiving the PREPARE message from the MPG node, the LPG node will perform secondary verification, generate and broadcast a COMMIT message in the format of COMMIT = <v,n,d,i,σ_i,group>, where group identifies the node group (LPG). The intervention of the LPG node ensures the final consistency and security of the proposal, which is especially important when dealing with nodes with uneven performance. The Commit message is broadcast to all nodes, and the system can confirm that the proposal is consistent after receiving enough Commit messages. Compared with the participation of all nodes in traditional PBFT, ABA-PBFT reduces the burden on high-performance nodes by assigning the final confirmation task to low-performance nodes.

[0099] Reply phase: The HPG node is responsible for sending a confirmation reply to the client after the consensus is reached. The message format is REPLY = <r, c, σ_r>, where r is the execution result of the client request and σ_r is the node's signature on the execution result. Due to the high performance and low latency of the HPG node, the client can quickly receive the final consensus result. The design of this phase ensures that the client's request is responded to quickly and the system's throughput is 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.

[0100] In summary, the algorithm of this embodiment shows significant advantages in optimizing each stage of the consensus process by introducing a grouping mechanism based on node performance. Compared with traditional PBFT, the request is quickly processed by the high performance group (HPG) in the Request stage, the proposal summary tree is used to improve the efficiency of data transmission and verification in the Pre-Prepare stage, and the participation of the medium performance group (MPG) nodes in the Prepare stage is used for efficient verification, which reduces the communication overhead. In the Commit stage, the low performance group (LPG) nodes make the final confirmation, which reduces the burden of high performance nodes, and accelerates the client response through the HPG nodes in the Reply stage. This hierarchical optimization not only effectively reduces communication delays and processing overhead, but also improves the throughput and fault tolerance of the system. The design concept of the algorithm of this embodiment integrates node performance differences into the consensus mechanism, so that it shows higher adaptability and stability under different network conditions, and provides new ideas and solutions for the research of consensus algorithms in blockchain and distributed systems.

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

[0102] In order to verify the effect of the method in this embodiment, the following experiments and analyses were performed:

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

[0104] 1. Consensus delay

[0105] In a blockchain system, the time interval from when a node submits a request to when consensus is reached is called consensus latency. This indicator is used to measure the performance of an algorithm. The shorter the latency, the faster the system confirms transactions, which significantly reduces the risk of transaction failure or data conflict. Although latency cannot be completely eliminated, the goal is to minimize it as much as possible. The calculation formula is:

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

[0107] Where: T consensus represents time delay; T msg_round Represents the time of each round of message delivery; N rounds Represents the number of rounds in the consensus process.

[0108] In order to explore the performance of the ABA-PBFT algorithm under different network scales, the experimental design uses the number of nodes as the independent variable, gradually increasing from 3 nodes to 10 nodes, and completed the test of nearly 1,000 transactions in this environment.

[0109] The experimental results are as follows Figure 3 As shown in the figure, by introducing a grouping mechanism based on node performance to select the master node, this optimization strategy greatly reduces the failure rate in the consensus process. At the same time, by implementing the participation of node groups in stages, the consensus process becomes more reliable, effectively reducing the number of nodes required for each round of consensus, thereby 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 reduction in the delay value, indicating that the ABA-PBFT algorithm has made substantial progress in scalability and performance optimization.

[0110] 2. Throughput

[0111] Throughput is a key indicator to measure the system's ability to handle business volume per unit time, which reflects the overall performance level of the system. The higher the throughput, the more transactions or requests the system can handle within a specific period of time, which in turn indicates the system's processing power and efficiency. The calculation formula is:

[0112]

[0113] Where: Throughput represents throughput, N transations Represents the time window T window The total number of transactions or messages successfully processed within T window is the length of the time window in seconds.

[0114] In order to systematically evaluate the throughput performance of the algorithm at different scales, we designed a series of experiments in which the number of nodes was used as a key variable and gradually increased from 3 to 10. Figure 4 The results show that as the number of nodes increases, the throughput of both PBFT and ABA-PBFT consensus algorithms decreases. This phenomenon reflects that in a distributed system, the increase in the number of nodes will lead to an increase in coordination and synchronization costs, which will have a negative impact on the system's processing capacity. However, although both algorithms face the problem of reduced throughput, the ABA-PBFT algorithm shows a higher throughput with the same number of nodes. This shows that ABA-PBFT shows better performance and higher efficiency when dealing with large-scale node participation.

[0115] 3. Communication overhead

[0116] Communication overhead refers to the amount of communication generated by nodes in the network during the consensus process. Since nodes need to communicate with each other to ensure data consistency during the consensus process, communication overhead is an important indicator for measuring the efficiency of the consensus algorithm. This section compares the communication overhead required for a single consensus between the PBFT algorithm and the ABA-PBFT algorithm.

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

[0118] 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.

[0119] 4. Security

[0120] 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. Random nodes with different speeds in three groups are selected and their node performance under the system is recorded, 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 shown in Figure 6 shown.

[0121] Consensus efficiency usually refers to the number of transactions or operations that the system can process and confirm in a unit of time. It measures the overall processing capacity of nodes for system transactions. Randomly select different nodes in the three groups and record their node performance after processing different numbers of transactions in a unit of time, such as Figure 7 As shown in the figure, after the experiment started, as the number of transactions increased, the node performance also improved.

[0122] The grouped Byzantine fault-tolerant consensus mechanism (ABA-PBFT) based on node behavior analysis in this embodiment is designed to overcome the problems faced by the traditional PBFT algorithm in practical applications, such as improper selection of master nodes, large system communication overhead, and long consensus delay. 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 master node is randomly selected from the high performance group (HPG), the master node selection and consensus execution process of PBFT are optimized, and the system communication overhead and consensus delay are significantly reduced. The simulation results show that ABA-PBFT is superior to the traditional PBFT algorithm in key performance indicators such as consensus delay and throughput, proving its effectiveness and reliability in preventing Byzantine attacks and improving system stability. The innovation of this paper is to introduce behavioral analysis into the consensus mechanism and group nodes according to their performance to improve the existing PBFT algorithm. This idea provides an important reference for future research on the optimization of blockchain consensus mechanisms. Through this study, the security and stability of the blockchain system have been further improved, and new ideas and methods have been provided for the design and implementation of decentralized systems, which has important theoretical significance and practical application value.

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

[0124] 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 program related to implementing a method in a method embodiment. The at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiment.

[0125] The program product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media 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.

[0126] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, in which readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Readable signal media may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

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

[0128] 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 conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user 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 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., using an Internet service provider to connect through the Internet).

[0129] An embodiment of the present invention further provides an electronic device, comprising a processor and the aforementioned non-transitory computer-readable storage medium.

[0130] The electronic device is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0131] 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 at least one processor mentioned above, the at least one memory mentioned above, and a bus connecting different system components (including the memory and the processor).

[0132] The memory stores program codes, which can be executed by the processor, so that the processor executes the steps in various embodiments described in this specification.

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

[0134] The memory may also include a program / utility having a set (at least one) of program modules, such program modules including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include an implementation of a network environment.

[0135] The bus may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures.

[0136] The electronic device may also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), may communicate with one or more devices that enable a user to interact with the electronic device, and / or may communicate with any device (e.g., routers, modems, etc.) that enables the electronic device to communicate with one or more other computing devices. Such communication may be performed through an input / output (I / O) interface. Furthermore, the electronic device may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) through a network adapter. The network adapter communicates with other modules of the electronic device through a 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.

[0137] Through the description of the above implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the implementation 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 can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the implementation of the present disclosure.

[0138] An embodiment of the present invention further provides a computer program product, which includes program code. When the program product is run on an electronic device, the program code is used to enable the electronic device to execute the steps of the method according to various exemplary embodiments of the present invention described above in this specification.

[0139] Although some specific embodiments of the present invention have been described in detail by way of example, it should be understood by those skilled in the art that the above examples are only for illustration, not for limiting the scope of the present invention. It should also be understood by those skilled in the art that various modifications may 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 Wherein, 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: U i Determine by following these steps: S130, obtain the running time Uptime of the i-th node i , the total time during the observation periodTotaltime i , the recovery time after the first failure is R il , the weight of the fault recovery time β l and the number of historical failures F i ; S131, according to Uptime i Totaltime i , R il , β l and F i ,Sure γ is the penalty coefficient for the number of failures.

6. 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.

7. 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, obtaining the average weight corresponding to S and weighted volatility S420: According to μ and σ, determine λ1=μ+σ and λ2=μ-σ.

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

9. 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-8.

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

Images