CN111629022B - Practical Byzantine fault-tolerant node setting method - Google Patents
Practical Byzantine fault-tolerant node setting method Download PDFInfo
- Publication number
- CN111629022B CN111629022B CN202010203490.0A CN202010203490A CN111629022B CN 111629022 B CN111629022 B CN 111629022B CN 202010203490 A CN202010203490 A CN 202010203490A CN 111629022 B CN111629022 B CN 111629022B
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- byzantine
- nodes
- type
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1031—Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention provides a practical Byzantine fault-tolerant node setting method, wherein a consensus message sent by a consensus node is received, and information of a first consensus node is extracted from the consensus message, wherein the first consensus node is a consensus node set for sending the consensus message; extracting an execution result of the consensus node according to the received consensus message, and dividing the first consensus node into a second type Byzantine node and a non-Byzantine node according to the execution result; extracting second common identification node information stored by a client, and obtaining a first type Byzantine node according to the first common identification node information and the second common identification node information; and performing first processing on the first type Byzantine node, and performing second processing on the second type Byzantine node. The invention distinguishes the different types of Byzantine nodes, adopts different processing forces for the different types of Byzantine nodes, can reserve non-malicious Byzantine nodes as much as possible, reduces the view change times, saves the online computing resources, eliminates the malicious fraudulent or attacked Byzantine nodes as much as possible, and ensures the safe and reliable operation of the system.
Description
Technical Field
The invention relates to the technical field of communication or computer, in particular to an improvement of a consensus process in a block chain, and especially relates to a practical Byzantine fault-tolerant node setting method.
Background
The consensus is the basis of all block chain technologies, the concept of block chain decentralization cannot be formed without the consensus, the block chain deployment modes include a public chain, a alliance chain and a private chain, and the block chain deployment modes correspond to a decentralization distributed system, a partial decentralization distributed system and a weak centralization distributed system. In decentralized distributed systems, a non-avoidable problem, i.e., consistency, is faced, where multiple hosts need to replicate states among themselves to achieve consistent state consensus by forming node sets.
The mainstream consensus commonly used at present mainly includes Pow workload certification, Pos equity certification, DPos share authorization certification mechanism, and PBFT (reactive Byzantine factory permission) practical Byzantine Fault tolerance.
The Pow workload proves that the process is the ore digging process of the bit coins, a random number meeting the rules is obtained through a large amount of calculation, namely, the accounting right of the transaction is obtained, data which needs to be recorded in the round is sent out, other nodes in the whole network are verified and then stored together, and meanwhile, a certain ore digging reward is obtained, namely a certain number of bit coins; the consensus has the characteristic of complete decentralization, the nodes are added and deleted completely freely without limitation, the shortcoming is that the computing power of most nodes is occupied, particularly, a large amount of resources are wasted due to ore digging, one transaction can be determined within one hour, and the period for achieving the consensus is long. The Pow equity certification is a slightly centralized consensus mechanism, interest which can be used as a judgment standard is allocated to the token of each node, the advantage of token concentration is formed, the speed of calculating random numbers is accelerated according to the proportion and duration of the token occupied by each node, consensus achievement time is shortened to a certain extent, calculation resources are saved, and a certain amount of calculation capacity is still needed. The DPos stock authorization proof mechanism is similar to stockholder voting, and a money holder throws out a certain number of nodes for verification and accounting, so that the advantage is that the number of nodes participating in verification and accounting can be greatly reduced, and the disadvantage is that the DPos stock authorization proof mechanism still depends on tokens which are not commonly used.
The PBFT practical Byzantine fault tolerance is commonly used in a alliance chain, the problem that the calculation amount of the consensus is too large is relieved to a certain extent, the copy of the state machine is used for copying, the problem that the original Byzantine fault tolerance is not high in efficiency is solved, the complexity is reduced from exponential level to polynomial level, the Byzantine fault tolerance is enabled to be feasible in the application of an actual system, the practical Byzantine is modeled through the state machine, the state machine copies the different nodes of a distributed system, the copy of each state machine stores the state of the consensus operation, generally, the node with the error or the malicious node is changed into the Byzantine node, the practical Byzantine fault tolerance can guarantee the correctness of the system under the condition that the number of the Byzantine nodes is less than one third, and the result of the consensus is obtained.
In the practical situation of using the practical Byzantine fault tolerance, communication between nodes is not completely reliable, delay and blockage can occur, errors and deviation can occur, downtime and disconnection can occur, even some nodes do harm, malicious fraud and attack can occur, and the nodes with the problems are called Byzantine nodes. Because the practical Byzantine fault tolerance has certain fault tolerance, when Byzantine nodes appear, the correct consensus process can still be completed under the condition that non-Byzantine nodes meet a certain number. In general, the amount of computation of the consensus process will increase greatly every time a node is added, and therefore, the number of consensus nodes participating in the consensus process is generally in a critical state, that is, in a case where an expected number of byzantine nodes can be tolerated, the number of non-byzantine nodes is in a relatively fragile state, and may be reduced to a number that cannot complete the consensus process at any time, for example, assuming that the expected number of byzantine nodes is f, the number of consensus nodes is generally set to 3f +1 in order to increase the operation speed. At this time, the number of byzantine nodes is f, the number of non-byzantine nodes is 2f +1, and the current consensus status is Weak authentication (Weak authentication), and in this case, if one non-byzantine node suddenly changes into a byzantine node, the whole consensus node set cannot normally complete the consensus process.
In order to solve the problem, some byzantine nodes need to be continuously deleted, and some non-byzantine nodes need to be continuously supplemented, in the prior art, a method for removing and supplementing the nodes is often adopted, and the nodes, no matter whether the nodes are disconnected, down, delayed, blocked, cheated, or attacked, can be directly deleted, or corresponding redundancy values or weighted values are set for the nodes, and the nodes are deleted under the condition that the redundancy values or the weighted values reach a certain threshold.
This operation often causes two situations. Firstly, due to environmental factors or capabilities of nodes, the nodes are not frequently problematic, for example, shading, fading, electromagnetic interference occur in a wireless environment, electrophoresis and electric arc occur in a wired environment, the bandwidth of the nodes is narrow, the machine speed is slow, and the nodes cannot complete the consensus process in time due to the reasons. Secondly, the nodes which are disconnected and crashed and the nodes which are fraudulently and attacked are not screened and processed in different ways, for example, some of the nodes which are disconnected and crashed are due to environmental factors or self-capability factors, and the situation that the consensus result cannot be fed back in time occurs, and after the environmental factors are normal or the processing speed is increased (for example, a machine opens too many processes, closes some processes after the speed is reduced, and the speed is recovered to be normal), the nodes are changed from the bypath nodes to the non-bypath nodes, and in this situation, the nodes do not need to be deleted, however, some malicious nodes which are fraudulently or attacked continuously release or feed back false consensus messages, so that not only limited computing resources are occupied and wasted, but also the robustness of the consensus node set is impacted.
In summary, the byzantine node includes two types of situations, one is a node caused by environmental factors or self-ability factors, and the other is a node which has the purpose of fraud or attack and specially maliciously destroys the consensus process. For the two situations, the prior art often adopts a cutting-off means, or the nodes may be directly deleted, or the nodes are deleted under the condition that the redundant value or the weighted value of the nodes reaches a certain threshold, that is, the prior art does not perform differential processing on the nodes of two different types, cannot rapidly delete malicious byzantine nodes, and does not have a certain fault-tolerant mechanism on non-malicious byzantine nodes.
Disclosure of Invention
To solve the technical problems described in the background art, the present invention provides a practical byzantine fault-tolerant node setting method. A classification mode is provided aiming at the Byzantine nodes under different conditions, the Byzantine nodes are divided into a plurality of different types, and different processing modes are adopted aiming at the different types of the Byzantine nodes. The main inventive content is as follows.
A practical Byzantine fault-tolerant node setting method is characterized by comprising the steps of receiving a consensus message sent by a consensus node, and extracting information of a first consensus node from the consensus message, wherein the first consensus node is a consensus node set for sending the consensus message; extracting an execution result of the consensus node according to the received consensus message, and dividing the first consensus node into a second type Byzantine node and a non-Byzantine node according to the execution result; extracting second consensus node information stored by a client, and obtaining a first type Byzantine node according to the first consensus node information and the second consensus node information; and performing first processing on the first type Byzantine node, and performing second processing on the second type Byzantine node.
The practical Byzantine fault-tolerant node setting method is characterized in that the client stores historical records of a first type of Byzantine node, a second type of Byzantine node and a non-Byzantine node.
The practical Byzantine fault-tolerant node setting method is characterized in that a threshold value of the storage time is set for the stored historical records.
The practical Byzantine fault-tolerant node setting method is characterized in that a third type Byzantine node is obtained according to the stored historical records, the currently obtained first type Byzantine node and the currently obtained second type Byzantine node, and third processing is carried out on the third type Byzantine node.
The utility model relates to a node setting method of Byzantine fault tolerance, which is characterized in that: the first processing of the first type Byzantine node is that reciprocal weighting is adopted as a first cost function of the node; the second processing of the second type byzantine node is to use exponential weighting as a second cost function for the node.
The utility model relates to a node setting method of Byzantine fault tolerance, which is characterized in that: the number of nodes in the first processing is one of parameters of a first cost function; the number of nodes in the second process is one of the parameters of the second cost function.
The method for setting the practical Byzantine fault-tolerant node is characterized in that the third processing on the third type Byzantine node is to adopt the product of reciprocal weighting and exponential weighting as the third price function of the node.
The practical Byzantine fault-tolerant node setting method is characterized in that the number of nodes in the third processing is used as one of the parameters of the third price function.
The practical Byzantine fault-tolerant node setting method is characterized in that a weight threshold value is set for the common identification node, when the value of a first cost function of the common identification node is lower than the set threshold value, the first type Byzantine node is deleted from the second common identification node, and/or when the value of a second cost function is lower than the set threshold value, the second type Byzantine node is deleted from the second common identification node set.
The practical Byzantine fault-tolerant node setting method is characterized in that a threshold value is set for the weight of the consensus node, and when the value of a third cost function of the consensus node is lower than the set threshold value, the third type Byzantine node is deleted from the consensus node set.
The practical Byzantine fault-tolerant node setting method is characterized in that the client can be replaced by a main common-identification node, a common-identification node set is stored on the main common-identification node, and when the main common-identification node goes down, and/or is disconnected, and/or is deleted, view conversion is started.
The practical Byzantine fault-tolerant node setting method is characterized in that the number of the currently available consensus nodes is monitored, and when the number of the consensus nodes is lower than the minimum number of the consensus nodes, the consensus nodes are supplemented and have redundant number of the consensus nodes.
The practical Byzantine fault-tolerant node setting method is characterized in that after the Byzantine nodes are deleted, broadcasting is carried out on the common nodes in a broadcasting mode.
The practical Byzantine fault-tolerant node setting method is characterized in that when the Byzantine nodes are deleted, if the main common identification node fails, the non-main common identification node deletes the Byzantine nodes first, and then the operation of changing the view is started, so that a new common identification node set and a new view are formed.
The practical Byzantine fault-tolerant node setting method is characterized in that after nodes are supplemented, the broadcasting is carried out on the consensus nodes in a broadcasting mode, and the consensus node set is updated and a new view is established.
According to the technical scheme, the invention distinguishes the different types of Byzantine nodes, namely the different types of Byzantine nodes are divided into a first type of Byzantine nodes and a second type of Byzantine nodes, wherein the first type of Byzantine nodes are caused by disconnection, downtime, delay, blockage and the like, and the second type of Byzantine nodes feed back wrong consensus messages possibly caused by fraud, attack and the like. Different operations are adopted for different types of Byzantine nodes, a light processing method is adopted for the Byzantine nodes caused by reasons such as outage or downtime, namely a relatively slow weighted cost function is adopted, a moderate processing method is adopted for the Byzantine nodes caused by reasons such as possible fraud or attack, namely a relatively fast weighted cost function is adopted, and after a weighted value reaches a certain threshold, the deleting operation is carried out on the Byzantine nodes. Through the technical scheme, non-malicious byzantine nodes can be reserved as much as possible, the view change times are reduced, online computing resources are saved, malicious fraudulent or attacked byzantine nodes are eliminated as much as possible, and the safe and reliable operation of the system is guaranteed.
Drawings
Figure 1 shows the flow of a practical byzantine fault tolerance in the prior art.
FIG. 2 shows a schematic diagram of an exemplary consensus node layout of the present invention.
Fig. 3 shows a schematic diagram of a flow of execution of the steps of an exemplary main embodiment of the present invention.
Fig. 4 shows a schematic diagram of an exemplary third class byzantine node deletion procedure in accordance with the present invention.
Fig. 5 shows a schematic diagram of an exemplary delete node flow of the present invention.
Detailed Description
The embodiment of the application provides a practical Byzantine fault-tolerant node setting method. Aiming at the Byzantine nodes under different conditions, a classification mode is provided, the Byzantine nodes are divided into a plurality of different types, different processing modes are adopted aiming at the Byzantine nodes of different types, different processing is carried out on malicious and non-malicious Byzantine nodes, the consumption of computing resources is reduced, and the safe and reliable operation of the system is ensured.
The terms in the abstract, the description, the claims, the drawings and the like (if any) are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order by virtue of the technical features. Features so used will be understood by those skilled in the art to be interchangeable under appropriate circumstances such that the embodiments described herein may be practiced in other sequences than as specifically illustrated or described herein. Moreover, the terms "comprises," "comprising," and any other variations thereof, are intended to cover other embodiments not necessarily limited to the explicitly recited steps, but may include other steps not explicitly recited or required for such processes, methods, and other steps.
The practical Byzantine fault tolerance comprises a plurality of basic nodes, including a client, a main consensus node and a replica node, wherein the main consensus node and the replica node are consensus nodes which need to execute a consensus process, and request and information are copied; the client, an initiator of the consensus process, initiates a request to the main consensus node, wherein the request comprises transaction information needing consensus, and the node can be the same node as the main consensus node in a block chain at times; the master consensus node starts a consensus process, generates a new block after receiving the request from the client and broadcasts the new block to each consensus node; the process of the consensus node verification block is to actually verify the request sent by the main consensus node, verify the request after receiving the request, and then broadcast the verification result to other consensus nodes including the main consensus node to execute the consensus process.
In the process of executing consensus, a combined mode of the main consensus node and the consensus node forms a view, and a consensus process is completed on the blocks on the view; at the end of consensus, if an acknowledgment is received that exceeds 2/3, it is called a checkpoint. The change of the view is started every time the main common knowledge node or the common knowledge node is changed, the change of the view is generally performed in a broadcasting mode, or the change of the view can be completed through common knowledge operation, for example, when the common knowledge nodes including the main common knowledge node have problems of downtime, disconnection and the like, a new view appears, and the new view selects a new main common knowledge node.
The prior art common recognition process of practical byzantine fault tolerance mainly comprises three stages, as shown in fig. 1, namely, a Pre-preparation (Pre-preparation), a preparation (preparation), and a Commit confirmation (Commit), and a Request (Request) and a Reply (Reply) are included before the three stages. In the pre-preparation stage, the main consensus node assigns a sequence number n to the request information sent by the client, and then broadcasts the request information to other consensus nodes. The format of the broadcast PRE-preparation information is < < PRE-PREPARE, v, n, d >, m >, wherein v represents a view number, n represents a sequence number allocated by a message carried in a request, m is a message requested by a client, and is uploaded to a block chain after reaching consensus, and d is summary information of the message m. When the consensus node of the network receives the pre-preparation message, the following conditions need to be satisfied: firstly, the signatures of the request message and the pre-prepared message are verified and the result is correct, wherein the digest information of the message m is the same as d; secondly, the view number of the current consensus node is the same as the view number v in the received pre-preparation information; third, the consensus node does not receive a message with sequence number n in the view with view number v, and the message digest d is not identical to the message with sequence number m. When the conditions are met, the consensus node receives the pre-preparation message and enters the next preparation stage. When the PRE-preparation information < < PRE-PREPARE, v, n, d >, m > received by the consensus node in the consensus node set, the consensus node enters a preparation stage, and sends a preparation message < PREPARE, v, n, d, i > to all the consensus nodes in the consensus node set, when the consensus node receives the preparation message, the following conditions need to be satisfied: firstly, whether the signature of the message is correct, secondly, whether the view numbers are consistent, and thirdly, whether the sequence number of the message is in the waterline, that is, the message cannot be advanced too much, the message which is still at the consensus node is continuously processed, and the sequence number of the message is lower than the waterline, so that the consensus process is entered. When the consensus node receives 2f +1 view numbers V (V1, V2, … …, V (2f +1)), the message sequence number n and the message digest d are both consistent with the preparation message of the pre-preparation phase message, the consensus node finishes the consensus processing of the preparation phase and enters the next submission phase. When the consensus node i needs to verify that (m, v, n, i) is correct, < COMMIT, v, n, D (m), i > is broadcast to other consensus nodes in the set of consensus nodes. When the consensus node receives the acknowledgement message, the following conditions need to be satisfied: first, the signature of the confirmation message is correct, second, the view number of the confirmation message is the same as the view number of the preparation phase, and third, the message sequence number n is within a specified range. When the above conditions are all satisfied, the confirmation message is accepted by the consensus node. If the consensus node receives 2f + l identical acknowledgement messages, the messages are acknowledged by most nodes in the set of consensus nodes.
In the reply phase, each consensus node sends Commit acknowledge information to the client and the consensus node will delete message sequences with timestamps smaller than t. When the client receives 2f + l identical reply messages, the client indicates that most of the consensus nodes in the network generate consensus results which are effective, namely, the practical Byzantine fault-tolerant consensus process initiated by the client is completed, and the corresponding messages are uploaded to the block chain.
In the above consensus process, if there is a problem in a consensus node (consensus node), that is, a byzantine node occurs, some of the byzantine nodes need to be deleted in order to enhance the robustness of the system, and in order to reasonably delete the byzantine nodes, the following implementation is mainly adopted.
Fig. 2 shows an example of a layout of a consensus node according to the present invention, where 201 is a peripheral device, which may be a terminal, a computer, an intelligent device, a machine communication device, etc., 202 is a client, and may also be a primary consensus node, 203 is a primary consensus node or a consensus node (replica node), 204 and 206 are consensus nodes (replica nodes).
Example one
The following steps, for example, all occur after completing a consensus process, assuming a total of N consensus nodes as the set of consensus nodes for this view. The implementation of this embodiment is described with reference to fig. 3.
Step S102, receiving a consensus message sent by a consensus node, and extracting first consensus node information from the consensus message, wherein the first consensus node is a set of consensus nodes sending the consensus message.
And the client C receives the consensus messages sent by the consensus nodes. Wherein, at least 2f +1 consensus nodes reply the consensus message to the client, and it is assumed that the number of the consensus nodes agreed is N0, and the rest consensus nodes have no reply message or the reply message is inconsistent with the reply messages of the N0 consensus nodes. The client C extracts first consensus node information for sending the consensus message according to the consensus message, wherein the first consensus node is a set of consensus nodes for sending the consensus message; in practical byzantine fault tolerance, each consensus node generally adopts a digital identifier, but the invention is not limited to this, and information such as a machine name, an IP address, and an MAC address of the consensus node can also be adopted, in this embodiment, the client C extracts the digital identifier i of the consensus node from the consensus information < REPLY, v, t, C, i, r >, and the meanings of other parameters are as follows: v is the current view number, t is the timestamp information, c is the client identification, and r is the execution result.
Step S104, extracting an execution result r of the consensus node according to the consensus information; and according to the execution result, dividing the consensus node sending the consensus message into a non-Byzantine node and a second type Byzantine node.
In the execution result, the agreed N0 consensus nodes belong to the normally operating consensus node and are non-byzantine nodes, and the other consensus nodes sending non-agreed execution results, whose sending motivation may be malicious, belong to byzantine nodes, are set as the second type byzantine nodes, assuming that there are N2 such byzantine nodes, at this time, N0 non-byzantine nodes and N2 byzantine nodes are discriminated from the consensus message received from the client C.
And step S106, obtaining a first type Byzantine node according to the second common node stored by the client and the first common node received by the client.
Specifically, all the consensus node information participating in the consensus process is stored on the client C, and the consensus node information includes N consensus nodes in total, and the consensus node information forms a consensus node set, i.e., a second consensus node. The client C calculates N1 ═ N- (N0+ N2) pieces of common node information according to the stored N pieces of common node information and N0+ N2 pieces of common node information sent common messages, wherein the N1 pieces of common node information do not send common node information and may be caused by disconnection, downtime, delay, congestion and the like, and the N1 pieces of common node information are called first-type byzantine nodes.
Step S108, first processing is carried out on the first type Byzantine node, and second processing is carried out on the second type Byzantine node.
The first processing mode adopts reciprocal weighting as a first cost function of the node, and the second processing mode adopts exponential weighting as a second cost function of the node. Assuming that the consensus node k is identified as a Byzantine node of the first type in this consensus process, WkIs the weight of the consensus node, the cost function is written as:
where N is the number of consensus nodes in the current set of consensus nodes, λ is an empirical constant or a buffer constant, and N is<And lambda and j represent j operation. When N is larger, namely when the number of the common nodes is largerAt the moment, the system has more consensus nodes, stronger fault-tolerant capability and cost function
The speed tending to be smaller is slower, so that the nodes are not required to be frequently deleted; when N is smaller, the number of the consensus nodes is less, the fault-tolerant capability of the system is weaker, the improper nodes need to be replaced in time, and the cost function
The speed of the node tends to be smaller is higher, so that an improper node can be obtained as soon as possible, and the deleting operation can be carried out in time.
For the case of the second type of byzantine node, also assuming that the consensus node k is identified as a second type of byzantine node, Wk is the weight of the consensus node, the cost function is written as:
Wk(j+1)＝Wk(j)Ne-λ (2)
wherein, N is the number of the common-known nodes in the current common-known node set, λ is an empirical constant or a buffer constant, and j represents the j-th operation. Similarly, when N is larger, the speed that the cost function Ne ^ (-lambda) tends to become smaller is slower, and when N is smaller, the speed that the cost function Ne ^ (-lambda) tends to become smaller is faster, and at the moment, the improper node can be deleted as soon as possible.
According to the technical scheme, the weight threshold value is set for the common identification nodes, and the descending speed of the exponential cost function is faster than that of the reciprocal cost function, so that the weights of the second type Byzantine nodes are closer to the set threshold value more quickly, the common identification nodes which are malicious, fraudulent and attacked can be screened out more quickly, the destructive ratio of the common identification nodes is stronger, and the malicious common identification nodes can be deleted in time.
And according to the calculation result of the cost function, when the weight of a certain consensus node is smaller than a threshold value, deleting the consensus node.
After the client C finishes the consensus process each time, the client C performs the above-mentioned weighting operation on the consensus situations of the consensus nodes, and stores the node information and the weighted values of the first-type byzantine node, the second-type byzantine node, and the non-byzantine node as history records on the client C.
Step S110, obtaining a third type Byzantine node according to the history record saved on the client, the currently obtained first type Byzantine node and the second type Byzantine node, and performing third processing on the third type Byzantine node.
Some nodes have deep malicious degree, sometimes send inconsistent consensus results, sometimes do not perform consensus operation on request messages of the client, and do not send reply messages to the client. Such nodes need to be removed from the set of consensus nodes more quickly. Thus, the consensus node currently sending the consensus message is classified according to the history kept on the client C, and if the current first class of byzantine node was once classified in the history as a second class of byzantine node, or if the current second class of byzantine node was once classified in the history as a first class of byzantine node, such a byzantine node is set as a third class of byzantine node for which a cost function with a faster descent rate should be applied, wherein a preferred way is to use the product of reciprocal weighting and exponential weighting as the third generation cost function of the node, the correlation function being as follows.
Wherein, N is the number of the consensus nodes in the current consensus node set, λ is an empirical constant or a buffer constant, and j represents the j-th operation. And setting a weight threshold value for the consensus node, wherein according to the technical scheme, the cost function adopts the product of two descending functions, so that the consensus node can be more quickly close to a preset threshold.
Example two
In this embodiment, the relevant steps or functions implemented on the client C may be moved to the main common node P for processing.
Step S202, after receiving the consensus information, the client sends the consensus information to the main consensus node for processing
After each consensus node replies, collecting the replied consensus results, and sending the consensus results to the main consensus node, wherein at least 2f +1 consensus messages should be contained.
After receiving the consensus message from the client C, the master consensus node P extracts the consensus node information for sending the consensus message, where the consensus node information may adopt information such as a digital identifier, a machine name, an IP address, and a MAC address, and the structure of the consensus information is < REPLY, v, t, C, i, r >, where the digital identifier i of the consensus node is a conventional parameter and may be replaced with other identification methods, and r is an execution result.
Step S204, extracting the execution result of the consensus node according to the received consensus message, and dividing the first consensus node into a second type Byzantine node and a non-Byzantine node according to the execution result;
and then, the main consensus node P extracts an execution result from the r, and classifies the consensus nodes sending the consensus messages according to the execution result. In accordance with the classification method of the first embodiment, in the execution result, the agreed N0 consensus nodes belong to the normal working consensus nodes, are non-byzantine nodes, and other consensus nodes sending the non-agreed execution result, the sending motivation of which may be malicious, and there are N2 such byzantine nodes.
Step S206, second common node information stored in the main common node is extracted, and a first type Byzantine node is obtained according to the first common node information and the second common node information;
specifically, all the information of N consensus nodes participating in the consensus process is stored in the master consensus node, and the master consensus node obtains N1 information of the first type from the information of N consensus nodes and N0+ N2 information of consensus nodes that have sent the consensus message, where the N1 consensus nodes do not send the consensus information.
And step S208, performing first processing on the first type of Byzantine node, and performing second processing on the second type of Byzantine node.
Specifically, a first processing mode is performed on N1 first-type byzantine nodes, that is, reciprocal weighting of formula (1) is used as a cost function, and a second processing mode is performed on N2 second-type byzantine nodes, that is, exponential weighting of formula (2) is used as a cost function.
Step S210, storing the history records of the first type Byzantine node, the second type Byzantine node and the non-Byzantine node on a main consensus node.
After each consensus process is finished, the above-mentioned weighting operation is performed on the consensus situations of the consensus nodes, and the node information and the weighted values of the first-type byzantine node, the second-type byzantine node and the non-byzantine node are stored as a history on the main consensus node P.
Step S212, according to the saved history record, the currently obtained first type Byzantine node and the second type Byzantine node, a third type Byzantine node is obtained, and third processing is carried out on the third type Byzantine node.
Specifically, the primary common node P may also identify, according to the history, a third type of byzantine node, that is, in combination with the current common result and the history, the type of byzantine node is once identified as both the first type of byzantine node and the second type of byzantine node, and for the type of byzantine node, formula (3) is adopted as the weighted cost function.
Step S214, a weight threshold value is set for the consensus node, and when the value of the cost function of the consensus node is lower than the set threshold value, the consensus node is deleted.
Step S216, after the common knowledge nodes are deleted, the numbers of the remaining common knowledge nodes are broadcasted to the remaining common knowledge nodes, and meanwhile, the main common knowledge node starts a process of view conversion, so that a new common knowledge node set is formed and a new view is established.
See fig. 5. And if the current main consensus node is effective and is not the Byzantine node, determining the Byzantine node needing to be deleted currently by the main consensus node according to the calculation result of the cost function. And deleting the determined Byzantine node in the current consensus node set, broadcasting the numbers of the remaining consensus nodes to the remaining consensus nodes, starting a VIEW conversion process by the main consensus node, namely triggering VIEW CHANGE protocol, forming a new consensus node set and establishing a new VIEW by mutually interacting VIEW-CHANGE, VIEW-CHANGE-ACK and other information with other consensus nodes, so as to continue the next consensus process.
Step S218, the number of the currently available consensus nodes is monitored, and when the number of the consensus nodes does not satisfy the minimum number of the consensus nodes, the consensus nodes are supplemented.
In general, when a consensus node is deleted, the corresponding consensus node needs to be supplemented, but this may cause the whole consensus node system to frequently delete and supplement the consensus node, in order to avoid this situation, a preferred mode is that the operation of deleting the consensus node and the operation of supplementing the consensus node are independent from each other, when the operation of deleting the consensus node is performed, the number of currently available consensus nodes is monitored, and when the number of the consensus nodes satisfies 3f +1, where f is the number of currently recorded byzantine nodes, in this case, the operation of supplementing the consensus node is not performed. When the number of the consensus nodes cannot meet the minimum requirement, triggering the operation of supplementing the consensus nodes, and at this time, in order to avoid frequently supplementing the consensus nodes, it is preferable to supplement a plurality of consensus nodes so that the number of non-byzantine nodes has a certain redundancy, but the number of the redundancy cannot be too large, which may greatly reduce the processing speed of the consensus node system, and it may be generally set according to experience, where a preferable redundancy number is the number f of the current byzantine nodes, for example, when there are four consensus nodes, the redundancy number may be set to 1, and when there are seven consensus nodes, the redundancy number may be set to 2.
In an alternative embodiment, a threshold value is set for the stored history. If the main common node P goes down, and/or is dropped, and/or is deleted, etc., the process of view conversion needs to be started, that is, the VIEW CHANGE protocol is triggered. In this case, it is necessary to ensure that the final state of the previous view is continued in the new view, and for a new request sent by the client C, an appropriate number needs to be set, and a request that has not been processed in the previous view is processed, and meanwhile, in order to ensure that data is not lost, a history of byzantine nodes on the primary consensus node P needs to be backed up to the primary consensus node P in the new view. However, since the main common node is down or offline at this time, the backup work may not be completed, and therefore, it is preferable that the history of the current byzantine node is backed up on all the common nodes. Considering that storing the history may cause the consensus node to face the pressure of insufficient storage space, it is preferable to add a storage threshold to the stored history, where the threshold may be a time threshold, for example, one hour is used as a time point for clearing the history, and the history before one hour is cleared after the expiration, or the threshold may be a time threshold, for example, six consensus is used as an upper limit, and the history before is cleared after the six consensus is completed. Through the technical scheme, some Byzantine nodes are in bad or malicious working states continuously, and the deleted threshold can be reached through the operation of the cost function.
In an alternative embodiment, the operations of deleting nodes and supplementing nodes may be performed in a broadcast manner, see fig. 5. And if the current main consensus node is effective and is not the Byzantine node, determining the Byzantine node needing to be deleted currently by the main consensus node according to the calculation result of the cost function. And deleting the determined Byzantine node in the current consensus node set, broadcasting the numbers of the remaining consensus nodes to the remaining consensus nodes, starting a VIEW conversion process by the main consensus node, namely triggering VIEW CHANGE protocol, forming a new consensus node set and establishing a new VIEW by mutually interacting VIEW-CHANGE, VIEW-CHANGE-ACK and other information with other consensus nodes, so as to continue the next consensus process.
In an optional implementation manner, if the current master consensus node fails, the view is updated first in a conventional manner, then the new master consensus node deletes the byzantine node, and then the master consensus node updates the view, that is, the view needs to be updated twice, which results in time delay and waste of computing resources. When other consensus nodes delete the Byzantine nodes, the numbers of the remaining consensus nodes are broadcasted to the remaining consensus nodes, meanwhile, the main consensus node starts a VIEW conversion process, namely, a VIEW CHANGE protocol is triggered, and a new consensus node set and a new VIEW are established by mutually interacting information such as VIEW-CHANGE, VIEW-CHANGE-ACK and the like with the other consensus nodes.
The operation of the supplementary node is similar to that of the deleting node, and at this time, the main common node may broadcast to the idle node, and in order to avoid supplementing the byzantine node which is deleted once, information of the byzantine node which is deleted once should be stored on the main common node or other common nodes, that is, the main common node broadcasts to the idle node which is not identified as the byzantine node as much as possible. The idle nodes return the information of the identification, the processing capacity and the like of the idle nodes to the main consensus node, the main consensus node selects the idle nodes with stronger processing capacity, the idle nodes have certain redundancy in quantity, and then a view conversion process is started to form a new consensus node set and establish a new view. The above process of supplementing the nodes can also be completed by any non-main consensus node.
The embodiments mentioned in the present specification are only used for illustrating the technical solutions, not for limiting the protection scope, and although the technical solutions of the present invention are described in detail with reference to the embodiments, those skilled in the art should understand that the technical solutions of the embodiments can be further modified, improved, or some or all of the technical features can be replaced; and that such modifications, improvements or substitutions do not materially depart from the scope of the invention as intended.
Claims (9)
1. A practical Byzantine fault-tolerant node setting method is characterized in that,
receiving a consensus message sent by a consensus node, and extracting information of a first consensus node from the consensus message, wherein the first consensus node is a consensus node set sending the consensus message;
extracting an execution result of the consensus node according to the received consensus message, and dividing the first consensus node into a second type Byzantine node and a non-Byzantine node according to the execution result;
extracting second consensus node information stored by a client, and obtaining a first type Byzantine node according to the first consensus node information and the second consensus node information;
performing first processing on the first type Byzantine node, and performing second processing on the second type Byzantine node;
wherein the first type of byzantine node and the second type of byzantine node are: the Byzantine nodes of the first type are caused by disconnection, downtime, delay and blockage, and the Byzantine nodes of the second type feed back wrong consensus information;
the second consensus node is: all consensus node information participating in the consensus process is stored on the client, and the consensus node information forms a consensus node set, namely a second consensus node;
the first processing of the first type Byzantine node is that reciprocal weighting is adopted as a first cost function of the node; performing a second process on the second type Byzantine node by adopting exponential weighting as a second cost function of the node;
the number of nodes in the first processing is one of parameters of a first cost function; the number of nodes in the second process is one of the parameters of the second cost function;
setting a weight threshold value for the consensus nodes, and when the value of the first cost function of the consensus nodes is lower than the set threshold value, deleting the first type Byzantine nodes from the second consensus nodes, and/or when the value of the second cost function is lower than the set threshold value, deleting the second type Byzantine nodes from the second consensus node set.
2. The method of practical byzantine-tolerant node setup according to claim 1, wherein the client maintains a history of first type byzantine nodes, second type byzantine nodes, and non-byzantine nodes.
3. The method of setting a practical byzantine-tolerant node according to claim 2, wherein a threshold value of a retention time is set for the retained history.
4. The method of setting a practical byzantine fault-tolerant node according to claim 3, wherein a third type byzantine node is obtained based on the saved history and currently obtained first type byzantine node and second type byzantine node, and a third process is performed on the third type byzantine node;
performing third processing on the third type Byzantine node by taking the product of reciprocal weighting and exponential weighting as a third price function of the node, wherein the number of the nodes in the third processing is taken as one of parameters of the third price function;
setting a threshold value for the weight of the consensus node, and deleting the third type Byzantine node from the consensus node set when the value of the third cost function of the consensus node is lower than the set threshold value;
the third type Byzantine node is as follows: a present byzantine node of the first type is set to a byzantine node of the third type if it was once classified in the history as a byzantine node of the second type or if it was once classified in the history as a byzantine node of the first type.
5. The method as claimed in claim 1, wherein the client is replaced with a main common-knowledge node, and the common-knowledge node set is saved on the main common-knowledge node, and when the main common-knowledge node goes down, and/or is deleted, the view switching is started.
6. The method as claimed in any one of claims 1 to 5, wherein the number of common nodes currently available is monitored, and when the number of common nodes is lower than the minimum number of common nodes, the common nodes are supplemented and have redundant numbers of common nodes.
7. The method as claimed in any one of claims 1 to 5, wherein after the byzantine node is deleted, the byzantine node is broadcasted to the consensus node in a broadcasting manner.
8. The method as claimed in claim 7, wherein when deleting the byzantine node, if the primary common node fails, the non-primary common node deletes the byzantine node, and then starts the operation of changing the view to form a new common node set and a new view.
9. The method as claimed in claim 6, wherein after the nodes are supplemented, the nodes are broadcasted to the consensus nodes in a broadcast manner, and the consensus node set is updated and a new view is created.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010203490.0A CN111629022B (en) | 2020-03-20 | 2020-03-20 | Practical Byzantine fault-tolerant node setting method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010203490.0A CN111629022B (en) | 2020-03-20 | 2020-03-20 | Practical Byzantine fault-tolerant node setting method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111629022A CN111629022A (en) | 2020-09-04 |
| CN111629022B true CN111629022B (en) | 2022-05-20 |
Family
ID=72272981
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010203490.0A Active CN111629022B (en) | 2020-03-20 | 2020-03-20 | Practical Byzantine fault-tolerant node setting method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111629022B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111526216B (en) * | 2020-07-03 | 2020-09-22 | 支付宝(杭州)信息技术有限公司 | Consensus method and system in alliance chain |
| CN113271204B (en) * | 2021-05-06 | 2022-04-12 | 西安电子科技大学 | Byzantine fault-tolerant consensus method based on quantum key distribution |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6671821B1 (en) * | 1999-11-22 | 2003-12-30 | Massachusetts Institute Of Technology | Byzantine fault tolerance |
| CN108492103A (en) * | 2018-02-07 | 2018-09-04 | 北京大学深圳研究生院 | A kind of alliance's block chain common recognition method |
| CN108601026A (en) * | 2018-04-02 | 2018-09-28 | 浙江大学 | Perception data error attack detection method based on random sampling consistency |
| CN109347804A (en) * | 2018-09-19 | 2019-02-15 | 电子科技大学 | A kind of Byzantine failure tolerance common recognition optimization method for block chain |
| CN110535680A (en) * | 2019-07-12 | 2019-12-03 | 中山大学 | A kind of Byzantine failure tolerance method |
| CN110830998A (en) * | 2019-05-28 | 2020-02-21 | 南通大学 | Vehicle networking malicious node identification method based on trust mechanism |
-
2020
- 2020-03-20 CN CN202010203490.0A patent/CN111629022B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6671821B1 (en) * | 1999-11-22 | 2003-12-30 | Massachusetts Institute Of Technology | Byzantine fault tolerance |
| CN108492103A (en) * | 2018-02-07 | 2018-09-04 | 北京大学深圳研究生院 | A kind of alliance's block chain common recognition method |
| CN108601026A (en) * | 2018-04-02 | 2018-09-28 | 浙江大学 | Perception data error attack detection method based on random sampling consistency |
| CN109347804A (en) * | 2018-09-19 | 2019-02-15 | 电子科技大学 | A kind of Byzantine failure tolerance common recognition optimization method for block chain |
| CN110830998A (en) * | 2019-05-28 | 2020-02-21 | 南通大学 | Vehicle networking malicious node identification method based on trust mechanism |
| CN110535680A (en) * | 2019-07-12 | 2019-12-03 | 中山大学 | A kind of Byzantine failure tolerance method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111629022A (en) | 2020-09-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11411721B2 (en) | Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system | |
| CN108492103B (en) | Joint block chain consensus method | |
| CN109150972B (en) | Working method of consensus mechanism of double-layer partitioned efficient block chain | |
| CN108122165B (en) | Block chain consensus method and system | |
| JP6905059B2 (en) | Systems and methods for detecting replay attacks | |
| EP3518110B1 (en) | Designation of a standby node | |
| JP2020505799A (en) | System and method for replay attack detection | |
| CN111061769B (en) | Consensus method of block chain system and related equipment | |
| CN110493198A (en) | A method of it is attacked based on Sybil in PBFT algorithm defence block chain is improved | |
| CN111629022B (en) | Practical Byzantine fault-tolerant node setting method | |
| CN109547527A (en) | Subregion in block chain based on credit mechanism is quickly known together method | |
| JP2020505839A (en) | Computer-implemented system and method for updating a network's knowledge of a network's topology | |
| CN111506656B (en) | Consensus processing method and device for block chain system, intelligent device and storage medium | |
| CN111046109A (en) | Cross-chain task processing method, device and equipment and readable storage medium | |
| CN109450685B (en) | local link node offline consensus method and node | |
| EP2432193A2 (en) | Method of data replication in a distributed data storage system and corresponding device | |
| US20230017790A1 (en) | Graphic-blockchain-orientated hybrid consensus implementation apparatus and implementation method thereof | |
| CN115022352B (en) | End edge cloud fusion-based segmented side chain data acquisition and storage system | |
| CN114490020A (en) | Block chain fragmentation method and system and electronic equipment | |
| CN112398692A (en) | Consensus process processing method and device and electronic equipment | |
| CN110635941A (en) | Database node cluster fault migration method and device | |
| CN112671908A (en) | Network management method and device, electronic equipment and readable storage medium | |
| CN113064764A (en) | Method and apparatus for performing blocks in a blockchain system | |
| Tsai et al. | Lessons learned from developing permissioned blockchains | |
| CN115473908A (en) | Block chain link point fault recovery method and block chain system |
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 |