Fault-tolerant consensus method based on dynamic grouping and credible evaluation

Abstract

The invention discloses a fault-tolerant consensus method based on dynamic grouping and credible evaluation, named GPBFT, and belongs to the field of block chains. All core mechanisms of the invention are specifically described below. The dynamic grouping mechanism divides the nodes into a consensus group, an election group and a suspicious group, and node grouping is dynamically adjusted through mutual trust indexes and credit values. And the credit values of the election group and the suspicious group are calculated by weighting the performance score and the credibility score. Mutual trust indexes of the nodes of the consensus group are generated through inter-node interaction score iteration, and the overall trust degree of each node by the consensus group is quantified. And the GPBFT uses a verifiable random function and a threshold value in a value range thereof to adjust the probability that the node participates in the consensus in the election group according to the credit value. In the optimized consensus process, the normal process of the GPBFT comprises three stages of Pre-pre, Pre and Commit, and the time complexity is reduced to O (n); and if an abnormal situation occurs, a Peer-prepart stage and a Peer-commit stage are triggered, so that the error-tolerant rate of the system is improved. Through the mechanisms, the security and the expandability of the block chain system can be remarkably improved.

Description

Technical Field

[0001] The present application relates to the technical field of blockchain consensus mechanism, and in particular to a consensus algorithm based on grouping and trust scoring. Background Art

[0002] Blockchain utilizes a decentralized network architecture. Because each node (host) in a blockchain is independent, the system requires a consensus algorithm to ensure consensus on data status across all nodes. For example, in small- to medium-scale scenarios, such as medical data sharing among hospitals across a city, the Practical Byzantine Fault Tolerance (PBFT) algorithm allows all nodes in the network to reach consensus on data when the number of Byzantine nodes is less than one-third of the total number of nodes in the system. PBFT communication consumes less energy and performs well when the number of nodes in the blockchain network does not exceed 100, making it suitable for applications such as consortium chains.

[0003] However, PBFT also has a number of shortcomings. First, it lacks the ability to exclude malicious nodes. Second, when the master node is a Byzantine node, the time complexity of PBFT view switching is high. Third, the scalability of systems using PBFT is also insufficient.

[0004] To this end, we propose an algorithm based on grouping and trusted evaluation to solve the above-mentioned security and scalability problems. Summary of the Invention

[0005] The purpose of the present invention is to provide a consensus algorithm that can improve the security and scalability of blockchain systems to solve the problems raised in the above background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a consensus algorithm called GPBFT (Grouping-based PBFT).

[0007] First, in GPBFT, nodes in the system are divided into three groups: the "consensus group," the "election group," and the "suspect group," with the reliability of these three groups decreasing in descending order. In each consensus round, the number of nodes in the consensus group remains constant at C (an adjustable parameter), and all nodes participate. In the election group, a portion of nodes are elected as consensus nodes, while nodes in the suspect group are excluded from consensus. The attribute used to assess the reliability of consensus group nodes is called the "mutual trust index," denoted as MT; the attribute used to assess the reliability of nodes in the election group and the suspect group is called the "credit value," denoted as CR.

[0008] It's worth noting that in a GPBFT consensus round, consensus nodes are divided into two categories: "master nodes" and "replica nodes." There is only one master node, which is rotated among all nodes in the consensus group according to their "consensus group number." All other consensus nodes are replica nodes.

[0009] Regarding consensus group numbers, each number represents a "position." From 0 to C-1, each consensus group member occupies a consensus group number (position). However, the consensus group number and the node number within the blockchain system are two separate entities. In the rotation of master nodes, the member with consensus group number 0 will first serve as the master node, followed by the node with consensus group number 1. And so on. After the member with consensus group number C-1 becomes the master node, the member with consensus group number 0 will again serve as the master node.

[0010] A rotation mechanism exists between the consensus group and the election group. After each consensus round, the members of the consensus and election groups rotate. The m nodes with the lowest mutual trust index in the consensus group become election group nodes, while the m nodes with the highest credit rating in the election group become consensus group nodes. The consensus group numbers of the m original consensus group members moved to the election group are randomly assigned to the m original election group members. m is an adjustable parameter.

[0011] There is also a rotation mechanism between the election group and the suspicious group. If the credit value of the election group member is lower than a certain critical value CR d , then it becomes a member of the suspicious group and enters a freeze period of x rounds. It cannot return to the election group in the next x rounds of consensus. If the credit value of a suspicious group member is higher than a certain critical value CR r , and the x-round freeze period has ended, then return to the election group. Here CR d , CR r , x are adjustable parameters, and CR r ≥CR d .

[0012] The significance of the above two rotation mechanisms is to ensure both the security of the system (excluding malicious nodes) and the decentralization of the system.

[0013] As mentioned above, the reliability of the elected group and the suspicious group members is evaluated by the credit value. The credit value is calculated by the weighted average of the "performance score" and the "trustworthiness score". The performance score of the node numbered i (hereinafter referred to as "node i") is recorded as Pf i , the trust score is recorded as Re i , then the credit value CR i for

[0014] CR i =e1·Pfi +e2·Re i .

[0015] The sum of the weights e1 and e2 is 1.

[0016] The performance score evaluates the hardware performance of the node, while the trust score evaluates the reliability of the node's behavior. From a security perspective, the latter is significantly more important than the former, so the value of e2 is much larger than e1.

[0017] For example, the values of e1 and e2 can be 0.15 and 0.85 respectively.

[0018] The performance score is calculated by combining the four indicators of "CPU frequency", "memory capacity", "memory frequency" and "hard disk capacity". Now normalize the above four indicators. The value of a certain indicator of the node numbered i is SC i , then the normalized value of the index (denoted as USC i )for

[0019]

[0020] Among them SC max and SC min are the maximum and minimum values of the indicator in the system, that is, the indicator of the node with the largest indicator value and the indicator of the node with the smallest indicator value.

[0021] The normalized index values of CPU frequency, memory capacity, memory frequency, and hard disk capacity of node i are USC_CPU and USC_CPU respectively. i 、USC_Mem i 、USC_MemF i 、USC_Hard i , then the performance score of node i (denoted as Pf i ) is the weighted average

[0022] Pf i =w1·USC_CPU i +w2·USC_Mem i +w3·USC_MemF i +w4·USC_Hard i .

[0023] Weights w1, w2, w3, and w4 are adjustable parameters, and the sum of the four weights is 1. Since the importance of CPU frequency, memory capacity, memory frequency, and hard disk capacity decreases in descending order, w1>w2>w3>w4.

[0024] For example, w1, w2, w3, and w4 can be 0.55, 0.25, 0.15, and 0.05, respectively.

[0025] The trust score is a normalized value between 0 and 1, which is calculated by the "independence score" indicator. The independence score is an integer, and its value range is theoretically the set of integers Z. The independence score of node i is denoted as RS i .

[0026] The initial independent score of each node when the system starts running and the node that has just been rotated from the consensus group to the election group is RS I This is an adjustable parameter, but usually RS I The value of is 0.

[0027] Regarding the addition and subtraction of independent scores with node behavior, here we introduce four parameters ΔRS0, ΔRS1, ΔRS2, and ΔRS3 (all positive integers) as the changes in independent scores:

[0028] ① If node i participates in a round of consensus completely and correctly, then RS i The value increases by ΔRS0.

[0029] ② If node i times out and does not respond during the consensus process, RS i The value is reduced by ΔRS1.

[0030] ③ If node i maliciously sends illegal information during the consensus process, RS i The value is reduced by ΔRS2.

[0031] ④ If node i is not a consensus node and only passively receives the consensus result in the background, then RS i The value increases by ΔRS3.

[0032] In principle, in order to make the penalty effect of node error behavior greater than the reward effect of correct behavior and effectively exclude malicious nodes, the size relationship of the four parameters ΔRS0, ΔRS1, ΔRS2, and ΔRS3 should be set to

[0033] ΔRS2>>ΔRS1>ΔRS0>ΔRS3.

[0034] Although the value of the independent score RS can be any integer in theory, in practical applications, the system needs to set upper and lower limits for it.

[0035] Lower limit processing: The independent score of the node reaches the lower limit RS B After that, it will stop at RS B , and will not continue to decrease.

[0036] Upper limit processing: The independent score of the node reaches the upper limit RS T After that, it will jump back to an intermediate value RS R , and RS R Only slightly larger than RSI .

[0037] The upper and lower limits of independent scores not only ensure that independent scores will not overflow due to excessive absolute values, but also prevent the nodes in the blockchain system from polarizing and forming a centralized tendency due to excessively large or small independent scores.

[0038] As a parameter, the lower limit RS B It can be set between -200 and -150, and the upper limit RS T Can be set between 150 and 200.

[0039] Regarding the trust score, its value range is between 0 and 1, and it is obtained by normalizing the independent scores using the inverse tangent function. Its function expression is:

[0040]

[0041] The q in the formula is also an adjustable parameter, which means the horizontal stretching multiple of the function graph.

[0042] In GPBFT's grouping mechanism, the reliability of nodes in the election group and the suspicious group is measured by credit value, while the reliability of nodes in the consensus group is measured by the mutual trust index.

[0043] The calculation of the mutual trust index is based on the basic principles of the EigenTrust model. In GPBFT, nodes in the consensus group will record the positive scores of correct responses and negative scores of incorrect responses from other nodes based on their message exchanges.

[0044] The positive score between node i and node j is K ij , negative rating is M ij .

[0045] In the initial stage of the system operation, K ij and M ij The initial value is 0, and when the node k in the election group is just rotated into the consensus group, for any other node l in the consensus group, K kl 、M kl , K lk 、M lk The initial value of is also 0.

[0046] In the consensus group, each time node j correctly responds to node i once, the positive score K ij The value of increases by ΔK0; each time node j does not respond to node i, the negative score M ij The value of increases by ΔM0; and whenever node j maliciously responds to node i with illegal information, the negative score M ij The value increases by ΔM1.

[0047] ΔK0, ΔM0, and ΔM1 are all adjustable positive parameters. In principle, ΔM1>>ΔM0≈ΔK0.

[0048] For example, you can set ΔK0=1, ΔM0=1, and ΔM1=5.

[0049] To characterize the degree of trust that node i has in node j, we calculate the difference between the positive score and the negative score W ij ,Right now

[0050] W ij =K ij -M ij .

[0051] When W ij If W is positive, it means that node i trusts node j; otherwise, ij If it is negative, it means that node i does not trust node j.

[0052] make

[0053]

[0054] And let the collective symbol of the consensus group be Con, and there are M nodes in the consensus group. Now let’s calculate the mutual trust index MT of node i in the consensus group. i The calculation method of is explained.

[0055] First calculate the normalized value

[0056]

[0057] The denominator of the above formula means D of all nodes k in the consensus group ik The sum of values.

[0058] Represents the initial level of trust that i has in j. To further confirm j’s credibility, node i can query other nodes in the consensus group one by one. The result of the first round of query is The calculation method is

[0059]

[0060] in The meaning of is the trust weight. ib When ≤0, This means that node i does not trust node b at all, so node i does not consider b’s trust in node j at all.

[0061] Note vector (j0,j1,...,j M-1 is the number of M nodes in the consensus group), combined with the above formula The matrix form can be obtained

[0062]

[0063] where the matrix U (0) for

[0064]

[0065] In the same way, we let node i conduct a second round of query and get the result

[0066]

[0067] Note vector The matrix form can be obtained

[0068]

[0069] And so on, after n rounds of iteration, we get the vector

