CN114938292B - Multi-level optimization PBFT consensus method based on node credibility - Google Patents
Multi-level optimization PBFT consensus method based on node credibility Download PDFInfo
- Publication number
- CN114938292B CN114938292B CN202210445397.XA CN202210445397A CN114938292B CN 114938292 B CN114938292 B CN 114938292B CN 202210445397 A CN202210445397 A CN 202210445397A CN 114938292 B CN114938292 B CN 114938292B
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- nodes
- message
- backup
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention belongs to the technical field of block chain consensus mechanisms, and particularly relates to a multi-level optimization PBFT consensus method based on node credibility; the method comprises the following steps: performing reliability evaluation on the nodes to obtain reliability scores of the nodes; performing node role attribute distribution and hierarchical structure division according to the reliability scores of the nodes to obtain a node consensus model; carrying out node consensus according to the node consensus model; when a new node is added or an old node is withdrawn, updating a node consensus model by adopting a dynamic node access management method; the invention can effectively reduce the traffic in the consensus process and improve the expandability of the system; when a new node is added or an old node is withdrawn, the system does not need to be restarted, and the requirements of a real application scene can be met; and the agent nodes are selected through the credibility scoring, so that the probability of view switching is reduced, the consensus efficiency and the safety of the system are improved, and the practicability of the blockchain system is improved.
Description
Technical Field
The invention belongs to the technical field of block chain consensus mechanisms, and particularly relates to a multi-level optimization PBFT consensus method based on node credibility.
Background
The nature of blockchain is a decentralized distributed ledger database. The problem that the data monopoly and the security of the traditional centralized system are poor can be solved. The method integrates the technical principles of network communication, consensus algorithm, cryptography foundation and the like, has the characteristics of non-falsification and easy verification, and is greatly developed in the fields of finance, internet of things, notarization and the like. The consensus algorithm is used as a block chain bottom layer core mechanism and is responsible for ensuring that all nodes in the system agree on the transaction sequence packed in a specific time, avoiding the problem of information asymmetry and playing an important role in realizing data sharing and data consistency of a distributed system.
The blockchain system is based on the differences of application scenes and the differences of the attributes and access conditions of all participants in the system. Generally, the types of public chains, alliance chains and private chains can be classified. The public blockchain means that all participants can join the system, are not constrained by any condition, and are completely decentralised; the alliance block chain is managed by a plurality of institutions together, nodes can join the system after identity authorization, and the alliance block chain belongs to partial decentralization; private blockchains are only used by individuals or single organizations, are rarely open to the outside, discard the decentralization feature, and belong to a decentralization system. Among the three types of architectures, the alliance blockchain has a local centralization characteristic, can allow a plurality of organization organizations to cooperate together, meets the actual application scene, has strong controllability and is a current mainstream research architecture. The PBFT (practical bayer fault tolerance) algorithm is the most commonly adopted and widely applied core consensus algorithm in the current alliance chain.
The PBFT algorithm reduces the algorithm complexity from an exponential level to a polynomial level, so that the Bayesian fault-tolerant algorithm has practical feasibility. However, the following problems exist, which limit the consensus efficiency and the application scenario: firstly, the PBFT algorithm requires all nodes in the system to participate in a consensus process, and realizes data consistency through a three-stage consensus protocol, so that after the number of the nodes reaches a specific threshold, the system performance is greatly reduced along with the increase of the number of the nodes, and the system expandability is poor; secondly, the PBFT algorithm cannot dynamically sense node change, and when a new node is added or an old node is withdrawn, the system is restarted, so that the requirements of a real application scene are difficult to meet; and finally, the algorithm selects the main node through a simple formula, so that the Bayesian and the honest nodes have the opportunity of equally selecting the main node, the probability of view switching is increased, and the consensus efficiency and the safety of the system are influenced.
Disclosure of Invention
Aiming at the defects existing in the prior art, the invention provides a multi-level optimization PBFT consensus method based on node credibility, which comprises the following steps:
s1: performing reliability evaluation on the nodes to obtain reliability scores of the nodes;
s2: performing node role attribute distribution and hierarchical structure division according to the reliability scores of the nodes to obtain a node consensus model; the character attribute comprises an agent node and a backup node, the hierarchical structure comprises a first-level consensus layer and a second-level consensus layer, the first-level consensus layer comprises a main consensus group, and the second-level consensus layer comprises at least one secondary consensus group;
s3: carrying out node consensus according to the node consensus model;
s4: when a new node is added or an old node is withdrawn, a dynamic node access management method is adopted to update the node consensus model.
Preferably, the process of evaluating the reliability of the node includes:
s11: calculating basic configuration scores of nodes according to the number of CPU cores, the memory capacity of a computer and the capacity of a hard disk;
s12: calculating consensus credit value, activity degree and consensus success rate of the nodes; calculating the consensus score of the node according to the consensus credit value, the activity degree and the consensus success rate of the node;
s13: and calculating the credibility score of the node according to the basic configuration score and the consensus score of the node.
Further, the formula for calculating the consensus score of the node is:
R j ＝k 1 ρ j +k 2 p j +k 3 E j
wherein R is j Representing consensus score, ρ, of node j j Represents the activity level of the node j, p j Represents the consensus success rate of node j, E j Representing the consensus reputation value, k, of node j 1 Represents a first regulatory factor, k 2 Representing the second regulatory factor, k 3 Represents a third adjustment factor, lambda represents an activity factor, n represents the number of consensus times a node participates in, n success Indicating the consensus number of successful completion of the job by the node.
Further, the formula for calculating the reliability score of the node is:
C j ＝K 1 B j +K 2 R j
wherein C is j Representing the confidence score of node j, B j Representing the base configuration score of node j, R j Representing consensus scores for nodes j, K 1 Representing the first weight, K 2 Representing a second weight.
Preferably, the process of obtaining the node consensus model includes:
s21: setting the number M of groups, sequencing the reliability scores of the nodes in a high-to-low order, taking M nodes before sequencing the reliability scores as proxy nodes and the rest nodes as backup nodes;
s22: carrying out hierarchical structure division according to the number of the proxy nodes and the backup nodes to obtain a node consensus model;
s23: after each consensus, reconstructing a node consensus model.
Further, the hierarchical structure division process includes: dividing all proxy nodes into a first-level consensus layer, and dividing all backup nodes into a second-level consensus layer; dividing the number of backup nodes by the number of proxy nodes to obtain a quotient n and a remainder r; dividing each group of nodes into sub-consensus groups of different proxy nodes by taking every n nodes as a group, and uniformly dividing the rest nodes into sub-consensus groups of r proxy nodes.
Preferably, the process of node consensus comprises:
s31: the client node sends a request message to all proxy nodes in the main consensus group;
s32: the agent node receives the request message and verifies the identity of the client according to the request message, and after the verification is passed, the agent node sends a pre-preparation message to all backup nodes in the secondary consensus group of the agent node;
s33: the backup node receives the pre-preparation message and verifies the correctness of the pre-preparation message, writes the message into a local log after the verification is passed, and broadcasts a new preparation message to other backup nodes in the same-time consensus group;
s34: the backup node broadcasts a confirmation message to other backup nodes in the same-time consensus group;
s35: each backup node feeds back a consensus result to the agent node to which the backup node belongs, and the agent node feeds back the consensus result to the client node; when the client receives the consensus result sent by more than half of the proxy node numbers, the system achieves consensus.
Preferably, the process of updating the node consensus model by adopting the dynamic node access management method comprises the following steps:
when a new node enters the system, the new node acquires the admission permission of each participating mechanism in the alliance block chain; the system carries out reliability evaluation on the new node to obtain reliability scores; distributing the new nodes into a secondary consensus group according to the reliability scores and broadcasting joining messages to all nodes in the system; each node receives the joining message and verifies the correctness of the message, and after verification, the node sends own information and signature to the new node; when the new node receives two-thirds messages exceeding the total node number of the system, the new node is successfully added into the system;
when the old node exits the system, the old node acquires the exit permission of each participating mechanism in the alliance block chain; the old node broadcasts an exit message to other nodes in the system; each node receives the exit message and verifies the correctness of the message, and after verification, the node sends an exit confirmation message to the old node; when the old node receives two-thirds exit confirmation messages exceeding the total number of the nodes of the system, the old node successfully exits the system.
The beneficial effects of the invention are as follows: according to the method, the nodes are subjected to role attribute division and hierarchy division, a consensus model is sequentially constructed, local consensus is firstly carried out on the consensus model, and then global consensus is carried out according to the local consensus; the invention can effectively reduce the traffic in the consensus process and improve the expandability of the system; when a new node is added or an old node is withdrawn, the system does not need to be restarted, and the requirements of a real application scene can be met; and the agent nodes are selected through the credibility scoring, so that the probability of view switching is reduced, the consensus efficiency and the safety of the system are improved, and the practicability of the blockchain system is improved.
Drawings
FIG. 1 is a flow chart of a multi-level optimization PBFT consensus method based on node credibility in the invention;
FIG. 2 is a schematic diagram of a node consensus model according to the present invention;
fig. 3 is a schematic diagram of a consensus flow of a multi-level optimization PBFT consensus method based on node credibility in the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The invention provides a multi-level optimization PBFT consensus method based on node credibility, which is shown in figure 1 and specifically comprises the following steps:
s1: and carrying out reliability evaluation on the nodes to obtain reliability scores of the nodes.
From basic configuration and consensus expression, evaluating node credibility, and scoring C by credibility as a result j The score is embodied as a data basis for the assignment of the attributes of the subsequent roles.
S11: calculating basic configuration score B of node according to CPU kernel quantity, computer memory capacity and hard disk capacity j The method comprises the steps of carrying out a first treatment on the surface of the The calculation process is as follows:
for the number of CPU cores, the memory capacity of a computer and the capacity of a hard disk, which are different in units, for convenience of unified calculation, the parameters are standardized by using a normalization formula, and the standardized values of the parameters are obtained:
wherein X is p Is the actual value, X b Is the value obtained by normalization, min (X p ) Representing the minimum value of the parameter, max (X p ) Representing the maximum value of the parameter.
And constructing a discrimination matrix according to the importance grades of the three parameters by adopting an analytic hierarchy process, and obtaining a weight vector conforming to the importance ranking according to the discrimination matrix. For example, the three aspect importance ratios are
The discrimination matrix can be constructed as: />
The weight vectors available are: [0.2 0.2 0.6]。
According to the weight vector and the normalized value X b Performing weight assignment on each parameter, and adding the parameters subjected to weight assignment to obtain a basic configuration score B of the node j 。
S12: calculating consensus credit value, activity degree and consensus success rate of the nodes; calculating consensus scores R of nodes according to the consensus reputation value, the activity degree and the consensus success rate of the nodes j The method comprises the steps of carrying out a first treatment on the surface of the The specific calculation process is as follows:
evaluating the behavior of the node in the consensus process by adopting a HonestPeer reputation model to obtain a consensus reputation value E j 。
The honeypeer reputation model aims to solve the problem that the EigenTrust model excessively depends on pre-trusted nodes, so that other honest nodes are marginalized. The HonestPeer model adopts the same standardized local reputation value mode as the EigenTrust model, and the improvement core is that the node with the highest reputation value is endowed with higher authority when the global reputation value is calculated; the node selection mode with the highest global reputation value is shown in the following formula:
t h (k) ＝max(t 1 (k) ,t 2 (k) ,…t n (k) )
wherein t is h (k) Representing the global reputation value of node h.
In the HonestPeer model, honest nodes have higher positions, and if the honest nodes are in a pre-trusted node set p, each node in the p still has great influence when determining the trust values of other nodes; however, if the honest node is not in the set p, the influence of each node in p is weakened, the honest node can exert higher influence, and the global reputation value of the node i can be calculated by using the following formula:
wherein C is ni Representing p i The value of a can be calculated by the following formula:
taking the global reputation value of the normalized node i as a consensus reputation value E of the node j 。
The activity degree refers to whether a node is actively involved in the consensus process, and the calculation formula is as follows:
where ρ represents the activity level of the node, λ represents the activity factor, and n represents the consensus number of participation of the node.
The consensus success rate refers to the ratio of the successful completion task to the total task in the consensus process of the participation of the nodes, and the calculation formula is as follows:
wherein p represents consensus success rate, n success Indicating the consensus number of successful completion of the job by the node.
Calculating consensus scores R of nodes according to the consensus reputation value, the activity degree and the consensus success rate of the nodes j The calculation formula is as follows:
R j ＝k 1 ρ j +k 2 p j +k 3 E j
wherein R is j Representing consensus score, ρ, of node j j Represents the activity level of the node j, p j Represents the consensus success rate, k of the node j 1 Represents a first regulatory factor, k 2 Representing the second regulatory factor, k 3 Representing a third regulatory factor; the size of the adjustment factor is defined in terms of the trust level of the federated blockchain system.
S13: scoring B according to the basic configuration of a node j Consensus score R j Calculating reliability score C of node j The method comprises the steps of carrying out a first treatment on the surface of the The calculation formula is as follows:
C j ＝K 1 B j +K 2 R j
wherein C is j Representing the confidence score, K, of node j 1 Representing the first weight, K 2 Representing a second weight; in determining the two weights K 1 And K 2 In the size, although the higher the basic configuration of the node is, the faster the information transfer speed is, and the better the system performance is, in order to resist the risk that malicious nodes are gathered and attack is performed by using high configuration equipment, the proportion of the basic configuration of the node in the node reliability evaluation should not be excessively high. Thus, the dynamic reliability of the node in the consensus process should be a higher percentage than the basic configuration in terms of evaluating the reliability, i.e. the weight factor should satisfy (K 1 ＜K 2 ) Conditions of K 1 And K 2 The specific numerical value of (2) is reasonably valued according to the actual situation.
S2: performing node role attribute distribution and hierarchical structure division according to the reliability scores of the nodes to obtain a node consensus model; the character attribute comprises a proxy node and a backup node, the hierarchical structure comprises a primary consensus layer and a secondary consensus layer, the primary consensus layer comprises a primary consensus group, and the secondary consensus layer comprises at least one secondary consensus group.
S21: setting the number M of groups, sequencing the reliability scores of the nodes in a high-to-low order, taking M nodes before sequencing the reliability scores as proxy nodes and the rest nodes as backup nodes.
The proxy node is used as a member of the primary consensus group, is responsible for receiving the request message from the client, and serves as a consensus process for leading the belonging consensus group in the secondary consensus layer by the primary node. The main work includes: broadcasting request information to each backup node in the group, packaging verification information from each backup node, feeding back the final result to the client node, and the like.
The backup node is a participant in the consensus process of each consensus group of the secondary consensus layer, and is other nodes except the proxy node in the system. And the method is responsible for completing the consensus verification work of the message in the belonging consensus group under the lead of the proxy node, and feeding back the consensus result to the proxy node after the verification is completed.
S22: carrying out hierarchical structure division according to the number of the proxy nodes and the backup nodes to obtain a node consensus model; as shown in fig. 2, the following are specifically included:
dividing all proxy nodes into a first-level consensus layer, and dividing all backup nodes into a second-level consensus layer; dividing the number of backup nodes by the number of proxy nodes to obtain a quotient n and a remainder r; dividing each group of nodes into sub-consensus groups of different proxy nodes by taking every n nodes as a group, and uniformly dividing the rest nodes into sub-consensus groups of r proxy nodes; preferably, the nodes in each group are divided into corresponding sub-consensus groups according to the reliability score ranking of the proxy nodes, and the remaining nodes are evenly distributed to the corresponding first r proxy nodes according to the reliability score ranking.
For example, assume that there are N nodes in the system, and all nodes are grouped into M consensus groups. After reliability score descending arrangement, selecting the first M nodes with highest scores as proxy nodes, constructing a main consensus group in a first-level consensus layer, and merging the rest nodes into a secondary consensus group led by each proxy node in a second-level consensus layer according to a score sequence:
firstly, dividing N-M backup nodes into M parts according to the reliability score ranking, wherein each part comprises N backup nodes, dividing the M parts of backup nodes into corresponding proxy nodes according to the reliability score ranking, for example, dividing the N backup nodes with the highest scores into sub-consensus groups of the proxy nodes with the highest reliability scores, dividing the rest r backup nodes into the first r proxy nodes which are corresponding to the backup nodes with the highest scores according to the reliability score ranking, for example, dividing the backup node with the highest scores in the r backup nodes into sub-consensus groups of the proxy nodes with the highest reliability scores; the sub-consensus group of each proxy node is subdivided into a backup node.
If the total number N of nodes is smaller than the group number M, the single-layer system structure of the original PBFT algorithm is directly adopted, and layering grouping is not needed. If the total number of nodes N is greater than the number of groups M, the hierarchical packet improvement described above may be performed.
S23: after each consensus, reconstructing a node consensus model.
Judging whether the consensus request is ended or not, if the consensus request is not ended, carrying out reliability assessment on the nodes again according to the performances of each node in the consensus process after each round of consensus, updating a reliability grading list, constructing a node consensus model, and carrying out next consensus work according to the reconstructed node consensus model.
S3: and carrying out node consensus according to the node consensus model. As shown in fig. 3, the following are specifically included:
s31: request phase: the client node sends a request message to all proxy nodes in the main consensus group; the format of the request message is:
wherein PREQUST is a message type identifier of the request message, representing the message as the request messageThe method comprises the steps of carrying out a first treatment on the surface of the m represents a request message, t represents a time stamp, σ c Representing the signature of client node c.
S32: pre-rrepore stage: the agent node receives the request message and verifies the identity of the client according to the request message, and after the verification is passed, the agent node sends a pre-preparation message to all backup nodes in the secondary consensus group of the agent node;
after receiving the request message from the client, the proxy node i verifies the identity of the client and distributes a serial number n for the request message; after the verification is passed, the preparation message is sent to all backup nodes in the secondary consensus group led by the proxy node in the secondary consensus layer; the format of the pre-prepare message is:
wherein PRE-PREPARE is the message type identifier of the PRE-preparation message, representing that the message is a PRE-preparation message, v represents the current view number, n represents the node number, d requests the abstract of message m, σ i Representing the signature of the proxy node i.
S33: rrepare phase: the backup node receives the pre-preparation message and verifies the correctness of the pre-preparation message, writes the message into a local log after the verification is passed, and broadcasts a new preparation message to other backup nodes in the same-time consensus group;
after receiving the pre-prepared message, the backup node j verifies the correctness of the message, writes the message into a local log after the verification is passed, and broadcasts a new prepared message to other backup nodes in the same-time consensus group; after receiving more than 2f consistent preparation messages (new preparation messages) sent by different backup nodes, including the self, the preparation stage is completed; f represents the number of wrongly generated nodes; the format of the new preparation message is:
wherein PREPARE is a message type identifier of the PREPARE message, representing that the message is a PREPARE message; d (m)) Representation, sigma j Representing the signature of backup node j.
S34: commit phase: the backup node broadcasts a confirmation message to other backup nodes in the same-time consensus group;
the backup node j broadcasts a confirmation message to all nodes except the node in the secondary consensus group, and when the node receives (2f+1) pieces of consistency confirmation messages (confirmation messages) containing the node, the messages reach consensus in the secondary consensus group; the format of the acknowledgement message is:
s35: stage Reply: each backup node feeds back a consensus result to the agent node to which the backup node belongs, and the agent node feeds back the consensus result to the client node; when the client receives the consensus result sent by more than half of the proxy node numbers, the system achieves consensus;
after the intra-group consensus is finished, each backup node feeds back a final consensus result to the affiliated proxy node. When the proxy node i receives more than (f+1) pieces of consistency feedback (consensus result), the second-level consensus layer agrees with the message. The proxy node feeds back the consensus result to the client node, and when the client receives the consensus result sent by the proxy node in more than half of the main consensus groups, the system achieves consensus.
S4: when a new node is added or an old node is withdrawn, a dynamic node access management method is adopted to update the node consensus model.
When a new node enters the system, the new node acquires the admission permission of each participating mechanism in the alliance block chain;
after obtaining admission permission, the system firstly performs credibility assessment on the new node (the node has static basic configuration scores at the moment);
distributing the new node into a secondary consensus group according to the reliability score and broadcasting a joining message to all nodes in the system, wherein the joining message is in the following format:
＜＜JOIN,score,m＞σ m ＞σ p
wherein JOIN is a message type identifier of a new node JOIN message, representing that the message is a new node JOIN message; score represents the confidence score of the new node, m represents the node number assigned by the new node, σ m Representing new node signature, sigma p Representing the signature of the consensus master node.
After each node receives the joining message, immediately verifying the correctness of the message content, and after the verification is passed, transmitting self-related information and a signature to a new node for local verification and storage, so that the new node can smoothly communicate with other nodes and timely participate in subsequent work; wherein the related information includes node numbers, belonging groups and confidence scores.
When the new node receives more than 2N/3 messages, the joining message has obtained authentication of most of the nodes in the system, representing that the new node successfully joins the system, wherein N is the total number of nodes in the system.
When the old node exits the system, the old node acquires the exit permission of each participating mechanism in the alliance block chain;
after obtaining the exit permission, the old node needs to broadcast the exit information of the node to other nodes in the system; the format of the exit message is:
＜＜LEAVE,group,n＞σ n ＞σ p
wherein LEAVE is a message type identifier of an old node exit message, representing that the message is an old node exit message; group represents the sub-consensus group to which the node belongs.
And after the verification is passed, the old node N receives more than 2N/3 exit confirmation messages, and the node considers that the exit message is confirmed by most nodes, and the node successfully exits the system.
According to the method, the nodes are subjected to role attribute division and hierarchy division, a consensus model is sequentially constructed, local consensus is firstly carried out on the consensus model, and then global consensus is carried out according to the local consensus; the invention can effectively reduce the traffic in the consensus process and improve the expandability of the system; when a new node is added or an old node is withdrawn, the system does not need to be restarted, and the requirements of a real application scene can be met; and the agent nodes are selected through the credibility scoring, so that the probability of view switching is reduced, the consensus efficiency and the safety of the system are improved, and the practicability of the blockchain system is improved.
While the foregoing is directed to embodiments, aspects and advantages of the present invention, other and further details of the invention may be had by the foregoing description, it will be understood that the foregoing embodiments are merely exemplary of the invention, and that any changes, substitutions, alterations, etc. which may be made herein without departing from the spirit and principles of the invention.
Claims (3)
1. A multi-level optimization PBFT consensus method based on node credibility is characterized by comprising the following steps:
s1: performing reliability assessment on the node comprises the following steps:
s11: calculating basic configuration scores of nodes according to the number of CPU cores, the memory capacity of a computer and the capacity of a hard disk;
s12: calculating consensus credit value, activity degree and consensus success rate of the nodes; calculating the consensus score of the node according to the consensus credit value, the activity degree and the consensus success rate of the node; the formula for calculating the consensus score of the node is:
R j ＝k 1 ρ j +k 2 p j +k 3 E j
wherein R is j Representing consensus score, ρ, of node j j Represents the activity level of the node j, p j Represents the consensus success rate of node j, E j Consensus message representing node jReputation value, k 1 Represents a first regulatory factor, k 2 Representing the second regulatory factor, k 3 Represents a third adjustment factor, lambda represents an activity factor, n represents the number of consensus times a node participates in, n success Indicating the consensus times of successful completion of the work by the node;
s13: calculating the credibility score of the node according to the basic configuration score and the consensus score of the node; the formula for calculating the reliability score of the node is:
C j ＝K 1 B j +K 2 R j
wherein C is j Representing the confidence score of node j, B j Representing the base configuration score, K, of node j 1 Representing the first weight, K 2 Representing a second weight;
s2: performing node role attribute distribution and hierarchical structure division according to the reliability scores of the nodes to obtain a node consensus model; comprising the following steps:
s21: setting the number M of groups, sequencing the reliability scores of the nodes in a high-to-low order, taking M nodes before sequencing the reliability scores as proxy nodes and the rest nodes as backup nodes;
s22: carrying out hierarchical structure division according to the number of the proxy nodes and the backup nodes to obtain a node consensus model; the process of hierarchical structure division comprises the following steps: dividing all proxy nodes into a first-level consensus layer, and dividing all backup nodes into a second-level consensus layer; dividing the number of backup nodes by the number of proxy nodes to obtain a quotient n and a remainder r; dividing each group of nodes into sub-consensus groups of different proxy nodes by taking every n nodes as a group, and uniformly dividing the rest nodes into sub-consensus groups of r proxy nodes;
s23: reconstructing a node consensus model after each consensus;
the character attribute comprises an agent node and a backup node, the hierarchical structure comprises a first-level consensus layer and a second-level consensus layer, the first-level consensus layer comprises a main consensus group, and the second-level consensus layer comprises at least one secondary consensus group;
s3: carrying out node consensus according to the node consensus model;
s4: when a new node is added or an old node is withdrawn, a dynamic node access management method is adopted to update the node consensus model.
2. The multi-level optimization PBFT consensus method based on node credibility as claimed in claim 1, wherein the process of performing node consensus includes:
s31: the client node sends a request message to all proxy nodes in the main consensus group;
s32: the agent node receives the request message and verifies the identity of the client according to the request message, and after the verification is passed, the agent node sends a pre-preparation message to all backup nodes in the secondary consensus group of the agent node;
s33: the backup node receives the pre-preparation message and verifies the correctness of the pre-preparation message, writes the message into a local log after the verification is passed, and broadcasts a new preparation message to other backup nodes in the same-time consensus group;
s34: the backup node broadcasts a confirmation message to other backup nodes in the same-time consensus group;
s35: each backup node feeds back a consensus result to the agent node to which the backup node belongs, and the agent node feeds back the consensus result to the client node; when the client receives the consensus result of more than half the proxy node number, the system achieves consensus.
3. The multi-level optimization PBFT consensus method based on node credibility according to claim 1, wherein the process of updating the node consensus model by adopting the dynamic node access management method comprises the following steps:
when a new node enters the system, the new node acquires the admission permission of each participating mechanism in the alliance block chain; the system carries out reliability evaluation on the new node to obtain reliability scores; distributing the new nodes into a secondary consensus group according to the reliability scores and broadcasting joining messages to all nodes in the system; each node receives the joining message and verifies the correctness of the message, and after verification, the node sends own information and signature to the new node; when the new node receives two-thirds messages exceeding the total node number of the system, the new node is successfully added into the system;
when the old node exits the system, the old node acquires the exit permission of each participating mechanism in the alliance block chain;
the old node broadcasts an exit message to other nodes in the system; each node receives the exit message and verifies the correctness of the message, and after verification, the node sends an exit confirmation message to the old node; when the old node receives two-thirds exit confirmation messages exceeding the total number of the nodes of the system, the old node successfully exits the system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210445397.XA CN114938292B (en) | 2022-04-26 | 2022-04-26 | Multi-level optimization PBFT consensus method based on node credibility |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210445397.XA CN114938292B (en) | 2022-04-26 | 2022-04-26 | Multi-level optimization PBFT consensus method based on node credibility |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114938292A CN114938292A (en) | 2022-08-23 |
| CN114938292B true CN114938292B (en) | 2023-05-23 |
Family
ID=82863005
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210445397.XA Active CN114938292B (en) | 2022-04-26 | 2022-04-26 | Multi-level optimization PBFT consensus method based on node credibility |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114938292B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115622716B (en) * | 2022-12-19 | 2023-03-28 | 湖南天河国云科技有限公司 | Internet of things equipment identity authentication method based on block chain |
| CN117294720B (en) * | 2023-11-27 | 2024-02-20 | 江西农业大学 | Block chain consensus method, device, storage medium and equipment |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111858105A (en) * | 2020-08-26 | 2020-10-30 | 电子科技大学 | Personal archive permission chain management system and method based on improved multi-layer PBFT |
| CN112039964A (en) * | 2020-08-24 | 2020-12-04 | 大连理工大学 | Node reputation consensus method based on block chain |
| CN113259179A (en) * | 2021-06-18 | 2021-08-13 | 杭州云智声智能科技有限公司 | Byzantine fault-tolerant consensus method and system based on node scoring |
| CN113781218A (en) * | 2021-09-03 | 2021-12-10 | 桂林电子科技大学 | Grouping PBFT consensus algorithm based on feature trust |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200344111A1 (en) * | 2020-05-14 | 2020-10-29 | Rani Malhotra | System and method for obtaining consensus in a distributed ledger network |
-
2022
- 2022-04-26 CN CN202210445397.XA patent/CN114938292B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112039964A (en) * | 2020-08-24 | 2020-12-04 | 大连理工大学 | Node reputation consensus method based on block chain |
| CN111858105A (en) * | 2020-08-26 | 2020-10-30 | 电子科技大学 | Personal archive permission chain management system and method based on improved multi-layer PBFT |
| CN113259179A (en) * | 2021-06-18 | 2021-08-13 | 杭州云智声智能科技有限公司 | Byzantine fault-tolerant consensus method and system based on node scoring |
| CN113781218A (en) * | 2021-09-03 | 2021-12-10 | 桂林电子科技大学 | Grouping PBFT consensus algorithm based on feature trust |
Non-Patent Citations (2)
| Title |
|---|
| Yanjun Jiang.Scalable efficient byzantine fault tolerance.《IEEEXplore》.2020,全文. * |
| 基于信任委托的区块链分层共识优化;段靓;吕鑫;刘凡;;计算机工程(第10期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114938292A (en) | 2022-08-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114938292B (en) | Multi-level optimization PBFT consensus method based on node credibility | |
| CN111082943B (en) | Efficient block chain consensus method | |
| Yu et al. | Proof-of-QoS: QoS based blockchain consensus protocol | |
| Hassanzadeh-Nazarabadi et al. | Lightchain: A dht-based blockchain for resource constrained environments | |
| CN109871669A (en) | A kind of data sharing solution based on block chain technology | |
| Wang et al. | A comparative study of blockchain consensus algorithms | |
| EP4318362A1 (en) | Blockchain-based data processing method, apparatus and device, and storage medium | |
| CN111611315A (en) | Financial big data-oriented multi-branch tree structure block chain integrated optimization storage method | |
| CN112540926A (en) | Resource allocation fairness federal learning method based on block chain | |
| Wang et al. | Beh-Raft-Chain: a behavior-based fast blockchain protocol for complex networks | |
| Wang et al. | A trusted consensus fusion scheme for decentralized collaborated learning in massive IoT domain | |
| CN113438084A (en) | Green power source tracing method and system based on R-PBFT consensus algorithm and timestamp | |
| CN112769580A (en) | Block chain layered excitation consensus algorithm | |
| CN111798234B (en) | Lightweight block chain system and construction method | |
| CN112187866B (en) | Novel block chain consensus method based on shared storage | |
| Wang et al. | A trusted consensus scheme for collaborative learning in the edge ai computing domain | |
| CN114499890A (en) | Raft PBFT two-stage consensus mechanism based on node grouping in alliance chain | |
| CN114490020A (en) | Block chain fragmentation method and system and electronic equipment | |
| CN113886501A (en) | Block chain service module extension method based on multi-chain architecture | |
| CN112468552A (en) | Lightweight reputation consensus realization method of double-layer distributed block chain network model | |
| CN111858105A (en) | Personal archive permission chain management system and method based on improved multi-layer PBFT | |
| Wang et al. | An efficient, secured, and infinitely scalable consensus mechanism for peer-to-peer energy trading blockchain | |
| CN114978684B (en) | PBFT consensus method based on improved condensation hierarchical clustering | |
| CN112463881A (en) | Efficient block chain system and processing method for cloud edge aggregation computing environment | |
| Al-Musharaf et al. | Improving blockchain consensus mechanism via network clusters |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |