Practical Byzantine fault-tolerant consensus method and device and electronic equipment

Abstract

The invention discloses a practical Byzantine fault-tolerant consensus method, a practical Byzantine fault-tolerant consensus device and electronic equipment. The method comprises the following steps: receiving a pre-preparation message sent by a master node and preparation messages sent by a plurality of slave nodes; wherein the pre-preparation message comprises a first signature of a first hash value corresponding to a client request by the main node; each preparation message is constructed by each slave node based on the received pre-preparation message, and the preparation message comprises a second signature of a second hash value corresponding to the client request by the master node; performing consistency comparison on the pre-preparation message and each preparation message to determine a comparison result, and performing signature verification on the first signature and each second signature to determine a verification result; based on the comparison result and the verification result, a malicious node is determined or execution of the client request is confirmed; wherein the malicious node is the master node or at least one slave node in the plurality of slave nodes.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, specifically relating to a practical Byzantine fault-tolerant consensus method, device, and electronic device. Background Technology

[0002] Blockchain is a distributed system composed of multiple computing nodes interconnected through a network. Unlike a single centralized control system, distributed systems possess high scalability and fault tolerance. Each node can operate independently, collectively completing complex computational tasks. This distributed architecture brings many advantages, including: improved system reliability and availability, enhanced computing and storage capabilities, support for geographically distributed applications, and promotion of parallel computing and load balancing. However, distributed systems also face unique challenges, the most critical being how to reach consensus among multiple nodes to ensure the system's correctness and consistency. Consensus algorithms are key to addressing this issue. The Practical Byzantine Fault Tolerance (PBFT) algorithm is a representative Byzantine fault-tolerant consensus algorithm. Related technologies utilize the PBFT algorithm to determine malicious behavior of the master node, including: 1. The master node forwards a pre-prepared message containing client requests within the system according to the protocol rules; 2. Slave nodes forward consensus messages within the system according to the received pre-prepared messages and the protocol rules; 3. If consensus on any client request is not reached within the system within a certain time, a view switching mechanism is triggered to switch the master node.

[0003] However, the above methods cannot identify the perpetrator of malicious behavior. For example, the system may have reached consensus on a client request, but inconsistent client requests may have occurred during the consensus process, indicating that a malicious node forged the client request. In this case, tracing and assigning responsibility for the forged client request would be difficult due to a lack of information, making it impossible to determine whether the malicious behavior originated from the master node or a slave node. Summary of the Invention

[0004] The purpose of this application is to provide a practical Byzantine fault-tolerant consensus method, apparatus, and electronic device that can solve the problem of being unable to determine the subject of malicious behavior.

[0005] In a first aspect, embodiments of this application provide a practical Byzantine fault-tolerant consensus method, the method comprising: receiving a pre-preparation message sent by a master node and preparation messages sent by multiple slave nodes; wherein, the pre-preparation message includes a first signature of a first hash value corresponding to a client request from the master node; each preparation message is constructed by each slave node based on the received pre-preparation message, and the preparation message includes a second signature of a second hash value corresponding to the client request from the master node; performing a consistency comparison between the pre-preparation message and each preparation message to determine a comparison result, and performing signature verification on the first signature and each second signature to determine a verification result; and determining a malicious node or confirming the execution of the client request based on the comparison result and the verification result; wherein, the malicious node is the master node or at least one of the multiple slave nodes.

[0006] Secondly, embodiments of this application provide a practical Byzantine fault-tolerant consensus device, comprising: a receiving module, configured to receive a pre-preparation message sent by a master node and preparation messages sent by multiple slave nodes; wherein the pre-preparation message includes a first signature of a first hash value corresponding to a client request from the master node; each preparation message is constructed by each slave node based on the received pre-preparation message, and the preparation message includes a second signature of a second hash value corresponding to a client request from the master node; a verification module, configured to perform a consistency comparison between the pre-preparation message and each preparation message to determine a comparison result, and to perform signature verification on the first signature and each second signature to determine a verification result; and a determining module, configured to determine a malicious node or confirm the execution of the client request based on the comparison result and the verification result; wherein the malicious node is the master node or at least one of the multiple slave nodes.

[0007] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0009] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the steps of the method described in the first aspect.

[0010] In a sixth aspect, embodiments of this application provide a computer program product, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including a program or instructions, which, when executed, implement the steps of the method described in the first aspect.

[0011] In this embodiment, for any slave node in a distributed system, it receives a pre-preparation message sent by the master node and preparation messages sent by multiple slave nodes. The pre-preparation message includes a first signature of the first hash value corresponding to the first request from the master node to the client, and the preparation messages include a second signature of the second hash value corresponding to the second request from the master node to the client. Both messages include a signature of the hash value corresponding to the same client request from the master node. The pre-preparation message and each preparation message are compared for consistency to determine the comparison result, and the first signature and each second signature are verified to determine the verification result. Based on the comparison result and the verification result, it is determined whether the master node and slave nodes have engaged in malicious behavior. Since the pre-preparation message and the preparation message include the first signature or second signature of the hash value corresponding to the client request from the master node, the node corresponding to the message carrying the signature is clear, thereby determining which node has committed malicious action and tracing malicious nodes. Attached Figure Description

[0012] Figure 1 A flowchart illustrating a practical Byzantine fault-tolerant consensus method provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating a method for distinguishing malicious nodes based on digital signatures provided in an embodiment of this application is shown. Figure 3 A flowchart illustrating a signature and signature verification method provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating a node contribution evaluation method provided in an embodiment of this application is shown. Figure 5 A flowchart illustrating a fast view switching method based on node distinguishability provided in an embodiment of this application is shown. Figure 6 This paper shows a schematic diagram of the structure of a practical Byzantine fault-tolerant consensus device provided in an embodiment of this application; Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0015] The practical Byzantine fault-tolerant consensus method, apparatus, and electronic equipment provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0016] Figure 1 This diagram illustrates a practical Byzantine fault-tolerant consensus method provided in an embodiment of this application, which can be executed by an electronic device. See also... Figure 1 The method may include the following steps.

[0017] Step 102: Receive a pre-preparation message sent by the master node and preparation messages sent by multiple slave nodes; wherein, the pre-preparation message includes a first signature of the first hash value corresponding to the client request from the master node; each preparation message is constructed by each slave node based on the received pre-preparation message, and the preparation message includes a second signature of the second hash value corresponding to the client request from the master node.

[0018] In this embodiment of the application, the distributed system includes n nodes, the maximum number of malicious / Byzantine nodes is f, and n = 3f + 1. The practical Byzantine fault-tolerant consensus method provided in this embodiment is applied to any slave node of the distributed system.

[0019] The client request may include the following fields: message type, operation, time, client identifier, and signature. Table 1 shows an exemplary client request format and content provided in an embodiment of this application.

[0020] Table 1.

[0021] In this process, after receiving the client request, the master node constructs a pre-preparation message and then sends it to each slave node. The pre-preparation message may include the following fields: message type, view number, client request sequence number, client request content, hash value corresponding to the client request, master node's signature of the hash value corresponding to the client request, and master node's signature of the current message. Table 2 shows an exemplary format and content of a pre-preparation message provided in this embodiment of the application.

[0022] Table 2.

[0023] In this process, after receiving the pre-preparation message sent by the master node, the slave node constructs a preparation message and then sends the preparation message to each of the other slave nodes. The preparation message may include the following fields: message type, view number, client request sequence number, current slave node number, request hash, master node signature of the hash value corresponding to the client request, and current slave node signature of the current message. Table 3 shows an exemplary format and content of a preparation message provided in this embodiment of the application.

[0024] Table 3.

[0025] Step 104: Perform a consistency comparison between the pre-prepared message and each of the prepared messages to determine the comparison result, and perform signature verification on the first signature and each of the second signatures to determine the verification result.

[0026] Specifically, a consistency comparison is performed between the pre-prepared message and each of the prepared messages to determine whether the information carried in the message received from the master node is consistent with the information carried in the messages received from other slave nodes, thereby judging whether the information transmission is erroneous. Signature verification is performed on the first signature and each of the second signatures to determine whether the master node or slave node corresponding to the message sent has engaged in malicious behavior.

[0027] Step 106: Based on the comparison result and the verification result, determine the malicious node or confirm the execution of the client request; wherein the malicious node is the master node or at least one of the slave nodes.

[0028] The comparison and verification results are used to determine whether a malicious node exists. If a malicious node exists, it is further determined which node it is. If no malicious node exists, it is confirmed that all nodes in the distributed system have reached a consensus, thus confirming the execution of the client request.

[0029] In this embodiment, for any slave node in a distributed system, it receives a pre-preparation message sent by the master node and preparation messages sent by multiple slave nodes. The pre-preparation message includes a first signature of the first hash value corresponding to the first request from the master node to the client, and the preparation messages include a second signature of the second hash value corresponding to the second request from the master node to the client. Both messages include a signature of the hash value corresponding to the same client request from the master node. The pre-preparation message and each preparation message are compared for consistency to determine the comparison result, and the first signature and each second signature are verified to determine the verification result. Based on the comparison result and the verification result, it is determined whether the master node and slave nodes have engaged in malicious behavior. Since the pre-preparation message and the preparation message include the first signature or second signature of the hash value corresponding to the client request from the master node, the node corresponding to the message carrying the signature is clear, thereby determining which node has committed malicious action and tracing malicious nodes.

[0030] In one implementation, step 106 above, which determines a malicious node or confirms the execution of the client request based on the comparison result and the verification result, may include the following steps.

[0031] Step 106a: If the comparison result shows that at least one of the preparation messages is inconsistent with the pre-preparation message, the malicious node is determined based on the verification result corresponding to at least one of the preparation messages.

[0032] In cases where at least one of the prepared messages is inconsistent with the pre-prepared message, it can be determined that a malicious node exists, and then the malicious node can be located based on the signature.

[0033] Step 106b: If the comparison result shows that a preset number of the prepared messages are consistent with the pre-prepared message among the multiple prepared messages, and the verification result corresponding to the preset number of prepared messages is that the first signature verification is passed and the second signature verification is passed, then confirm the execution of the client request.

[0034] The preset quantity can be 2f+1. If at least one of the prepared messages matches the pre-prepared message, the consensus among the nodes is confirmed by combining the signature verification result.

[0035] In this embodiment of the application, the comparison result obtained by comparing the pre-prepared message with each of the prepared messages may include consistency and inconsistency. In the case of inconsistency, it can be determined that there is a malicious node. Then, based on the verification result obtained by verifying the first signature and each of the second signatures, the malicious node can be accurately located to determine whether the malicious node is a master node or at least one of multiple slave nodes.

[0036] In one implementation, step 106a above, in the case that the comparison result is that at least one of the preparation messages is inconsistent with the pre-preparation message, determines the malicious node based on the verification result corresponding to at least one of the preparation messages, may include the following steps.

[0037] Step 1061: If the verification result corresponding to at least one of the preparation messages is that the first signature verification is successful and the second signature verification is successful, then the malicious node is determined to be the master node.

[0038] Among the multiple preparation messages, at least one preparation message is inconsistent with the pre-preparation message, but both the first signature and the second signature are verified. The signatures of different hash values ​​corresponding to the same client request from the master node are all verified, indicating that there is a contradiction. That is, the pre-preparation message sent by the master node to the current slave node is inconsistent with the pre-preparation message sent by the master node to other slave nodes. However, for the master node, any signature can be verified. Thus, the current slave node can determine that the master node has malicious behavior and locate the malicious node as the master node.

[0039] Step 1062: If the verification result corresponding to at least one of the preparation messages is that the first signature verification passes and the second signature verification fails, the malicious node is determined to be the slave node corresponding to at least one of the preparation messages.

[0040] Among them, at least one of the preparation messages is inconsistent with the pre-preparation message. The first signature passes but the second signature fails, indicating that the slave node whose signature verification failed has engaged in malicious behavior, causing its preparation message to be inconsistent with the pre-preparation message sent by the master node. Thus, the malicious node is located as the slave node whose signature verification failed.

[0041] In this embodiment, if it is determined that at least one of the prepared messages is inconsistent with the pre-prepared message, the malicious node is further located based on the verification results of the signatures of these inconsistent prepared messages and the signature of the pre-prepared message. For at least one inconsistent prepared message, if the signature verification of the prepared message passes and the signature of the pre-prepared message also passes, the malicious node is determined to be the master node; if the signature verification of the prepared message passes and the signature of the pre-prepared message passes, the malicious node is determined to be the slave node corresponding to that prepared message. Thus, the malicious node is accurately located based on the verification results of the signatures of the pre-prepared message and the prepared message.

[0042] In one implementation, after determining the malicious node as the master node in step 1061 above, the method further includes the following steps.

[0043] Step 1063: Receive the view switching message sent by the slave node.

[0044] The view switching message indicates that the current master node is malicious and a view switch is needed to replace the master node. The view switching message may include the following fields: message type, view number, client request sequence number, replica ID, request hash, maliciousbehaviorProof, and signature of the current slave node for the current message. Table 4 shows the format and content of an exemplary view switching message provided in this application embodiment.

[0045] Table 4.

[0046] Step 1064: If the number of view switching messages is greater than or equal to the preset number, switch to the new view in the view switching message; wherein the new view includes a new master node.

[0047] If the number of view switching messages is greater than or equal to a preset number, it indicates that in the distributed system, more than a preset number of slave nodes consider the master node to be a malicious node and a view switch is required.

[0048] In this embodiment, after determining that a malicious node is the master node, the current slave node receives view switching messages sent by other slave nodes. Through the view switching messages, it learns that other slave nodes also consider the master node to be a malicious node. Therefore, if the number of received view switching messages is greater than or equal to a preset number, it immediately switches to the new view that includes the new master node in the view switching message, without waiting for timeout, and quickly realizes view switching. This can deal with the situation where the master node has malicious behavior and ensure the normal operation of the distributed system.

[0049] In one implementation, before performing signature verification on the first signature and each of the second signatures in step 104 above to determine the verification result, the method may further include the following steps.

[0050] Step 1031: Receive the evaluation message sent by the master node and the evaluation preparation messages sent by multiple slave nodes; wherein the evaluation message and the evaluation preparation messages include a consensus message set.

[0051] The evaluation message and evaluation preparation message are used to instruct the master node and slave nodes to evaluate their contributions, thus characterizing their influence in the distributed system based on their contributions. The consensus message set can include the aforementioned pre-preparation message, preparation message, and commit messages used for mutual confirmation between the master node and slave nodes, and among slave nodes themselves. Consensus messages in the consensus message set can be categorized into driving messages and non-driving messages. In consistent consensus messages, a message arriving at the master node in an order less than or equal to 2f+1 is classified as a driving message. Other consistent consensus messages, i.e., those arriving later than 2f+1, are classified as non-driving messages.

[0052] The message type of the evaluation message is "Evaluation". Table 5 shows the format and content of an exemplary evaluation message provided in an embodiment of this application.

[0053] Table 5.

[0054] The evaluation preparation message is similar to the preparation message described above, except that its message type is EvaluationPrepare, and the hash value and signature corresponding to the client request are replaced with a consensus message set. Table 6 shows an exemplary format and content of an evaluation preparation message provided in this application embodiment.

[0055] Table 6.

[0056] Step 1032: If a preset number of the evaluation preparation messages are consistent with the evaluation messages, determine the node status information of the master node and the slave node according to the consensus message set.

[0057] Specifically, when the number of evaluation preparation messages consistent with the evaluation message reaches a preset number, it is determined that other slave nodes have reached a consensus, and node evaluation can be carried out.

[0058] The node status information for both master and slave nodes may include the node's ID (node_id), the node's physical device (device_type), the physical device's performance (node_performence), the node's role (role), the number of malicious behaviors (malicious_behavior_cnt), the node's score (point), and the normalized value of the node's score (point_std). Table 7 illustrates an exemplary format and content of node status information provided in this application embodiment.

[0059] Table 7.

[0060] Step 1033: Determine the contribution of the master node and the slave node based on the node status information of the master node and the slave node.

[0061] In some embodiments, the contribution of a node can be calculated using the following formula. : ; ; .

[0062] in, It is a custom weighting coefficient and ; Represents a node The number of commit-driven messages sent; Represents a node The number of preparation class-driven messages sent; and These represent the number of non-driver messages in the commit class and the number of non-driver messages in the preparation class, respectively. Indicates the number of times malicious behavior by the node occurred; This is the base deduction value. It is a node The number of times malicious acts occurred It is a constraint variable used to control the rate at which the deduction value changes with the number of malicious behaviors.

[0063] In this embodiment, by receiving evaluation messages sent by the master node and evaluation preparation messages sent by multiple slave nodes, and if a preset number of evaluation preparation messages are consistent with the evaluation messages, the node status information of the master node and the slave nodes is determined according to the consensus message set. The contribution of the master node and the slave nodes is determined according to the node status information of the master node and the slave nodes. The contribution is used to measure the impact of the participation and behavior of the master node and each slave node on the performance of the distributed system, thereby prioritizing the processing of messages sent by nodes with higher contribution.

[0064] In one implementation, the pre-preparation message further includes the public key of the master node; the preparation message further includes the public key of the slave node; step 104 above verifies the signatures of the first signature and each of the second signatures, and may include the following steps: Step 1041: Perform hash calculation on the public key of the master node and the consensus message set to obtain a first digest value, and perform hash calculation on the public key of each slave node and the consensus message set to obtain a second digest value; Step 1042: Verify the first signature based on the master node's public key, the first digest value, and the master node's contribution. Step 1043: For each slave node, verify the second signature based on the slave node's public key, the second digest value, and the slave node's contribution.

[0065] In this embodiment, signature verification of the first signature is performed by hashing the public key of the master node carried in the prepared message and the consensus message set to obtain a corresponding first digest value, which is then combined with the master node's public key and its contribution to verify the first signature. Signature verification of each second signature is performed by hashing the public key of the slave node carried in each prepared message and the consensus message set to obtain a corresponding second digest value, which is then combined with the slave node's public key and its contribution to verify the second signature. This ensures that the master node's contribution participates in the signature verification of the first signature, and each slave node's contribution participates in the signature verification of each second signature. Consequently, consensus messages from nodes with high contribution levels are prioritized and not blocked by consensus messages from nodes with low contribution levels, thus improving throughput.

[0066] Figure 2 , Figure 3 , Figure 4 and Figure 5The illustration shows a flowchart of another practical Byzantine fault-tolerant consensus method provided in this application embodiment, which can be executed by electronic devices and applied to distributed systems.

[0067] In this embodiment, the distributed system includes n nodes, with an upper limit of f for the number of malicious / Byzantine nodes, and n = 3f + 1. See also Figure 2 , Figure 2 The illustration shows a flowchart of a malicious node differentiation method based on digital signature provided in an embodiment of this application. The method may include steps 201 to 205a2.

[0068] Step 201: The client sends a client request to the master node. Upon receiving the request, the master node constructs a pre-preparation message and broadcasts it to all slave nodes.

[0069] The format and content of the client request are shown in Table 1 above, and the format and content of the preparation message are shown in Table 2 above.

[0070] Step 202: After receiving the pre-preparation message, each slave node constructs a preparation message and broadcasts it to all nodes.

[0071] The format and content of the preparation message are shown in Table 3 above.

[0072] Step 203: For each slave node, perform consistency comparison and signature verification on the pre-prepared message and the prepared message.

[0073] The signing of the pre-prepared message and the prepared message is achieved by calling a signature algorithm. The implementation includes signature verification of the pre-prepared message and the prepared message by calling the signature verification algorithm. accomplish.

[0074] Step 204a: If the number of consistent and signature-verified preparation messages reaches 2f+1, broadcast the commit message to all nodes.

[0075] The signature verification is considered successful if the following formula holds true: ; .

[0076] in, Representative node public key, This represents the public key of the master node. `signature_i` represents the signature in the preparation message received by node i. `requestHash_i` and `requestHashSignature_i` represent the hash value and signature of the client request in the preparation message received by node i.

[0077] The submission message may include the following fields: message type, view number, client request sequence number, current node number, request hash, and signature of the current node for the current message. Table 8 shows an exemplary submission message format and content provided in an embodiment of this application.

[0078] Table 8.

[0079] Step 204b: For each slave node, perform signature verification on the commit message. If the signature verification passes, put the commit message into the cache.

[0080] Step 204c: After there are 2f+1 commit messages in the cache, send a reply message to the client.

[0081] Step 205a: In the event of inconsistency, identify the malicious node as either the master node or a slave node based on the verification result of the master node's signature on the hash value corresponding to the client request in the pre-preparation message and the preparation message.

[0082] Inconsistencies between the pre-preparation message and the preparation message can include: pre-preparation message and preparing messages ,in This resulted in an inconsistency. Each parameter corresponds to a field in the aforementioned message.

[0083] Step 205a1: If the signature verification result of the master node for the hash value corresponding to the client request in both the pre-preparation message and the preparation message is successful, the malicious node is determined to be the master node.

[0084] The malicious node is determined to be the master node if the following formula holds true: .

[0085] Step 205a2: If the verification result of the master node's signature on the hash value corresponding to the client request in the pre-preparation message is successful, and the verification result of the master node's signature on the hash value corresponding to the client request in the preparation message is unsuccessful, then the malicious node is determined to be the slave node that sent the preparation message.

[0086] Among them, a malicious node is determined to be a slave node that sends the preparation message if the following formula holds true: .

[0087] Through the embodiments of this application, the distributed system can accurately locate the identity of a malicious node when a node engages in malicious behavior.

[0088] In some embodiments, such as Figure 3 As shown, Figure 3 The illustration shows a flowchart of a signature and signature verification method provided in an embodiment of this application. The signature method is described in steps 301 to 302, and the signature verification method is described in steps 303 to 304.

[0089] Step 301: Obtain the system's public parameters, the public and private keys of each node, the contribution of each node, and the consensus message set.

[0090] The common parameters can include N, p, q, and B. N is an integer representing the order of the polynomial; p and q are prime numbers; B = ... p^2 N / 4 This is used to constrain the range of values ​​for the polynomial coefficients. The public key for each node is determined as follows: First, a... Trivariate polynomial of order And let , Each coefficient is from the set It is randomly selected from among them. Then, a small-coefficient polynomial is randomly selected. If obtained and In the model With model If the current path is irreversible, then reselect until an irreversible path is generated. and .calculate Used as the node's public key.

[0091] Step 302: Input the system public parameters, the public and private keys of each node, the contribution of each node, and the consensus message set into the preset signature algorithm, and output the signature of the consensus message set.

[0092] In some embodiments, a preset signature algorithm is used. It can include: input ,in, It's the private key. It is a set of consensus messages, mapped into a binary string using any encoding method. It is the public key corresponding to the private key. It is the contribution of the node.

[0093] 1. Initialize the signature of the consensus message set as follows: ; 2. Regarding Perform a hash calculation to obtain the digest value. ; 3. Introduce variables And assign a value ; 4. Update for ; 5. Update for ; 6. Introduce variables And assign a value ; 7. Determine the signature of the consensus message set. for ; 8. Determine if If so, output the signature of the consensus message set. as well as Otherwise, return 3.

[0094] Among them, due to The absolute value of the coefficient does not exceed , The absolute value of the coefficient does not exceed .therefore satisfy: .

[0095] Therefore, given that 8 are true, the probability of a successful signature is: .

[0096] According to this formula, the probability of a successful signature increases with... The probability of a node successfully signing a document changes with the number of nodes contributing to the document; nodes with high contribution levels have a higher probability of successfully signing a document than nodes with low contribution levels.

[0097] Step 303: Obtain the system's public parameters, the public keys of each node, the contribution of each node, and the signature of the consensus message set.

[0098] Among them, the system's public parameters, the public keys of each node, the contribution of each node, and the signature of the consensus message set can be obtained from the pre-preparation message or the preparation message.

[0099] Step 304: Input the system public parameters, the public keys of each node, the contribution of each node, the consensus message set and its signature into the preset signature verification algorithm, and output the verification result.

[0100] The verification result is a Boolean value. A Boolean value of 0 indicates that the signature verification failed, and a Boolean value of 1 indicates that the signature verification passed.

[0101] In some embodiments, a preset signature verification algorithm is used. It can include: input ,in, It is the signature of the consensus message set. It is a consensus message set. It is the public key of the node that sent the message. It represents the contribution of the node that sent the message.

[0102] 1. The initial verification result is 0; 2. Regarding Perform a hash calculation to obtain the digest value. ; 3.Judgment Is it always equal to If yes, then execute step 4; otherwise, the verification result is determined to be 0. 4.Judgment Is it always equal to ,and Is it always equal to If yes, then execute step 5; otherwise, the verification result is determined to be 0. 5. The verification result is 1. Output the verification result as 0 or 1.

[0103] In some embodiments, such as Figure 4 As shown, Figure 4 The flowchart of a node contribution evaluation method provided in an embodiment of this application is shown, see steps 401 to 406.

[0104] Step 401: The master node temporarily caches the set of consensus messages sent and received during the consensus process locally.

[0105] The consensus message set cache has the data structure shown in Table 9.

[0106] Table 9.

[0107] Step 402: When the master node confirms that the client request with sequence number n=kw has reached consensus in the system, the sequence number is less than or equal to... All client requests for consensus messages are loaded into an evaluation message and broadcast.

[0108] Here, w is a custom system parameter used to control the node status update cycle. The format and content of the evaluation message are shown in Table 5 above.

[0109] Step 403: After receiving the evaluation message from the master node, the slave node constructs an evaluation preparation message and broadcasts it to all nodes.

[0110] The format and content of the assessment preparation message are shown in Table 6 above.

[0111] Step 404: After receiving 2f+1 evaluation preparation messages that are consistent with the evaluation message, the slave node broadcasts the evaluation commit message to all nodes.

[0112] The evaluation commit message is similar to the commit message described above, except that the message type of the evaluation commit message is EvaluationCommit, and the hash value and signature corresponding to the client request are replaced with a consensus message set. Table 10 shows an exemplary format and content of an evaluation commit message provided in an embodiment of this application.

[0113] Table 10.

[0114] Step 405: After receiving 2f+1 consistent evaluation commit messages, all nodes determine the node state information of each node based on the consensus message set.

[0115] The format and content of the node status information are shown in Table 7 above.

[0116] Step 406: Determine the contribution of each node based on the node status information of each node.

[0117] In some embodiments, the contribution of a node can be calculated using the following formula. : ; ; .

[0118] in, It is a custom weighting coefficient and ; Represents a node The number of commit-driven messages sent; Represents a node The number of preparation class-driven messages sent; and These represent the number of non-driver messages in the commit class and the number of non-driver messages in the preparation class, respectively. Indicates the number of times malicious behavior by the node occurred; This is the base deduction value. It is a node The number of times malicious acts occurred It is a constraint variable used to control the rate at which the deduction value changes with the number of malicious behaviors.

[0119] In other embodiments, through the above... Figure 2 After determining that the malicious node is the master node in the illustrated embodiment, this application also provides a fast view switching method based on node distinguishability. See [link to relevant documentation]. Figure 5 When node k receives the preparation message from node i, an inconsistency occurs and is resolved through... Figure 2 Taking the example of determining a malicious node as the master node in the illustrated embodiment, the method may include steps 501 to 505.

[0120] Step 501: Node k constructs a view switching message and broadcasts it to all nodes.

[0121] The format and content of the view switching message are shown in Table 4 above.

[0122] Step 502: Other nodes receive the view switching message and verify proof that the master node has committed malicious behavior.

[0123] The proof that the master node committed malicious behavior includes: If the following formula holds true, the master node is confirmed to be a malicious node: .

[0124] Step 503: If other nodes confirm that the master node is a malicious node, they construct a view switch preparation message and broadcast it to all nodes.

[0125] The view switch preparation message may include the following fields: message type, view number, replicaId, lastStableCheckpoint, preparedProofs (a set of messages that complete the preparation phase), checkpointProofs (a set of messages that prove the checkpoint), and the signature of the current replica node for the current message. Table 11 shows the format and content of an exemplary view switch preparation message provided in an embodiment of this application.

[0126] Table 11.

[0127] Step 504: After receiving 2f+1 view switching preparation messages, each node sends a new view message.

[0128] The new view message may include the following fields: message type, new view number, new master node number, viewChangeProofs, prePreparedMessages (pre-sent), and signature of the current slave node for the current message. Table 12 shows an exemplary format and content of a new view message provided in an embodiment of this application.

[0129] Table 12.

[0130] Step 505: After receiving the new view message, each node enters the new view state and continues to process the consensus messages under the new view.

[0131] This application's embodiments incorporate a signature of the hash value corresponding to the client request from the master node into the pre-preparation message and the preparation message. Based on this, a malicious node identification mechanism is constructed, capable of identifying the role of a malicious node—whether it is the master node or a slave node—to prevent the master node from maliciously controlling slave nodes. Furthermore, upon determining that a malicious node is the master node, a fast view switching mechanism is triggered to promptly switch the master node to the new master node. In addition, when verifying the first signature and each of the second signatures, the master node's contribution participates in the verification of the first signature, and each slave node's contribution participates in the verification of each of the second signatures. This takes into account the impact of the device performance of different nodes on the overall performance of the distributed system, thus allowing consensus messages from nodes with high contributions to be processed first and not blocked by consensus messages from nodes with low contributions, thereby improving throughput.