[0070]

[0071] The more iterations, the more reliable the result. (0) represents the state transition matrix of a Markov chain, so the above iterative process will converge to a vector that depends only on the overall trust of the consensus group and has nothing to do with the specific individual nodes in the consensus group.

[0072]

[0073] Denote vector u (∞) The elements in These elements comprehensively quantify the degree of trust the consensus group as a whole has in each node in the group.

[0074] Finally, the mutual trust index of node i in the consensus group is calculated based on the most reliable node in the group, and the result is

[0075]

[0076] As mentioned above, the vector u (∞) It takes an infinite number of operations to get it, but in practical applications, we can only get u through a finite number of operations. (∞) To do this, we can use a sufficiently large integer n to calculate the approximate value

[0077]

[0078] Furthermore, in order to significantly reduce computational overhead, the integer n must satisfy n=2 s (s is also an integer). In this way, only s rounds of iteration are needed to get the result.

[0079] The specific method is: (0) ) T First multiply by itself to get ((U (0) ) T ) 2 , and then multiply the result by itself again, so that we only need to multiply by itself s times to get the result ((U (0) ) T ) 2s .

[0080] In GPBFT, the system uses a Verifiable Random Function (VRF) to elect consensus nodes. VRFs can be used to generate random values, and their validity can be verified by a third party. GPBFT uses the elliptic curve signature algorithm to generate VRFs. The following describes the generation steps.

[0081] Node i generates a pair of keys based on the elliptic curve

[0082] <K public (i),K private (i)>.

[0083] K public (i) is the public key, K private (i) Private key. Where public key K public (i) is the private key K private (i) Generated based on a base point of an elliptic curve over a finite field. For a specific message msg, node i first takes its hash value based on the hash function SHA-256 to obtain the message digest.

[0084] dig=Hash(msg).

[0085] Reuse the private key K private (i) Digitally sign the summary dig to obtain

[0086] SG(i)=Sgn(dig,K private (i)).

[0087] Sgn is the signature algorithm. Finally, node i takes the SHA-256 hash value of the signature SG(i) to obtain the value of VRF

[0088] RA(i)=Hash(SG(i)).

[0089] If node k wants to verify the VRF value RA(i) generated by node i, it first uses the public key K of node i public(i) Verify the signature SG(i) of node i. If the verification succeeds and the hash value of the signature SG(i) is equal to RA(i) after being recalculated by node k, then the VRF value RA(i) is valid.

[0090] Regarding the specific VRF generation method in GPBFT, we will now introduce VRF generation based on "rolling parameters." In GPBFT, the view number value "view" records the consensus round and increases by 1 after each consensus round. This allows the system to generate different rolling parameters in each consensus round.

[0091] Before executing a round of consensus, the system will first concatenate the height value of the latest block and the current view number view, and then take the hash value of the concatenated data height||view to obtain the current scroll parameter

[0092] R view =Hash(height||view).

[0093] The height value of a block means that this block is the height-th block generated by the system after the genesis block. The height value of the genesis block is 0.

[0094] The value of view is different in each round of consensus, and if the consensus does not fail frequently, the height is almost always different, so the height||view of the spliced data in each round must be different. According to the "anti-hash collision" property of the hash function, the rolling parameter R view =The value of Hash(height||view) is also unique to each round of consensus.

[0095] In the consensus round with view number view, node i can use the rolling parameter R view Digitally sign and get

[0096] SG(i)=Sgn(Hash(R view ),K private (i)).

[0097] Next, node i takes the hash value of the signature SG(i) and obtains the VRF value RA(i) in this round of consensus.

[0098] Based on the VRF generation described above, we will now explain the consensus node election rules for the election group. In GPBFT, we introduce the concept of "thresholds" for each node in the election group. Each node in the election group has a field called the threshold, whose value depends on the node's credit score. The node's threshold is the same type of data as the VRF generated by the node.

