WO2023016428A1

WO2023016428A1 - Byzantine fault tolerance method and apparatus, and electronic device and storage medium

Info

Publication number: WO2023016428A1
Application number: PCT/CN2022/111000
Authority: WO
Inventors: 段斯斯; 张海滨
Original assignee: 清华大学; 山东区块链研究院
Priority date: 2021-08-12
Filing date: 2022-08-09
Publication date: 2023-02-16
Also published as: CN113783935A; CN113783935B

Abstract

Provided in the embodiments of the present application is a Byzantine fault tolerance method, which is applied to any consensus node in a distributed system. The distributed system comprises at least N consensus nodes, wherein N ≥ 3f +1, f being an integer greater than 0. The method comprises: on the basis of a reliable broadcast (RBC) protocol, broadcasting to other consensus nodes a local proposal on which a consensus is to be reached; for a proposal, on which a consensus is to be reached, of any consensus node, determining, on the basis of a local receiving condition, an initial voting value of the proposal on which a consensus is to be reached, wherein the initial voting value is a priority voting value or another voting value; and for any proposal on which a consensus is to be reached that has the initial voting value, determining a consensus result thereof by using a re-votable binary consensus algorithm. By using the method provided in the present embodiment, binary consensus processes of proposals on which a consensus is to be reached can be concurrently processed, such that the time consumed by each instance of reaching a consensus is shortened, and the efficiency of reaching a consensus is improved, thereby improving the processing capability of a distributed system.

Description

A Byzantine fault tolerance method, device, electronic equipment and storage medium

Cross References to Related Applications

This application is based on a Chinese patent application with application number 202110925724.7 and a filing date of August 12, 2021, and claims the priority of this Chinese patent application. The entire content of this Chinese patent application is hereby incorporated by reference into this application.

technical field

The present application relates to the field of computer technology, in particular, to a Byzantine fault tolerance method, device, electronic equipment and storage medium.

Background technique

The Byzantine fault tolerance method based on binary consensus is one of the commonly used methods for dealing with Byzantine problems in distributed systems. In this method, in each consensus process, any consensus node in the distributed system will The consensus proposal proposed by each consensus node interacts with other consensus nodes to reach a consensus, and finally outputs the consensus result of each consensus proposal. In each consensus process, the consensus node usually cannot completely parallelize each consensus proposal. Therefore, the current Byzantine fault-tolerant method based on binary consensus has low consensus efficiency.

Contents of the invention

The embodiment of the present application provides a Byzantine fault tolerance method, device, electronic equipment and storage medium, which are used to solve the problem of low execution efficiency of the binary consensus-based Byzantine fault tolerance method in the prior art.

In order to achieve the above object, the application provides the following technical solutions:

According to the first aspect of the embodiment of the present application, a Byzantine fault-tolerant method is provided, which is applied to any consensus node in a distributed system. The distributed system includes at least N consensus nodes, and among the N consensus nodes, at most F malicious nodes are allowed, where N≥3f+1, the f is an integer greater than 0, and the method includes: broadcasting the local consensus proposal to other consensus nodes based on the reliable broadcast RBC protocol;

In the case of receiving a consensus proposal broadcast by any consensus node through the reliable broadcast RBC protocol, if the re-voting binary consensus algorithm has not been started for the consensus proposal, the initial The voting value is determined as the priority voting value; if the re-voting binary consensus algorithm has been executed for the pending consensus proposal, and the consensus result of the pending consensus proposal has not been obtained, the initial voting of the pending consensus proposal The value is determined as the priority voting value;

In the case of receiving the pending consensus proposal broadcast by N-f consensus nodes, the initial voting value of the pending consensus proposal that has not started to execute the re-voting binary consensus algorithm is determined as other voting value;

For any pending consensus proposal with an initial voting value, a re-voting binary consensus algorithm is used to determine the consensus result.

In the above scheme, for any proposal to be agreed upon with an initial voting value, a re-voting binary consensus algorithm is used to determine the consensus result, including:

For any consensus proposal, if it is determined that the consensus proposal has an initial voting value, the initial voting value will be used as the input of the re-voting binary consensus algorithm, and the output of the algorithm will be used as the consensus proposal consensus results.

In the above scheme, the method further includes: after obtaining the consensus results of the N proposals to be agreed upon, determining a set consisting of at least one proposal to be agreed upon whose consensus result is a priority voting value as the set to be agreed upon;

After receiving all the proposals to be agreed in the set to be agreed, execute the proposals to be agreed in the set according to the preset order.

According to the second aspect of the embodiment of the present application, a Byzantine fault-tolerant device is provided, which is applied to any consensus node in a distributed system, and the distributed system includes at least N consensus nodes, and among the N consensus nodes, at most F malicious nodes are allowed, where N≥3f+1, the f is an integer greater than 0, and the device includes:

The communication module is used to broadcast the local consensus proposal to other consensus nodes based on the reliable broadcast RBC protocol;

The processing module, in the case of receiving a consensus proposal broadcast by any consensus node through the reliable broadcast RBC protocol, if the binary consensus algorithm that can be voted again has not been started for the consensus proposal, then the consensus proposal The initial voting value of the proposal is determined as the priority voting value; if the re-voting binary consensus algorithm has been implemented for the pending consensus proposal, and the consensus result of the pending consensus proposal has not been obtained, the pending consensus proposal will be re- The initial voting value of is determined as the priority voting value; in the case of receiving the consensus proposal broadcast by N-f consensus nodes, the initial voting value of the pending consensus proposal that has not started to execute the re-voting binary consensus algorithm is determined as other Voting value; For any proposal to be consensus with an initial voting value, a re-voting binary consensus algorithm is used to determine the consensus result.

In the above solution, the processing module is specifically configured to, for any proposal to be consensus, if it is determined that the proposal to be consensus has an initial voting value, the initial voting value is used as the voting value of the binary consensus algorithm that can be voted again. Input, take the output of the algorithm as the consensus result of the proposal to be consensused.

In the above scheme, the re-voting binary consensus algorithm includes: a binary consensus that allows the input of any proposal to be consensus to be changed from other voting values to priority voting values, and the output consensus result is biased towards the priority voting value algorithm.

In the above scheme, the processing module is also used to determine the set consisting of at least one proposal to be consensus whose consensus result is a priority voting value after obtaining the consensus results of the N proposals to be consensused as the set to be agreed upon; After all the pending consensus proposals in the consensus set, execute the pending consensus proposals in the set according to the preset order.

According to a third aspect of the embodiments of the present application, a computer device is provided, including a memory, a processor, a communication interface, and a computer program stored in the memory and operable on the processor, wherein the processor executes the When the program is described, the steps of the method described in the first aspect above are realized.

According to a fourth aspect of the embodiments of the present application, there is provided a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the steps of the method described in the above-mentioned first aspect are implemented.

Using the Byzantine Fault Tolerance method provided in the embodiment of this application, each consensus node broadcasts the local consensus proposals based on the reliable broadcast RBC protocol, and determines the initial voting value for each consensus proposal based on the local reception situation. The meta-consensus algorithm determines the consensus results of each pending consensus proposal, so that the consensus nodes can completely parallelize the consensus processing for each pending consensus proposal, shortening the time-consuming of each consensus, improving the efficiency of the consensus, and further improving the efficiency of the distributed system. processing power.

Description of drawings

The drawings described here are used to provide a further understanding of the application and constitute a part of the application. The schematic embodiments and descriptions of the application are used to explain the application and do not constitute an improper limitation to the application. In the attached picture:

FIG. 1 is a schematic structural diagram of an existing Byzantine fault-tolerant method according to an embodiment of this specification;