[0132] It should be noted that the Practical Byzantine Fault-Tolerant Consensus Method provided in this application can be executed by a Practical Byzantine Fault-Tolerant Consensus Device, or a control module within that device for executing the method. This application uses the execution method of a Practical Byzantine Fault-Tolerant Consensus Device as an example to illustrate the device provided.

[0133] Figure 6 This paper presents a schematic diagram of a practical Byzantine fault-tolerant consensus device according to an embodiment of this application. (See also...) Figure 6 The device 600 may include a receiving module 61, a verification module 62, and a determining module 63.

[0134] The receiving module 61 is used to receive a pre-preparation message sent by the master node and preparation messages sent by multiple slave nodes; wherein the pre-preparation message includes a first signature of the first hash value corresponding to the client request from the master node; each preparation message is constructed by each slave node based on the received pre-preparation message, and the preparation message includes a second signature of the second hash value corresponding to the client request from the master node; the verification module 62 is used to perform a consistency comparison between the pre-preparation message and each preparation message to determine the comparison result, and to perform signature verification on the first signature and each second signature to determine the verification result; the determining module 63 is used to determine a malicious node or confirm the execution of the client request based on the comparison result and the verification result; wherein the malicious node is the master node or at least one of the multiple slave nodes.

[0135] In one implementation, the determining module 63 described above can be used to: determine the malicious node based on the verification result corresponding to at least one of the prepared messages when the comparison result is that at least one of the prepared messages is inconsistent with the pre-prepared message; and confirm the execution of the client request when the comparison result is that a preset number of prepared messages are consistent with the pre-prepared message and the verification result corresponding to the preset number of prepared messages is that the first signature verification is passed and the second signature verification is passed.

[0136] In one implementation, the determination module 63 described above can be used to: determine the malicious node as the master node when the verification result corresponding to at least one of the preparation messages is that the first signature verification is successful and the second signature verification is successful; and determine the malicious node as the slave node corresponding to at least one of the preparation messages when the verification result corresponding to at least one of the preparation messages is that the first signature verification is successful and the second signature verification is unsuccessful.

[0137] In one implementation, the device 600 may further include a view switching module, which can be used to receive view switching messages sent by the slave node; and when the number of view switching messages is greater than or equal to the preset number, switch to the new view in the view switching message; wherein the new view includes a new master node.

[0138] In one implementation, the aforementioned apparatus 600 may further include an evaluation module, which can be used to receive evaluation messages sent by the master node and evaluation preparation messages sent by a plurality of slave nodes; wherein the evaluation messages and the evaluation preparation messages include a consensus message set; when a preset number of evaluation preparation messages are consistent with the evaluation messages, the node status information of the master node and the slave nodes is determined according to the consensus message set; and the contribution of the master node and the slave nodes is determined according to the node status information of the master node and the slave nodes.

[0139] In one implementation, the pre-preparation message further includes the public key of the master node; the preparation message further includes the public key of the slave node; the verification module 62 described above can be specifically used to: perform a hash calculation on the public key of the master node and the consensus message set to obtain a first digest value, and perform a hash calculation on the public key of each slave node and the consensus message set to obtain a second digest value; verify the first signature based on the public key of the master node, the first digest value, and the contribution of the master node; and verify the second signature for each slave node based on the public key of the slave node, the second digest value, and the contribution of the slave node.

[0140] The practical Byzantine fault-tolerant consensus device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the specific implementation.

[0141] The practical Byzantine fault-tolerant consensus device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.

[0142] The practical Byzantine fault-tolerant consensus device provided in this application embodiment can achieve... Figures 1 to 5 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0143] Based on the same technical concept, embodiments of this application also provide an electronic device for executing the aforementioned practical Byzantine fault-tolerant consensus method. Figure 7 This is a schematic diagram of the structure of an electronic device to implement the various embodiments of this application. The electronic device can vary significantly due to differences in configuration or performance, and may include a processor 701, a communications interface 702, a memory 703, and a communication bus 704. The processor 701, communications interface 702, and memory 703 communicate with each other via the communication bus 704. The processor 701 can call a computer program stored in the memory 703 and executable on the processor 701 to perform the various steps of the above-described practical Byzantine fault-tolerant consensus method embodiments, achieving the same technical effects. To avoid repetition, further details are omitted here.

[0144] It should be noted that the electronic devices in the embodiments of this application include servers, terminals, or other devices besides terminals. For example, automobiles, robots, and handheld devices.

[0145] The above electronic device structure does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or arrange them differently. For example, an input unit may include a Graphics Processing Unit (GPU) and a microphone, and a display unit may use a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar display panels. User input units include at least one of a touch panel and other input devices. A touch panel is also called a touchscreen. Other input devices may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be elaborated further here.