[0099] The threshold is used to adjust the probability of a node in the election group being selected as a consensus node. We denote the threshold of node i as TH i , if the VRF value RA(i) it generates is greater than the threshold TH of node i i , that is, RA(i)>TH i , then node i is selected as the consensus node. Otherwise, node i only serves as a background node and passively receives the results of this round of consensus.

[0100] The threshold value TH is now described in detail. i The method of determining. The maximum value of the hash function Hash is Hash max Since the hash function value range is [0,Hash max ], so the total number of possible values is Hash max +1, and all values greater than the threshold TH i The hash value range is [TH i +1,Hash max ], that is, the total number of values that meet the conditions is Hash max -TH i According to the uniformity of the hash function value, the probability that node i is selected as the consensus node is

[0101]

[0102] Because Hash max and TH i are all large enough numbers, so the 1 added to the denominator in the above formula can be ignored, that is,

[0103]

[0104] It can be seen that the probability of node i being selected as a consensus node is related to its threshold TH i Negatively correlated. Now establish the threshold TH i With credit value CR i Dependencies between

[0105]

[0106] Obviously, under the above functional relationship, the higher the credit value, the greater the probability of being selected as a consensus node. The adjustable parameter α determines the maximum possible probability of each node in the election group being selected as a consensus node. BRIEF DESCRIPTION OF THE DRAWINGS

[0107] Figure 1 The overall framework of the grouping and evaluation mechanism of the present invention is presented.

[0108] Figure 2 A schematic diagram of the node grouping mechanism of the present invention is shown.

[0109] Figure 3 This shows the GPBFT consensus process under normal circumstances.

[0110] Figure 4 Demonstrates the GPBFT consensus process under abnormal circumstances.

[0111] Specific algorithm process

[0112] The following is a detailed description of the process of a GPBFT consensus round.

[0113] Before a consensus round begins, the membership of the consensus group and the election group rotates. The m nodes with the lowest mutual trust index in the consensus group enter the election group, while the m nodes with the highest trust value in the election group enter the consensus group. Subsequently, the system elects consensus nodes from the election group using the VRF method described in the Summary of the Invention. The nodes selected from the election group participate in the consensus process alongside all consensus group members.

[0114] After the rotation and election process is complete, a new round of consensus begins. Under normal circumstances, the GPBFT process is divided into three phases: Pre-prepare, Prepare, and Commit. However, in abnormal situations, such as when the master node is unresponsive or responding maliciously, the GPBFT consensus process adds two new phases: Peer-prepare and Peer-commit. The GPBFT execution order is Pre-prepare, Prepare, Commit, Peer-prepare, and Peer-commit, and under normal circumstances, the system only needs to execute the Pre-prepare, Prepare, and Commit phases. In abnormal situations, if a replica node fails to receive a response from the master node during the Commit phase, a timeout mechanism is triggered, and each replica node initiates the Peer-prepare phase.

[0115] In the following description, we will just satisfy the number of Byzantine nodes f and the total number of consensus nodes N. The consensus process is described under the assumption of this tolerable worst-case scenario.

[0116] As described in the invention, in GPBFT, nodes are divided into two categories: consensus nodes and background nodes. Consensus nodes are further divided into master nodes and replica nodes. There is only one master node in each consensus round.

[0117] First, let’s explain the Pre-prepare phase. In a blockchain system using GPBFT, we denote the block with height as B. heightIn the Pre-prepare phase, the master node packages the block B to be released. height+1 , where height represents the height of the most recent block on the chain. After packaging the block, the master node sends a Pre-prepare message to all replica nodes to publish the block. The format of the Pre-prepare message is

[0118] <<PRE_PREPARE,view,height+1,dig,p> ,B height+1 >σ p .

[0119] In the message, the PRE_PREPARE field records the algorithm stage of the message, view indicates the current view number, and dig indicates block B. height+1 Hash value summary Hash(B height+1 ), p represents the master node number, σ p Indicates the master node's signature on the Pre-prepare message.