Fig. 2 is a schematic flow chart of a Byzantine fault tolerance method implemented in this description;

FIG. 3 is a schematic structural diagram of a Byzantine fault-tolerant method according to an embodiment of the present specification;

FIG. 4 is a schematic flow diagram of a re-voting binary consensus algorithm according to an embodiment of this specification;

FIG. 5 is a schematic flow diagram of a broadcast consensus message according to an embodiment of this specification;

FIG. 6 is a schematic flow diagram of another re-voting binary consensus algorithm according to the embodiment of this specification;

FIG. 7 is a schematic structural diagram of a Byzantine fault-tolerant device according to an embodiment of the present specification;

Fig. 8 is a schematic structural diagram of a device for configuring the device of the embodiment of this specification.

Detailed ways

A centralized system refers to a central node composed of one or more host computers. Data is stored centrally in this central node, and all business units of the entire system are deployed centrally on this central node, and all functions of the system are centralized by it. Processing, each terminal or client connected to the centralized system is only responsible for data input and output, and the processing and storage of data is completely handed over to the central node. Although the centralized system deployment structure is simple and easy to implement, when the host of the central node fails, such as downtime, the entire system will be in an unavailable state, which will cause quite serious consequences. Therefore, the industry has begun to use distributed systems to solve the above problems. One solution is to partition the data, that is, store the data in blocks on different computer devices; the other solution is to use multiple computer devices to store the same data separately. and provide the same service. The above-mentioned first solution still cannot fundamentally solve the problem. When a certain computer equipment fails, some data will be lost, and the usability is still not strong. Using the above-mentioned second solution can ensure the availability of the system to the greatest extent and reduce the harm caused by a single computer equipment failure. At present, many service systems are deployed using the above-mentioned second solution, such as blockchain networks. In this way of deployment, it is necessary to ensure that each computer device in the system can store the same data to ensure data consistency, so the consensus problem arises as the times require. In addition, most of the current network environments are asynchronous, that is, the messages sent by each node in the system cannot be guaranteed to arrive within a known time, and there will usually be a single node computer equipment failure or malicious behavior in the system. It can be called a Byzantine node. How to ensure that all normal nodes in the system can achieve consensus in this case is the main research direction in the industry at present.

For the above-mentioned problems in the distributed system, there are many solutions in the industry, one of which is the Byzantine method based on binary consensus. Make a consensus. Any consensus node will locally use reliable broadcast RBC and binary consensus ABA (asynchronous binary agreement) to determine the consensus result of the pending consensus proposal proposed by each consensus node. For example, there are N consensus nodes in a distributed system, where there are at most f malicious nodes or Byzantine nodes in the distributed system, N≥3f+1, f>0, then any consensus node will maintain N pairs of RBC +ABA instance, each pair of instances is used to determine the consensus result of a pending consensus proposal, and in a distributed system, each consensus node will obtain all the consensus results of the pending consensus proposal at the same time in a consensus process before determining the consensus At the end of the process, in this method, any consensus node will broadcast local consensus proposals to other consensus nodes based on the reliable broadcast RBC protocol, and will also receive its own consensus proposals broadcast by other consensus nodes based on the reliable broadcast RBC protocol. After receiving a consensus proposal from a target node, it will determine that the initial voting value of the consensus proposal is 1, and start to exchange voting values with other consensus nodes to perform binary consensus, which is to execute ABA, and after receiving N-f consensus After the node broadcasts the pending consensus proposals, ABA is executed separately for the N-f pending consensus proposals, until the ABA is executed for the N-f pending consensus proposals and N-f consensus results are obtained, and then the remaining f ones are serially targeted. The consensus process is not complete until the consensus proposals are executed with ABA, and the consensus results of N pending consensus proposals are obtained.

As shown in Figure 1, there are 7 consensus nodes in this embodiment, that is, N is 7 and f is 2. This figure shows the RBC+ABA instance maintained internally by any consensus node, which needs to maintain 7 pairs of RBC+ABA instances. That is, RBC+ABA is used to consensus the consensus proposal of each consensus node. For the convenience of explanation, any consensus node is called the target node. After the target node receives the consensus proposal of node 0-node 4 based on the reliable broadcast RBC protocol , start to execute ABA for the pending consensus proposals of node 0-node 4, that is, set the inputs of ABA0-ABA4 to 1 and start execution, instead of continuing to receive the pending consensus proposals of node 5 and node 6, that is, for N-f(7 -2) ABA is performed on the pending consensus proposals of consensus nodes. After executing the ABA process for the consensus proposal for node 0-node 4, 5 ABA output results will be obtained, that is, 5 consensus results will be obtained. After confirming that the consensus results are all 1, at this time, the target node will correspond to The input of ABA5 and ABA6 of node 5 and node 6 is set to 0 and starts to execute. As shown in the figure, ABA2 is the last one in ABA0-ABA4 to be executed. After the execution of ABA2 is completed, ABA5 and ABA6 will be executed. The execution process is not complete until ABA5 and ABA6 are executed and the output results are obtained, that is, a total of 7 consensus results are obtained (consensus is reached based on all consensus proposals of all consensus nodes).

To sum up, in the existing Byzantine fault-tolerant method based on binary consensus, it is necessary to implement binary consensus for N-f pending consensus proposals (as shown in Figure 1, N-f=5) before starting to target the remaining f proposals. The pending consensus proposal implements a binary consensus process, so each consensus process takes a long time and is inefficient.

In view of the above problems, the embodiment of this application provides a Byzantine fault-tolerant method, which is applied to any consensus node in the distributed system, based on the reliable broadcast RBC protocol to broadcast and receive consensus proposals from other consensus nodes, and determine based on local reception conditions The initial voting value of the proposal to be consensus, and based on the re-voting binary consensus algorithm to reach a consensus on each proposal to be consensus, can effectively improve the efficiency of each consensus.

The solutions in the embodiments of the present application can be realized by using various computer languages, for example, the object-oriented programming language Java and the literal translation scripting language JavaScript.

In order to make the technical solutions and advantages in the embodiments of the present application clearer, the exemplary embodiments of the present application will be further described in detail below in conjunction with the accompanying drawings. Apparently, the described embodiments are only part of the embodiments of the present application, and Not an exhaustive list of all embodiments. It should be noted that, in the case of no conflict, the embodiments in the present application and the features in the embodiments can be combined with each other.

As shown in Figure 2, based on the above description, a Byzantine fault tolerance method proposed in this specification is applied to any consensus node in the distributed system. The distributed system includes at least N consensus nodes, where the consensus node refers to participating in the consensus process It is understandable that there are usually other nodes that do not participate in the consensus in the distributed system. These nodes only receive and store the consensus results of the consensus nodes and do not participate in the consensus process; in addition, when malicious nodes in the system or It is said that when there are too many Byzantine nodes, any consensus method cannot ensure that the consensus nodes in the system reach a consensus. Therefore, this specification stipulates that the distributed system includes N consensus nodes, and there are at most f malicious nodes among the N consensus nodes. N≥3f+1, both f and N are integers greater than 0, the method includes:

S201, broadcast the local consensus proposal to other consensus nodes based on the reliable broadcast RBC protocol;

S202, for any consensus node's pending consensus proposal, determine the initial voting value of the pending consensus proposal based on the local reception situation; the initial voting value is the priority voting value or other voting values;

S203. For any proposal to be agreed upon with an initial voting value, a re-voting binary consensus algorithm is used to determine the consensus result.

The consensus proposal can have different actual meanings in different distributed system application scenarios. For example, in a blockchain network, the pending consensus proposal can be a batch of transactions obtained by a consensus node in the consensus node from the local transaction pool and needs to be stored together by other consensus nodes, and the voting value proposed by a certain node represents Whether to agree to store the batch of transactions; in other application scenarios, the consensus proposal and voting value may have other specific meanings, which are not limited in this manual. For convenience of description, the node executing the method is referred to as the target node hereinafter.