[0146] Memory can be used to store software programs and various data. Memory can primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area can store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, memory can include volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (Synchlink DRAM, SLDRAM), and direct memory bus RAM (DRRAM).

[0147] The processor may include one or more processing units; optionally, the processor integrates an application processor and a modem processor, wherein the application processor mainly handles operations related to the operating system, user interface, and applications, while the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor.

[0148] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described practical Byzantine fault-tolerant consensus method embodiments and achieve the same technical effects. To avoid repetition, these will not be described again here.

[0149] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0150] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described practical Byzantine fault-tolerant consensus method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0151] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0152] This application also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes a program or instructions. When the program or instructions are executed, they implement the various processes of the above-described practical Byzantine fault-tolerant consensus method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0153] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0154] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0155] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A practical Byzantine fault-tolerant consensus method, characterized in that, The method includes: The system receives a pre-preparation message sent by the master node and preparation messages sent by multiple slave nodes; wherein, the pre-preparation message includes a first signature of the first hash value corresponding to the client request from the master node; each preparation message is constructed by each slave node based on the received pre-preparation message, and the preparation message includes a second signature of the second hash value corresponding to the client request from the master node; A consistency comparison is performed between the pre-prepared message and each of the prepared messages to determine the comparison result, and a signature verification is performed between the first signature and each of the second signatures to determine the verification result; Based on the comparison results and the verification results, a malicious node is identified or the execution of the client request is confirmed; wherein, the malicious node is the master node or at least one of the multiple slave nodes.

2. The method according to claim 1, characterized in that, Based on the comparison results and the verification results, determining a malicious node or confirming the execution of the client request includes: If the comparison result shows that at least one of the preparation messages is inconsistent with the pre-preparation message, the malicious node is determined based on the verification result corresponding to at least one of the preparation messages. If the comparison result shows that a preset number of the prepared messages are consistent with the pre-prepared message, and the verification result corresponding to the preset number of prepared messages is that the first signature verification is passed and the second signature verification is passed, then the client request is confirmed to be executed.

3. The method according to claim 2, characterized in that, In the case where the comparison result shows that at least one of the preparation messages is inconsistent with the pre-preparation message, determining the malicious node based on the verification result corresponding to at least one of the preparation messages includes: If the verification result corresponding to at least one of the preparation messages is that the first signature verification is successful and the second signature verification is successful, the malicious node is determined to be the master node; If the verification result corresponding to at least one of the preparation messages is that the first signature verification passes and the second signature verification fails, the malicious node is determined to be the slave node corresponding to at least one of the preparation messages.

4. The method according to claim 3, characterized in that, After determining that the malicious node is the master node, the method further includes: Receive the view switching message sent by the slave node; If the number of view switching messages is greater than or equal to the preset number, the view is switched to the new view in the view switching message; wherein, the new view includes a new master node.

5. The method according to claim 1, characterized in that, Before performing signature verification on the first signature and each of the second signatures to determine the verification result, the method further includes: The system receives evaluation messages sent by the master node and evaluation preparation messages sent by multiple slave nodes; wherein the evaluation messages and the evaluation preparation messages include a set of consensus messages. If a preset number of the evaluation preparation messages are consistent with the evaluation messages, the node status information of the master node and the slave node is determined according to the consensus message set; The contribution of the master node and the slave node is determined based on the node status information of the master node and the slave node.

6. The method according to claim 5, characterized in that, The pre-preparation message also includes the master node's public key; The preparation message also includes the public key of the slave node; the signature verification of the first signature and each of the second signatures includes: A hash calculation is performed on the public key of the master node and the consensus message set to obtain a first digest value, and a hash calculation is performed on the public key of each slave node and the consensus message set to obtain a second digest value; The first signature is verified based on the master node's public key, the first digest value, and the master node's contribution. For each of the slave nodes, the second signature is verified based on the slave node's public key, the second digest value, and the slave node's contribution.

7. A practical Byzantine fault-tolerant consensus device, characterized in that, include: A receiving module is used to receive a pre-preparation message sent by a master node and preparation messages sent by multiple slave nodes; wherein, the pre-preparation message includes a first signature of a first hash value corresponding to a client request from the master node; each preparation message is constructed by each slave node based on the received pre-preparation message, and the preparation message includes a second signature of a second hash value corresponding to a client request from the master node; The verification module is used to perform a consistency comparison between the pre-prepared message and each of the prepared messages to determine the comparison result, and to perform signature verification on the first signature and each of the second signatures to determine the verification result; The determination module is used to determine a malicious node or confirm the execution of the client request based on the comparison result and the verification result; wherein the malicious node is the master node or at least one of the slave nodes.

8. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the practical Byzantine fault-tolerant consensus method as described in any one of claims 1 to 6.

9. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the practical Byzantine fault-tolerant consensus method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including programs or instructions that, when executed, implement the steps of the practical Byzantine fault-tolerant consensus method as described in any one of claims 1 to 6.

Images