[0120] Next, let's explain the Prepare phase. Let's say the replica node is numbered i. After receiving the Pre-prepare message from the master node, node i verifies the Pre-prepare message according to the following criteria:

[0121] ①Digital signature σ p The signature verification is passed;

[0122] ② In view numbered view, node i has not received any other Pre-prepare messages;

[0123] ③The current view number is determined to be view;

[0124] ④dig confirms it is B height+1 Get the hash value result;

[0125] ⑤Packed into B height+1 All transactions are valid and legal.

[0126] If all the above verifications are passed, node i sends a Prepare message to the master node as feedback. The format of the Prepare message is

[0127] <<PREPARE,view,height+1,dig,i> ,VT(B height+1 ,i,true)τ i >σ i ,

[0128] Among them, VT(B height+1,i,true) represents the vote of node i, which means node i agrees with block B height+1 On the contrary, VT(B height+1 ,i,false) represents a negative vote, meaning that node i disagrees with block B height+1 It is worth mentioning that the affirmative vote VT(B height+1 ,i,true) also carries the digital signature τ of node i i , the purpose is to prevent other nodes in the system from impersonating node i to vote.

[0129] Next, we describe the Commit phase. After receiving the Prepare message from node i, the master node p verifies the message according to the following criteria:

[0130] ①Digital signature σ i The signature verification is passed;

[0131] ② Node i’s vote in favor VT(B height+1 ,i,true)τ i Signature τ i The verification is passed;

[0132] ③The values of the view, height+1, and dig fields are consistent with those in the Pre-prepare message.

[0133] If all the above verifications are passed, the master node p will cache the Prepare message from node i into the log, otherwise it will discard the Prepare message from node i. If the master node p successfully receives at least 2f+1 Prepare messages containing affirmative votes sent by different nodes, it will package all the affirmative votes in the Prepare messages belonging to this round of consensus in the log and generate certificate C (B height+1 ). Subsequently, the master node sends a Commit message to all other consensus nodes. The format of the Commit message is

[0134] <<COMMIT,view,height+1,dig,p> ,C(B height+1 )>σ p .

[0135] At this time, since it has received votes from no less than two-thirds of the nodes, it is confirmed that no less than two-thirds of the nodes in the entire network agree to put the block on the chain, and the master node p can already height+1 to synchronize.

[0136] After receiving the Commit message sent by the master node, the replica node i verifies the Commit message according to the following standards:

[0137] ①Digital signature σp The signature verification is passed;

[0138] ②The values of the view, height+1, and dig fields are consistent with those in the Pre-prepare message;

[0139] ③Certificate C(B height+1 ) contains no fewer than 2f+1 votes in favor, and the digital signature of each vote in favor in the certificate is valid.

[0140] If all the above verifications are passed, node i can also pass the certificate C (B height+1 ) indicates that at least two-thirds of the consensus nodes in the system have agreed to block B. height+1 At this point, node i can also check block B height+1 to synchronize.

[0141] Then, when all normal nodes in other consensus nodes have received and successfully verified the Commit message, B height+1 On-chain, this round of consensus is successful.

[0142] If a round of GPBFT consensus process is successfully completed through only three stages: Pre-prepare, Prepare, and Peer-prepare, then compared with PBFT's O(n 2 ), the time complexity of GPBFT is reduced to O(n).

[0143] Thus far, we have fully described the GPBFT consensus process, which has a time complexity of O(n) under normal circumstances. However, systems using GPBFT may also face abnormal situations such as the master node failing and becoming unresponsive during a consensus round.