In the above S201, the target node can use any reliable broadcast RBC protocol to broadcast the local consensus proposal to other consensus nodes.

In the Byzantine Fault Tolerance method proposed in this manual, each node does not directly have a master-slave distinction, and other consensus nodes are also performing the same steps, so the target node can receive consensus proposals broadcast by other consensus nodes based on the reliable broadcast RBC protocol.

The following is an example of the distributed system as a blockchain network to illustrate the above broadcast process. The target node can randomly obtain a preset number of transactions from the local transaction pool, or obtain the transactions stored earlier in priority according to the order in which transactions are stored. A preset amount of transactions. It is understandable that since each consensus node will receive the transaction requested by the client, each consensus node can maintain its own transaction pool locally. After the target node obtains the transaction, it can package the obtained transaction into the consensus proposal for this time. After the target node obtains the local pending consensus proposal, it can broadcast the local pending consensus proposal to other consensus nodes based on the reliable broadcast RBC protocol, and can also receive the pending consensus proposal broadcast by other consensus nodes based on the reliable broadcast RBC protocol. The following is an example of a specific implementation of the reliable broadcast RBC protocol:

The target node can use the erasure code to process the consensus proposal to obtain N data blocks; build a Merkle tree based on the hash values of the obtained N data blocks, and obtain the root hash and the Merkle tree corresponding to each data block. Merkel proof of Merkel path; save some of the N data blocks locally, and send other data blocks, root hashes, and Merkel paths corresponding to other data blocks to other consensus nodes, so that Other consensus nodes broadcast and verify the data block. Taking a total of 4 consensus nodes (consensus node 1-consensus node 4) as an example, the target node is consensus node 1, and consensus node 1 splits the local pending consensus proposal into 4 data blocks after processing with erasure codes, which are respectively Data block 1-data block 4, use the preset Hash algorithm to perform Hash operation on the 4 data blocks, get the Hash values of the 4 data blocks, and build a Merkle tree based on the hash values of the 4 data blocks, the data block The hash value of 1 is Hash1, the hash value of data block 2 is Hash2, the hash value of data block 3 is Hash3, and the hash value of data block 4 is Hash4. Hash12 is obtained by calculating Hash1 and Hash2, and Hash3 and Hash4 are calculated. Hash34, calculate Hash12 and Hash34 to get the root Hash, so as to get the Merkle tree. It can be understood that the above only takes 4 nodes as an example. In practical applications, more complex Merkle trees can be constructed according to different numbers of consensus nodes. After building the Merkle tree, consensus node 1 can store data block 1 locally, send data block 2, Hash1, Hash34 and root Hash to consensus node 2; send data block 3, Hash4, Hash12 and root Hash To consensus node 3; send data block 4, Hash3, Hash12 and root Hash to consensus node 4. Take the content sent to consensus node 2 as an example, where Hash1 and Hash34 are the Merkel proofs of the Merkel path corresponding to data block 2. Consensus node 1 can send the above content to other consensus nodes in Rval message format. After other consensus nodes receive the above content sent by consensus node 1, they can broadcast the above content to other consensus nodes in Echo message format. After receiving the Echo message, other consensus nodes can verify whether the message is legal. Specifically, after receiving the message, for the data block in the message, use the Merkle proof of the Merkle path corresponding to the data block , root hash for verification; if the verification is passed, it is determined that the message is legal.

Continuing the above example, after receiving the Echo message, the consensus node 3 determines that the content of the message is: data block 4, Hash3, Hash12 and root Hash, then it can calculate the data block 4 to get Hash4, and combine Hash4 with the received Hash3 is calculated to get Hash34, and Hash34 is calculated with the received Hash12 to get the root Hash. If the calculated root Hash is the same as the received root Hash, it means that the Echo message is legal. If the verification fails, the root Hash can be discarded directly. Echo messages to avoid tampering of messages by malicious nodes.

In the above way, consensus node 2 to consensus node 4 can receive all data blocks sent by consensus node 1 (target node) (in the case that no node intentionally does not send data blocks), any node can receive N-f Echo After the message, and the N-f Echo messages are all verified, select any N-2f data blocks to restore the consensus proposal, and the Merkle tree can be reconstructed, and the root of the reconstructed Merkle tree can be compared Whether the Hash is consistent with the root Hash in the Echo received before, and if it is consistent, the Ready message will be broadcast.

It is understandable that, although the above description takes target node 1 as an example, in the consensus method shown in this specification, each consensus node has no primary and secondary distinction, that is, any consensus node is a target node, and any consensus node Nodes can obtain consensus proposals from other consensus nodes through the above methods; any consensus node can also send local consensus proposals to other consensus nodes through the above methods.

Each consensus node can send local pending consensus proposals at the same time, so the target node may successively receive pending consensus proposals sent by different consensus nodes. After receiving the pending consensus proposals sent by other consensus nodes, the target node can execute S201-S203 for each pending consensus proposal, that is, it can reach consensus on the pending consensus proposals broadcast by each consensus node in the blockchain network.

It can be understood that, the foregoing is only a specific implementation manner of the reliable broadcast RBC protocol, and the reliable broadcast RBC may also be implemented in other ways, for details, reference may be made to related technologies, which is not limited in this description.

In the above S202, the target node may specifically receive the proposal to be consensus broadcast by any consensus node through the reliable broadcast RBC protocol, if the proposal to be consensus has not yet started to implement the binary consensus that can be voted again Algorithm, the initial voting value of the proposed consensus proposal is determined as the priority voting value;

In addition, if the binary consensus algorithm that can be voted again has been implemented for the proposal to be consensus, and the consensus result of the proposal to be consensus has not been obtained, the initial voting value of the proposal to be consensus will be re-determined as the priority vote value;

In the case of receiving the pending consensus proposals broadcast by N-f consensus nodes, the initial voting value of the pending consensus proposals that have not started to execute the re-voting binary consensus algorithm is determined as other voting values.

Among them, the voting value includes the priority voting value and other voting values. This manual proposes to set one of the voting values as the priority voting value, that is, it is hoped that each consensus node will reach a consensus on the priority voting value. In a specific example 1 and 0 can be used to represent the priority voting value and other voting values respectively, wherein the priority voting value can be 1 or 0, and the following descriptions will take the priority voting value of 1 and other voting values of 0 as an example.

Taking N as 7 and f as 2 as an example, the target node determines whether it has started to execute the binary consensus algorithm of re-voting for the consensus proposal after receiving the consensus proposal broadcast by any consensus node, if not , then the initial voting value of the proposal to be consensus is determined as the priority voting value 1, and the priority voting value 1 is used as the input of the re-voting binary consensus algorithm to obtain the consensus result for the proposal to be consensus.

In addition, after it is determined that the consensus proposals broadcast by N-f, that is, 7-2=5 consensus nodes, have been received, the binary consensus algorithm that can be voted again has started to be executed with the priority voting value 1 as input for the 5 consensus proposals. , the initial voting value of the remaining two proposals to be consensus that have not started to implement the re-voting binary consensus algorithm can be determined as the other voting value 0, and start to execute the re-voting binary consensus algorithm.

At the same time, after the target node receives the pending consensus proposal broadcast by any consensus node, if it has started to execute the binary consensus algorithm that can be voted again for the pending consensus proposal, and the initial voting value of the pending consensus proposal is 0 , and the consensus result of the pending consensus proposal has not been obtained, the initial voting value of the pending consensus proposal is re-determined as the priority voting value.

The reliable broadcast RBC protocol can ensure that the target node will only receive once when receiving any pending consensus proposal, instead of receiving the same pending consensus proposal multiple times. consensus algorithm, and then receive the proposal to be consensus, it means that the initial voting value of the proposal to be The voting value of 1 is the input to trigger the execution of the re-voting binary consensus algorithm again.

In the above S203, it can be for any proposal to be agreed upon. When it is determined that the proposal to be agreed upon has an initial voting value, the binary consensus algorithm that can be voted for is then used to determine the consensus result of the proposal to be agreed upon. Specifically, it can be For any consensus proposal, if it is determined that the consensus proposal has an initial voting value, the initial voting value will be used as the input of the re-voting binary consensus algorithm, and the output of the algorithm will be used as the consensus proposal consensus results.

It can be seen that the Byzantine fault tolerance method proposed in this specification does not need to wait for the execution of the binary consensus steps of the N-f consensus nodes to be proposed before starting to execute the binary consensus steps of the remaining f pending consensus proposals. Instead, it is based on The reception of each pending consensus submission directly determines the initial voting value of each pending consensus proposal, and triggers the execution of the binary consensus process of each pending consensus proposal. From this perspective, the execution of any pending consensus proposal’s binary consensus process , does not need to rely on the completion of the consensus of other pending consensus proposals, so the consensus process of each pending consensus proposal is processed in parallel, thus shortening the duration of each consensus process and improving consensus efficiency.

As shown in Figure 3, compared to the existing Byzantine fault-tolerant algorithm based on binary consensus shown in Figure 1, there are still 7 consensus nodes in the figure, that is, N is 7, f is 2, and the target node receives the node After the pending consensus proposal of node 0-node 4, the re-voting binary consensus algorithm RABA (reproposable asynchronous binary agreement) will be executed for the pending consensus proposal of node 0-node 4, that is, the input of RABA ₀ -RABA ₄ will be set 1 (priority voting value) and start execution, and directly set the inputs of RABA 5 and RABA 6 corresponding to nodes ₅ and ₆ to 0 (other voting values) and start execution, that is, after receiving Nf consensus nodes In the case of the last consensus proposal of the pending consensus proposal, it starts to trigger the execution of the remaining f pending consensus proposals that have not yet started to execute RABA. As shown in the figure, node 3 starts to execute RABA ₃ with 1 as input , the inputs of RABA ₅ and RABA ₆ are both set to 0, triggering the execution of RABA ₅ and RABA ₆ . In addition, after the input of RABA 5 and RABA 6 of node ₅ and node ₆ is set to 0, and the output results of RABA ₅ and RABA ₆ have not been obtained, if the pending consensus proposal of node 5 and node 6 is received, then it can Change the input of RABA ₅ and RABA ₆ to 1, and trigger the execution of RABA ₅ and RABA ₆ again to get the output of RABA ₅ and RABA ₆ . Different from what is shown in Figure 1, the Byzantine fault tolerance method proposed in this specification does not execute ABA ₅ and ABA ₆ after the ABA process of node 0-node 4 to be proposed by consensus is executed. The meta-consensus process, that is, the ABA process, takes a long time. If you wait for the end of the binary consensus process of Nf consensus proposals to be proposed, and then serially execute the remaining f ABA processes to be proposed by consensus, the overall consensus process will take a long time. Long, in the Byzantine fault tolerance method proposed in this note, it can guarantee that the binary consensus process of each proposal to be consensus is basically processed and occurred in parallel. Therefore, the duration of each consensus process is significantly shortened and the consensus rate of each consensus is improved efficiency.

The new parallel binary consensus method proposed in this manual is the proposed Byzantine Fault Tolerance method. In addition to being applied to the blockchain network, it can also be applied to multiple directions such as multi-party secure computing and interactive consistency.

The re-voting binary consensus algorithm in the above S203 is described below. The re-voting binary consensus algorithm proposed in this manual refers to allowing the input of any proposal to be consensus to be changed from other voting values to priority voting value, and the output consensus result is biased towards the binary consensus algorithm of the priority voting value.

A re-voting binary consensus algorithm can be implemented in a variety of ways. The implementation of a specific re-voting binary consensus algorithm will be described below. It is understandable that other re-voting binary consensus algorithms can also be used. The algorithm implements the Byzantine fault tolerance method proposed in this specification, and this specification does not limit the specific implementation of the re-voting binary consensus algorithm.

As shown in Figure 4, the algorithm includes:

S401, for any consensus node's pending consensus proposal, determine the initial voting value and initial auxiliary value corresponding to the pending consensus proposal;

S402, broadcasting the first-round consensus message carrying the initial voting value and the initial auxiliary value;

S403. Reach a consensus on the priority voting value according to the first-round consensus message and the first-round consensus strategy for the proposal to be consensus broadcast by other consensus nodes.

Voting value, which is used to represent the consensus opinion of each consensus node on the data, where the voting value includes two values: priority voting value and other voting value, that is, each consensus node can have two kinds of consensus opinions on consensus proposals, priority voting value and In an embodiment, other voting values may be represented by 1 and 0 respectively. The auxiliary value is a kind of auxiliary opinion proposed in this specification to assist each node to reach a consensus on the proposal to be consensus, which includes the priority voting value, other voting values and null values.

In S401, the initial voting value and the initial auxiliary value are determined for the consensus proposal. The initial auxiliary value can be empty by default, and the initial voting value can be determined according to the content in S202 above. It will not be described in detail here, and it is directly based on the results obtained in S202. Execute S402 for the initial voting value, which can be understood here as the re-voting binary consensus algorithm receives the input of the upload protocol and determines the initial voting value of the consensus proposal;

In S401, when the target node determines the initial voting value, regardless of whether the initial voting value is the priority voting value or other voting values, the target node can execute S402, that is, broadcast the initial voting value and initial auxiliary value, and receive other voting values. The consensus node broadcasts the initial voting value and initial auxiliary value for the consensus proposal.

In addition, this specification proposes that in order to enable each consensus node to quickly reach a consensus on the priority voting value in the first round of consensus process, it allows the target node to receive the priority voting value in the case of the determined initial voting value. After the consensus proposal, the initial voting value can be re-determined as the priority voting value. The process of S202 above can be referred to, and S401-S403 can be triggered again.

In the above S402, specifically, the method shown in FIG. 5 may be executed:

S501, carrying the initial voting value and the initial auxiliary value in the first round of the first type of consensus message for broadcasting;

The target node can add the locally determined initial voting value and initial auxiliary value to the first round of the first type of consensus message, and transmit the first round of the first type of consensus message to other consensus nodes in the distributed system through the authentication channel. When there is no authentication channel, in order to ensure the security of data transmission, cryptographic tools such as digital signatures or public key technology facilities can also be used to ensure the security of consensus message transmission, which is not limited in this specification. In one embodiment, the first type of consensus message can be a message in bval _r format, and the target node can broadcast a message in the form of bval _r (est _r , maj _r ), where est _r is a voting value, maj _r is an auxiliary value, and voting The value est _r is a binary number (0 or 1), maj _r ∈ {0,1,⊥}, in the first round, maj _r is set to be empty, r is the consensus round, the first round is the 0th round, and the consensus round starts from Start with 0 and increment in steps of 1.

S502, receiving the first round of first-type consensus messages broadcast by other consensus nodes;

It is understandable that all the correct nodes in the distributed system are executing the steps performed by the target node, that is, other consensus nodes will also send the first round of the first category including the initial voting value and initial auxiliary value for the proposal to be consensus. Consensus message; at this point, the target node will receive the first round of the first type of consensus message sent by other consensus nodes.