[0144] The Peer-prepare phase is now explained. In GPBFT, to cope with unusual situations, if a replica node i does not receive a Commit message from the master node p for a certain period of time during the Commit phase, a timeout mechanism is triggered and the peer-prepare phase is entered. To prevent some replica nodes in the system from exiting the consensus process after the Commit phase is successfully completed, and thus being unable to participate in the subsequent Peer-prepare and Peer-commit backup phases, GPBFT stipulates that after the Commit phase is completed, even if the replica node has synchronized with B height+1 The node also needs to receive the approval certificate C(B height +1) is cached in the log and continues to monitor the blockchain system for a period of time. If other replica nodes broadcast the Peer-prepare message, they will immediately cooperate and participate in the Peer-prepare phase.

[0145] In the Peer-prepare phase, the node i whose timeout mechanism is triggered sends a Peer-prepare message to all other consensus nodes. The format of the Peer-prepare message is

[0146] <<PEER_PREPARE,view,height+1,dig,i> ,VT(B height+1 ,i,true)τ i >σ i .

[0147] Unlike the Prepare phase, the replica nodes in the Peer-prepare phase will collect votes from all consensus nodes in the system, thereby offsetting the impact of abnormalities in the master node on the consensus process.

[0148] Finally, we will explain the Peer-commit phase. After receiving the Peer-prepare message sent by replica node i, replica node j will verify the Peer-prepare message according to the following criteria:

[0149] ①Digital signature σ i The signature verification is passed;

[0150] ② Node i’s vote in favor VT(B height+1 ,i,true)τ i Signature τ i The verification is passed;

[0151] ③The values of the view, height+1, and dig fields are consistent with those in the Pre-prepare message.

[0152] After all the above verifications are passed, node j should take different actions according to the two different situations.

[0153] In the first case, if node j has received certificate C(B height+1 ), it means that node j has received the Commit message sent by the primary node p. At this time, node j sends a message containing C(B height+1 ) of the Peer-commit message. The format of the Peer-commit message is

[0154] <<PEER_COMMIT,view,height+1,dig,j> ,C(B height+1 )>σ j .

[0155] In this case, since node j receives the certificate C(B height+1 ) can only come from the master node, so the master node must already have the approval ticket certificate, and node j does not need to send it repeatedly to the master node.

[0156] In the second case, if node j has not received a certificate of approval votes, it will first wait for messages from other consensus nodes in the system until it successfully verifies at least 2f+1 Peer-prepare messages. Node j then collects all the approval votes in the Peer-prepare messages it has received and successfully verified, and generates a certificate C (B height+1 ,j), and broadcast the data containing C(B height+1 ,j) of the Peer-commit message. The format of the Peer-commit message is

[0157] <<PEER_COMMIT,view,height+1,dig,j> ,C(B height+1 ,j)>σ j .

[0158] Node k that receives the Peer-commit message will verify it according to the following criteria:

[0159] ①Digital signature σ j The signature verification is passed;

[0160] ②The values of the view, height+1, and dig fields are consistent with those in the Pre-prepare message;

[0161] ③Certificate C(B height+1 ,j) Contains no less than 2f+1 votes in favor, and the signature of each vote in favor is valid.

[0162] If all the above verifications are passed, node k can know through the approval certificate that no less than two-thirds of the consensus nodes in the blockchain network have agreed to block B. height+1 The system reaches a consensus. Then, node k can synchronize B height+1 If all normal nodes have successfully verified at least one Peer-commit message, then block B height+1 On-chain, a round of GPBFT consensus was successfully completed.

Claims