In one embodiment, if the target node receives f+1 first-round consensus messages in the first round of consensus, that is, the first-round consensus messages exceeding the number of malicious nodes, if the f+1 first-round consensus messages The voting values in one type of consensus messages are the same and inconsistent with the voting values of the local broadcast. The target node modifies the local initial voting value to the voting value in the f+1 first type of consensus messages, and broadcasts the first type of consensus messages again. Consensus news. For example, if the target node receives f+1 bval ₀ (b,⊥) messages, and b is not equal to the vote value of the target node’s first broadcast in the current round, the target node will broadcast bval ₀ (b,⊥). The purpose of this step is to allow the local node to correct the local voting value.

S503. Re-determine the voting value and auxiliary value based on the initial voting value and the first-round first-type consensus message broadcast by other consensus nodes, and carry the re-determined voting value and auxiliary value in the first-round second-type consensus message to broadcast.

Among them, each consensus node only sends the second type of consensus message once per round, and the specific way to determine the information carried in the second type of consensus message can be as follows:

In one embodiment, when the initial voting value broadcast locally through the first type of consensus message is the priority voting value for the first time, the initial voting value is added to the first set; and the first set The voting value of is determined as the voting value and auxiliary value in the second type of consensus message in the first round.

Combined with the above example, the target node broadcasts bval ₀ (est ₀ , maj ₀ ) message, where est ₀ is 1 (priority voting value), then 1 can be directly stored in bin_values ₀ (the first set of the first round, r=0) and Broadcast aux ₀ (1,1). Where aux _r is the second type of consensus message format.

In one embodiment, when the initial voting value broadcast by the target node through the first type of consensus message for the first time is not the priority voting value, if f+1 first-round first-type consensus messages broadcast by other consensus nodes are received, And the voting values carried in the f+1 first-type consensus messages are priority voting values, then the priority voting values are added to the first set of the first round, and the first set of the first round The voting value of is determined as the voting value and auxiliary value in the second type of consensus message in the first round.

For example, if the target node receives f+1 bval ₀ (b,⊥) messages, where b=1 is the priority voting value, then store b in bin_values ₀ ; if the target node has not sent aux ₀ at this time () message, broadcast aux ₀ (1,1).

In one embodiment, when the initial voting value broadcast by the target node through the first type of consensus message for the first time is not the priority voting value, if a quorum of the first round of the first type of consensus message broadcast by other consensus nodes is received, and If the voting values carried in the quorum of first-class consensus messages are not priority voting values, that is, they are all other voting values, the other voting values are added to the first set of the first round, and the first round The voting value in the first set is determined as the voting value and auxiliary value in the second type of consensus message in the first round. Among them, the quorum is 2f+1 consensus nodes (including its own nodes). Unless otherwise specified, the quorum below is 2f+1.

For example, if the target node receives 2f+1 bval ₀ (b,⊥) messages, where b is 0, that is, it is not a priority voting value, the target node will add b to the set bin_values _0. If the target node is still If no aux ₀ () message has been sent, broadcast aux ₀ (0,0).

In the above method, after the target node locally broadcasts the priority voting value through the first type of consensus message, it can directly broadcast the priority voting value through the second type of consensus message without referring to the opinions of other consensus nodes. The purpose is also to make each node A consensus can be quickly reached on the priority voting value, and at the same time, after re-voting, the consensus progress for the priority voting value can exceed the consensus progress for other voting values.

After the target node receives the first-round consensus message broadcast by other consensus nodes, it can determine whether it can reach a consensus on the priority voting value according to the first-round consensus strategy. The first-round consensus strategy is to make each consensus node Strategies that enable rapid consensus on said preferred voting value in the first round.

In one embodiment, the first-round consensus strategy can specifically be:

After receiving a quorum of first-round consensus messages of the second type, the voting value in the second-type consensus messages received will be stored in the second set of the first round, and the auxiliary value will be stored in the third set of the first round ;Set the value of the first round of public coin toss as the priority voting value;

In the case that only one voting value is included in the second set of the first round, if more than (N+f+1)/2 second-type consensus messages carrying priority voting values are received, the consensus result is determined to be the priority Voting value; if more than (N+f+1)/2 second-type consensus messages carrying other voting values are received, the voting value and auxiliary value carried in the second-round first-type consensus message are set as other voting values value.

For example, after the target node receives Nf aux ₀ () messages (the second type of consensus messages in the first round), the target node will store the voting value and auxiliary value in the received aux ₀ () messages in vals ₀ (first round in the second set of the round) and avals ₀ (the third set of the first round). If, the set vals ₀ contains only b, where b is 0 or 1, and more than (N+f+1)/2 aux ₀ (b,*) of the same b is received, * can be 0, 1 or empty Any value of , and b=1 (priority voting value), then the consensus result is determined to be 1; if b=0, the target node will compare est _r+1 (the voting value of the next consensus round) with maj _r+1 ( The auxiliary value of the next consensus round) are all set to b.

In addition, if no more than (N+f+1)/2 second-type consensus messages carrying the same voting value are received, the voting value and auxiliary value carried in the second-round first-type consensus message are set as priority voting value.

Combining the above example, if the target node does not receive more than (N+f+1)/2 second-type consensus messages carrying the same voting value, then both est _r+1 and maj _r+1 are set to 1.

It can be seen that adopting the above-mentioned first-round consensus strategy can enable each consensus node to quickly reach a consensus on the priority voting value, which improves the consensus efficiency.

The above S401-S403 are the first-round consensus method of the re-voting binary consensus algorithm, and the other rounds of consensus methods are introduced below:

Except for the first round, the consensus of the other rounds is reached by the method shown in Figure 6:

In the case that no consensus is reached on the priority voting value in the first round, S601-S602 can be executed cyclically until the consensus result for the pending consensus proposal is obtained:

S601. Broadcast the consensus message of the current round, and the consensus message carries the voting value of the current round and the auxiliary value;

S602. Based on the received voting value and auxiliary value for the proposal to be consensus broadcast by other consensus nodes, determine whether to obtain a consensus result.

Wherein, in S601, it may specifically be:

S601a, carrying the voting value and the auxiliary value in the first type of consensus message for broadcasting;

S601b, receiving the first type of consensus message broadcast by other consensus nodes;

S601c. Re-determine the voting value and the auxiliary value based on the received first-type consensus message, and broadcast the re-determined voting value and auxiliary value in the second-type consensus message.

Among them, the process of S601a-S601b can refer to the content in the above-mentioned S501-S502, which will not be described in detail here. The only difference is that the voting value and auxiliary value broadcast in the first type of consensus message are not the initial voting value and initial auxiliary value. , but after the first round of consensus, the voting value and auxiliary value are re-determined based on the message transmission results. For details, please refer to the above-mentioned part about S403 and subsequent S602, which will not be described in detail here.

In S601c, after receiving a quorum of first-type consensus messages, the target node re-determines the voting value and the auxiliary value according to the received first-type consensus messages.

Specifically, if the voting values in the 2f+1 first-type consensus messages are the same, the target node will add the voting values to the first set. For example, if the target node receives 2f+1 bval _r (b,*) messages, b∈{0,1}. Then the target node adds b to the first set bin_values _r . In addition, the target node also adds the auxiliary values in the above 2f+1 first-type consensus messages to the auxiliary value set majs. In this step, if a quorum of the same voting value is received, the voting value is stored in the first set, which means that most nodes in the system may have reached a consensus. The target node can compare the voting value in the first set with the public coin toss value of the previous round, and determine the voting value and auxiliary value carried in the second type of consensus message according to the comparison result. Among them, the public coin toss value has only two values of 0 or 1. Each consensus node can obtain the same public coin toss value in a certain round, and the value of each round of coin toss is random except for the first round. The method of currency value can be obtained by means of threshold signature algorithm, etc., and the specific content can refer to related technologies, which are not limited here.

The specific way to determine the voting value and auxiliary value carried in the second type of consensus message according to the comparison result can be as follows:

One situation is that if the voting value in the first set is equal to the public coin toss value of the previous round, and the voting values carried in the first type of consensus messages received by the target node are all voting values in the first set, The auxiliary values carried are all voting values in the first set or empty, then set the voting values and auxiliary values in the second type of consensus message as the voting values in the first set and broadcast; if the carrying For the first type of consensus message with other voting values, the voting value in the second type of consensus message is set to be empty, and the auxiliary value in the second type of consensus message is set as the voting value in the first set.

Continuing the above example, if the voting value in the first set is b, the value of the public coin toss in the last round is S _r-1 , if b=S _r-1 , and the target node has only received bval _r (b,b) and bval _r (b,⊥) messages, broadcast aux _r (b,b) directly, and broadcast aux _r (⊥,b) if the first type of consensus message carrying other voting values is also received.

Another situation is that if the voting value in the first set is not equal to the public coin toss value of the previous round, and the voting value and auxiliary value carried in the first type of consensus message received by the target node are both the first set In the case of the voting value in the second consensus message, set the voting value and auxiliary value in the second type of consensus message as the voting value in the first set and broadcast it; If one type of consensus message is used, the voting value in the second type of consensus message is set to be empty, and the auxiliary value in the second type of consensus message is set as the voting value in the first set. Continuing the above example, if the voting value in the first set is b, the value of the public coin toss in the last round is S _r-1 , if

in,

Since the coin toss value has only two values, 0 or 1, and the voting value has only two values, 0 or 1, so when the voting value b is not equal to the coin toss value S _r-1 , it is equal to 1-S _r-1 , that is

In this case, and the target node has only received the bval _r (b, b) message, it will broadcast aux _r (b, b) directly. If it has also received the first type of consensus message carrying other voting values or auxiliary values, Then broadcast aux _r (⊥,b).

Each consensus node only broadcasts the second consensus information once in each round. The above method is the method for the target node to determine the voting value and auxiliary value carried in the second type of consensus message not in the first round.

When the target node sends the second type of consensus message, since other consensus nodes will also send the second type of consensus message asynchronously, the target node will receive the second type of consensus message sent by other consensus nodes. After the target node receives the consensus messages sent by other consensus nodes, it can first delete some obviously illegal second-type consensus messages. According to the above content, since the correct consensus node will only broadcast aux _r (b,b) And the second type of consensus message of aux _r (⊥,b), so when receiving a message carrying other voting values or auxiliary values, it can be discarded directly, because the voting value in the second type of consensus message is stored in the first set Therefore, after receiving the second type of consensus message, the first set can be used to determine legal and illegal messages.

In the above S602, the target consensus node determines whether a consensus result is obtained based on the received voting value and auxiliary value. If no consensus result is obtained, the next round of voting value and auxiliary value is determined, and execution of S601 is restarted.

The following is a detailed description of how the target consensus node determines the consensus result based on the received voting value and auxiliary value, and determines the next round of voting value and auxiliary value:

After the target node receives a quorum of second-type consensus messages, it can store the voting value and auxiliary value in the second-type consensus messages received in the second set vals _r and the third set avals _r respectively, and obtain The unified public coin toss value of all consensus nodes in this round. For example, after receiving 2f+1 aux _r () messages, the target node can store the voting value and auxiliary value in the received aux _r () messages into the sets vals _{r (} second set) and avals _r (the second set) respectively three sets). The target node can determine the consensus result, or the voting value and auxiliary value carried by the first type of consensus message in the next round of consensus according to the situation of the second type of consensus message received:

(a) If there are more than quorum of the second consensus messages received by the target node that are the same, and the voting value in these second consensus messages is the same as the auxiliary value, the target node will The voting value in the second type of consensus message is compared with the current round of public coin toss value. If the voting value is the same as the current round of public coin toss value, the target consensus node determines that the consensus result is the voting value; if not, the target node will The voting value and auxiliary value carried in the first type of consensus message in the next round are set as the voting value in these second type of consensus messages, and the next round of consensus is started.

For example, if the target node receives a quorum of aux _r (b, b) information, the target node will compare b with the current round of public coin toss S _r . If b=S _r , the target node determines that the consensus result is b; otherwise, the target node sets both est _r+1 and maj _r+1 to b, and enters into the next round of consensus.

(b) If the target node has only received legitimate second-type consensus messages, and the voting value in the second set is a voting value and empty, and there are at least a quorum of second-type consensus messages whose auxiliary values are For this type of voting value, compare this type of voting value with the public coin value of the previous round of consensus and the current round of consensus. If this type of voting value is the same as the public coin toss value of the previous round and this round, the target node determines that the consensus result should be this type of voting value. If the currency values are different, the target consensus node will set the voting value and auxiliary value in the first type of consensus message in the next round as this type of voting value, and start the next round of consensus.

For example, if the target node has only received aux _r (b,*) and aux _r (⊥,*), and there is at least a quorum of second-class consensus messages for aux _r (*,b), then the target node compares b with Two rounds of public coin flips S _{r - 1} are compared with S _r . If b=S _r-1 and b=S _r , the target node determines that the consensus result is b, otherwise the target node sets both est _r+1 and maj _r+1 to b, and enters the next round.

(c) If the target node has received a quorum of legitimate second-type consensus messages, and the auxiliary values carried by the quorum of second-type consensus messages are not exactly the same, the voting value in the second set is a voting value and an empty , and this type of voting value is the same as the previous round of public coin toss, the target consensus node will set the voting value and auxiliary value in the first type of consensus message in the next round of consensus as this type of voting value, and start to execute the next round of consensus. For example, if the target node receives Nf aux _r (b,*) and aux _r (⊥,*) messages, which contain both aux _r (*,0) and aux _r (*,1), and b=S _{r -1} , the target node sets both est _r+1 and maj _r +1 to b, and enters the next round of consensus.

(d) If the second type of consensus message received by the target node does not belong to the above three situations, that is, if the received second consensus message includes two voting values; The auxiliary value carried by the second type of consensus message is different, the voting value in the second set is a kind of voting value and empty, and this kind of voting value is different from the previous round of public coin flip; The coin toss value is used as the voting value of the first type of consensus message in the next round, and the auxiliary value in the first consensus message of the next round is set to a value whose occurrence times in the second set exceeds the preset number of times, and enters the next round of consensus .

For example, if the second type of consensus message received by the target node does not belong to the above three situations, the target node will use the public coin toss value of the current round as the next round input (that is, set est _r+1 to S _r ). The target node sets maj _r+1 as majority(vals _r ), where majority(vals _r )=b, b∈{0,1}, which means that b appears in the majority of vals _r , that is, b in vals _r The number is not less than

If there is no such b, let majority(vals _r )=⊥.

It can be understood that the above method is the method executed by any correct node among the consensus nodes, and other correct consensus nodes are also executing the above method asynchronously. Using the above method, set the priority voting value, and each consensus node in the first round Probability can reach a consensus on the priority voting value, and can make each consensus node in the distributed system in the asynchronous environment quickly reach a consensus state on the priority voting value, which greatly improves the consensus efficiency of the distributed system in the asynchronous environment. Because of the binary consensus algorithm that can be voted again, the target node can determine the initial voting value multiple times for any proposal to be consensus, specifically when the initial voting value of a proposal to be consensus is determined to be 0 for other voting values , start to execute the binary consensus algorithm that can be voted again with the other voting value 0 as input, and if the consensus result is not obtained, and the pending consensus proposal is received, then you can vote again, that is, re-determine the consensus of the pending consensus proposal The result is the priority voting value of 1, and the re-voting binary consensus algorithm is executed again with the priority voting value of 1 as input, and because the re-voting binary consensus algorithm is biased towards the priority voting value to reach a consensus, and the high probability is in In the first round of consensus, consensus can be reached based on the priority voting value, and consensus cannot be reached based on other voting values in the first round of consensus. In both cases, the algorithm executes faster when the input is 1, therefore, the Byzantine fault-tolerant method proposed in this specification can be realized by using the re-voting binary consensus algorithm.