1. A fault-tolerant consensus method GPBFT based on dynamic grouping and trusted evaluation, characterized by: Includes the following sections: ① Dynamically divide the nodes in the blockchain network into consensus group, election group, and suspicious group, where the number of nodes in the consensus group is constant as parameter C; ② Dynamically rotate nodes based on mutual trust index and credit value. After each round of consensus, the m nodes with the lowest mutual trust index in the consensus group will be downgraded to the election group, and the m nodes with the highest credit value in the election group will be upgraded to the consensus group; the suspicious group nodes must be upgraded to the consensus group when their credit value is higher than the threshold CR. r And they can only return to the election group after the freeze period ends; ③ The credit value is calculated by weighting the performance score and the trust score. The trust score is generated by normalizing the node's independent score through a specific function; the performance score is calculated by weighting the normalized CPU frequency, memory capacity, memory frequency, and hard disk capacity. ④ The mutual trust index is a normalized value generated by iterative interaction scores between nodes, which quantifies the degree of trust that the member nodes of the consensus group have in the consensus group as a whole; ⑤GPBFT adjusts the threshold TH based on the credit value from the election group based on the verifiable random function i , to adjust the probability of a node being selected as a consensus node; ⑥ Under normal circumstances, the GPBFT consensus process includes three stages: Pre-prepare, Prepare, and Commit. The master node is rotated among the consensus group members according to the consensus group number. Abnormal situations will trigger the Peer-prepare and Peer-commit stages, and multiple nodes will collaborate to collect votes to reach a system consensus.

2. The fault-tolerant consensus method according to claim 1, characterized in that: In the mechanism whereby the consensus group members take turns to serve as the master node: Each consensus group number is a "position," ranging from 0 to C-1, and each member of a consensus group has a consensus group number. In each round of GPBFT consensus, the member with consensus group number 0 becomes the master node. The next round, the member with consensus group number 1 becomes the master node. And so on. After the member with consensus group number C-1 becomes the master node, the member with consensus group number 0 becomes the master node in the next round.

3. The fault-tolerant consensus method according to claim 1, characterized in that: In the dynamic rotation mechanism: The m original election group members transferred into the consensus group randomly occupy the consensus group number positions of the m original consensus group members that were demoted.

4. The fault-tolerant consensus method according to claim 1, characterized in that: The calculation of the mutual trust index includes: (I) Record the positive score K between the consensus group nodes ij and negative score M ij ; (II) According to the trust difference W ij =K ij -M ij Construct a matrix for iterative calculation and generate the final trust vector through Markov chain iterative convergence; (III) The maximum value in the trust vector is used as the calculation standard for the mutual trust index.

5. The fault-tolerant consensus method according to claim 1, characterized in that: The increase and decrease rules of the independent score RS include: (I) ΔRS0 increases when a node correctly participates in a round of consensus; (II) Reduce ΔRS1 when the node does not respond due to timeout; (III) Reduce ΔRS2 when a node sends illegal information; (IV) When non-consensus nodes passively receive consensus results, ΔRS3 is increased; (V) The above four values satisfy ΔRS2>>ΔRS1>ΔRS0>ΔRS3.

6. The fault-tolerant consensus method according to claim 1, characterized in that: The upper and lower limits of the independent score RS are as follows: (I) Reaching the upper limit RS T Then jump to the intermediate value RS R ; (II) Reaching the lower limit RS B It will stop at RS B , and will not continue to decrease.

7. The fault-tolerant consensus method according to claim 1, characterized in that: The trust score Re i The generation formula is: Where q is an adjustable parameter for the transverse stretching ratio.

8. The fault-tolerant consensus method according to claim 1, characterized in that: The VRF generation step includes: (I) Rolling parameter R based on elliptic curve view Signature (II) Generate a random value RA(i) through the hash signature result and verify its validity.

9. The fault-tolerant consensus method according to claim 1, characterized in that: The threshold TH i With credit value CR i The functional relationship is: Where α is an adjustable parameter that controls the maximum probability of an election group node being selected as a consensus node.

10. The fault-tolerant consensus method according to claim 1, characterized in that: In the consensus process: (I) Pre-prepare stage: The master node broadcasts the block; (II) In the Prepare phase, the replica node sends a positive vote after verification; (III) Commit phase: The master node collects no less than 2f+1 affirmative votes, generates a certificate, and broadcasts it; (IV) In abnormal situations, the Peer-prepare and Peer-commit phases are triggered, and the replica nodes broadcast and collect affirmative votes and generate certificates to reach a consensus.

Images