At the same time, adopting a re-voting consensus algorithm can ensure that the consensus nodes in the distributed system meet the following properties, that is, the following technical effects:

Validity: In the case that the voting value broadcast by all correct nodes is v, and no other voting value is broadcast again, then the consensus result of all correct nodes is the voting value v;

Unanimous termination: when all correct nodes broadcast the same voting value v and do not broadcast other voting values again, then all correct nodes can terminate the consensus operation, that is, reach a consensus;

Consensus: If any correct node determines that a certain voting value v is the consensus result, then other correct nodes that terminate the consensus operation will also determine that the voting value v is the consensus result;

Biased validity: If f+1 correct nodes broadcast the voting value v, then the correct node can determine that the voting value v is the consensus result when terminating the consensus;

Biased termination: If Q is a set of correct nodes, where Q1 is the set of correct nodes that broadcast a vote value of 1 but did not broadcast a vote value of 0 again, and Q2 is the set of correct nodes that broadcast a vote value of 0 and again broadcast a vote value of 1 set if

And Q=Q1∪Q2, then all correct nodes will reach a consensus;

Integrity: Correct nodes reach consensus on a proposal only once.

It can be understood that the content involved in Figure 4, Figure 5, Figure 6 and the relevant parts of Figure 4, Figure 5 and Figure 6 are all a specific implementation of the re-voting binary consensus algorithm, and other re-voting can also be used The Binary Consensus Algorithm implements the Byzantine consensus method described in this manual. This manual does not limit this, nor does it describe other binary consensus algorithms that can be voted in detail, as long as the input for any proposal to be consensus is allowed to be determined by Other voting values are changed to the priority voting value, and the output consensus result is biased towards the binary consensus algorithm of the priority voting value, and the binary consensus algorithm that satisfies the relevant properties of the above-mentioned re-voting binary consensus algorithm includes Within the scope of the re-voting binary consensus algorithm proposed in this specification.

Using the above Byzantine fault-tolerant method, N consensus results can be obtained for the pending consensus proposals proposed by the N consensus nodes in the distributed system. After obtaining the consensus results of the N pending consensus proposals, the consensus results are at least A set of pending consensus proposals is determined as the pending consensus set; after receiving all the pending consensus proposals in the pending consensus set, execute the pending consensus proposals in the set according to the preset order.

For example, after reaching a consensus on the consensus proposals proposed by all consensus nodes, each correct consensus node will get the same consensus result, which is a sequence containing 0 and 1. For example, there are 7 consensus nodes P ₁ -P ₇ , Among them, the consensus result of the ₆ pending consensus proposals corresponding to P ₁ -P 6 is 1, and the consensus result of the pending consensus proposal corresponding to P ₇ is 0, then the set of pending consensus proposals corresponding to P ₁ -P ₆ is determined to be consensus Set S, any correct consensus node at this time will get such a set to be consensus, but it may not have received some proposals to be consensus in the set S to be consensus, because it uses the reliable broadcast RBC protocol The broadcasted consensus proposal, therefore, can ensure that the consensus node can receive all the consensus proposals in the consensus set S. Based on this, the consensus node can continue to wait until it receives all the consensus proposals in the consensus set S After that, all the proposals to be agreed in the consensus set S can be executed according to the preset execution sequence, that is, the proposals to be agreed on P ₁ -P ₆ are executed.

Still taking the blockchain network as an example, in the blockchain network, 0 or 1 is used to indicate whether to pack the corresponding consensus proposal into a block. For example, there are four consensus nodes. The consensus proposal proposed by consensus node 1 is P1, the consensus proposal proposed by consensus node 2 is P2, the consensus proposal proposed by consensus node 3 is P3, and the consensus proposal proposed by consensus node 4 is P4. The fault-tolerant method obtains a 01 sequence after consensus, for example, the obtained sequence is (1,1,1,0), then the consensus result reached is that all nodes pack P1, P2, and P3 into blocks and store them locally, and do not store P4. That is, each consensus node performs consistent processing on each consensus proposal according to the consensus result to ensure the data consistency of each consensus node.

The following describes S201-S203 of this manual from the perspective of code implementation:

The pseudo code is as follows:

In the above pseudo-code, the r-broadcast and r-deliver primitives in RBC are used, as well as RABA primitives such as propose, repropose, and decide. For each epoch, the framework includes n parallel RBC instances and n parallel RABA instances.

In the RBC phase, each replica p _i broadcasts a proposal m _i for the RBC instance RBC _i . If p _i r-delivers proposal m _j in RBC _j instance, p _i will start running RABA _j and propose1 in RABA _j . After Nf RBC instances have r-delivered the proposal, p _i does not need to wait for the termination of nf RABA instances, but directly propose0 in those RABA instances that have not started running. If p _i propose0 in RABA _j , r-deliver the proposal m _j , and RABA _j has not terminated, then p _i will repropose1 in RABA _j . Let S denote the set of RABA instance numbers for which the value of decide is 1. If p _i is decide 1 in the RABA _j instance, add the proposal m _j proposed by p _j for RBC _j to the set C. If for any j∈S, r-deliver([e,j],m _j ) has been done in the RBC _j instance, then confirm and execute the messages in the C set in a deterministic order.

As shown in Figure 7, corresponding to the above-mentioned Byzantine fault-tolerant method, this specification also provides a Byzantine fault-tolerant device, which is applied to any consensus node in a distributed system, and the distributed system includes at least N consensus nodes , wherein N≥3f+1, the f is an integer greater than 0, and the device includes:

The communication module 710 is used to broadcast the local consensus proposal to other consensus nodes based on the reliable broadcast RBC protocol;

The processing module 720 is used to determine the initial voting value of the consensus proposal based on the local reception situation for any consensus node's pending consensus proposal; the initial voting value is the priority voting value or other voting values; for any consensus node with the initial voting value When the consensus is proposed, a re-voting binary consensus algorithm is used to determine the consensus result.

In one embodiment, the processing module 720 is specifically configured to, in the case of receiving a proposal to be consensus broadcast by any consensus node through the reliable broadcast RBC protocol, if the proposal to be consensus has not yet started to execute the reproducible In the binary consensus algorithm for voting, the initial voting value of the proposed consensus proposal is determined as the priority voting value;

If the binary consensus algorithm that can be voted again has been implemented for the proposal to be consensus, and the consensus result of the proposal to be consensus has not been obtained, the initial voting value of the proposal to be consensus is re-determined as the priority voting value;

In one embodiment, the processing module 720 is specifically configured to use the initial voting value as the re-voting binary if it is determined that the consensus proposal has an initial voting value for any proposal to be agreed upon. The input of the consensus algorithm takes the output of the algorithm as the consensus result of the proposal to be consensused.

In one embodiment, the re-voting binary consensus algorithm includes: a binary algorithm that allows the input of any proposal to be consensus to be changed from other voting values to priority voting values, and the output consensus result is biased towards the priority voting value. Meta Consensus Algorithm.

In one embodiment, the processing module 720 is specifically configured to, after obtaining the consensus results of the N proposals to be consensus, determine a set consisting of at least one proposal to be consensus whose consensus result is a priority voting value as the set to be agreed upon; After receiving all the pending consensus proposals in the pending consensus set, execute the pending consensus proposals in the pending consensus set in a preset order.

For the implementation process of the functions and effects of each component in the above-mentioned device, please refer to the implementation process of the corresponding steps in the above-mentioned method for details, and details will not be repeated here.

As for the device embodiment, since it basically corresponds to the method embodiment, for related parts, please refer to the part description of the method embodiment. The device embodiments described above are illustrative only. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. It can be understood and implemented by those skilled in the art without creative effort.

The embodiment of this specification also provides a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and operable on the processor, wherein the aforementioned method is implemented when the processor executes the program. The method includes at least the method shown in FIG. 2 above.

FIG. 8 shows a schematic diagram of a more specific hardware structure of a computing device provided by the embodiment of this specification. The device may include: a processor 1010 , a memory 1020 , an input/output interface 1030 , a communication interface 1040 and a bus 1050 . The processor 1010 , the memory 1020 , the input/output interface 1030 and the communication interface 1040 are connected to each other within the device through the bus 1050 .

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit, central processing unit), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, and is used to execute related programs to realize the technical solutions provided by the embodiments of this specification.

The memory 1020 can be implemented in the form of ROM (Read Only Memory, read-only memory), RAM (Random Access Memory, random access memory), static storage device, dynamic storage device, etc. The memory 1020 can store operating systems and other application programs. When implementing the technical solutions provided by the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1020 and invoked by the processor 1010 for execution.

The input/output interface 1030 is used to connect the input/output module to realize information input and output. The input/output/module can be configured in the device as a component (not shown in the figure), or can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, and the like.

The communication interface 1040 is used to connect a communication module (not shown in the figure), so as to realize the communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.), and can also realize communication through wireless means (such as mobile network, WIFI, Bluetooth, etc.).

Bus 1050 includes a path that carries information between the various components of the device (eg, processor 1010, memory 1020, input/output interface 1030, and communication interface 1040).

It should be noted that although the above device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in the specific implementation process, the device may also include other components. In addition, those skilled in the art can understand that the above-mentioned device may only include components necessary to implement the solutions of the embodiments of this specification, and does not necessarily include all the components shown in the figure.

The embodiment of the present specification also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the aforementioned method is implemented. The method includes at least the method shown in FIG. 2 above.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, A magnetic tape cartridge, disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It can be known from the above description of the implementation manners that those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the essence of the technical solutions of the embodiments of this specification or the part that contributes to the prior art can be embodied in the form of software products, and the computer software products can be stored in storage media, such as ROM/RAM, A magnetic disk, an optical disk, etc., include several instructions to enable a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this specification.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for relevant parts, please refer to part of the description of the method embodiments. The device embodiments described above are only illustrative, and the modules described as separate components may or may not be physically separated, and the functions of each module may be integrated in the same or multiple software and/or hardware implementations. Part or all of the modules can also be selected according to actual needs to achieve the purpose of the solution of this embodiment. It can be understood and implemented by those skilled in the art without creative effort.

The above is only the specific implementation of the embodiment of this specification. It should be pointed out that for those of ordinary skill in the art, without departing from the principle of the embodiment of this specification, some improvements and modifications can also be made. These Improvements and modifications should also be regarded as the scope of protection of the embodiments of this specification.

Claims

A Byzantine fault-tolerant method, characterized in that it is applied to any consensus node in a distributed system, and the distributed system includes at least N consensus nodes, and a maximum of f malicious nodes are allowed to exist in the N consensus nodes, wherein N ≥3f+1, the f is an integer greater than 0, and the method includes:

Based on the reliable broadcast RBC protocol, the local consensus proposal is broadcast to other consensus nodes;

In the case of receiving a consensus proposal broadcast by any consensus node through the reliable broadcast RBC protocol, if the re-voting binary consensus algorithm has not been started for the consensus proposal, the initial The voting value is determined as the priority voting value; if the re-voting binary consensus algorithm has been executed for the pending consensus proposal, and the consensus result of the pending consensus proposal has not been obtained, the initial voting of the pending consensus proposal The value is determined as the priority voting value;

In the case of receiving the pending consensus proposal broadcast by N-f consensus nodes, the initial voting value of the pending consensus proposal that has not started to execute the re-voting binary consensus algorithm is determined as other voting value;

For any pending consensus proposal with an initial voting value, a re-voting binary consensus algorithm is used to determine the consensus result.
The method according to claim 1, characterized in that, for any proposal to be agreed upon with an initial voting value, the consensus result is determined using a re-voting binary consensus algorithm, including:

For any consensus proposal, if it is determined that the consensus proposal has an initial voting value, the initial voting value will be used as the input of the re-voting binary consensus algorithm, and the output of the algorithm will be used as the consensus proposal consensus results.
The method according to claim 2, wherein the re-voting binary consensus algorithm comprises:

A binary consensus algorithm that allows the input of any proposal to be consensus to be changed from other voting values to the priority voting value, and the output consensus result is biased towards the priority voting value.
The method according to claim 1, further comprising:

After obtaining the consensus results of the N pending consensus proposals, the set of at least one pending consensus proposal whose consensus result is the priority voting value is determined as the pending consensus set;

After receiving all the proposals to be agreed in the set to be agreed, execute the proposals to be agreed in the set according to the preset order.
A Byzantine fault-tolerant device is characterized in that it is applied to any consensus node in a distributed system, and the distributed system includes at least N consensus nodes, and a maximum of f malicious nodes are allowed to exist in the N consensus nodes, where N ≥3f+1, the f is an integer greater than 0, and the device includes:

The communication module is used to broadcast the local consensus proposal to other consensus nodes based on the reliable broadcast RBC protocol;

The processing module, in the case of receiving a consensus proposal broadcast by any consensus node through the reliable broadcast RBC protocol, if the binary consensus algorithm that can be voted again has not been started for the consensus proposal, then the consensus proposal The initial voting value of the proposal is determined as the priority voting value; if the re-voting binary consensus algorithm has been implemented for the pending consensus proposal, and the consensus result of the pending consensus proposal has not been obtained, the pending consensus proposal will be re- The initial voting value of is determined as the priority voting value; in the case of receiving the consensus proposal broadcast by N-f consensus nodes, the initial voting value of the pending consensus proposal that has not started to execute the re-voting binary consensus algorithm is determined as other Voting value: For any proposal to be consensus with an initial voting value, a re-voting binary consensus algorithm is used to determine the consensus result.
The device according to claim 5, characterized in that,

The processing module is specifically configured to, for any proposal to be consensus, when it is determined that the proposal to be consensus has an initial voting value, the initial voting value is used as the input of the re-voting binary consensus algorithm, and the The output of the algorithm is the consensus result of the proposal to be consensused.
The device according to claim 6, characterized in that,

The re-voting binary consensus algorithm includes: a binary consensus algorithm that allows the input of any proposal to be consensus to be changed from other voting values to priority voting values, and the output consensus result is biased towards the priority voting value.
The device according to claim 5, characterized in that,

The processing module is also used to determine, after obtaining the consensus results of the N proposals to be agreed upon, that the consensus result is a set of at least one proposal to be agreed upon with a priority voting value as the set to be agreed upon; After all the pending consensus proposals are executed, the pending consensus proposals in the set are executed in the preset order.
A computer device, characterized by comprising a memory, a processor, a communication interface, and a computer program stored on the memory and operable on the processor, wherein, when the processor executes the program, it realizes the following claims 1 to 1: 4. The method described in any one.
A computer-readable storage medium, characterized in that a computer program is stored thereon, and when the program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.