BFT

A technology used by S0

The Byzantine Fault Tolerance problem is referred to as BFT. BFT is a core problem that needs to be solved in the blockchain consensus algorithm. POW represented by Bitcoin and Ethereum, DPOS represented by EOS, and the consensus algorithm POS that will gradually be replaced by Ethereum in the future, these They are all public chain algorithms, which solve the BFT in the case of many consensus nodes. PBFT is a solution for BFT when there are fewer consensus nodes in the alliance chain. PBFT was used in fabric-0.6.0 version, but it was changed to Kafka in version 1.0.0.

The Practical Byzantine Fault Tolerant System (PBFT) reduces the operating complexity of the Byzantine protocol, from exponential level to polynomial level (Polynomial), making the application of the Byzantine protocol in distributed systems possible. PBFT is a state machine copy replication algorithm, that is, the service is modeled as a state machine, and the state machine is replicated at different nodes in a distributed system. Each copy of the state machine saves the state of the service and also implements the operation of the service. The set consisting of all the copies is represented by a capital letter R, and each copy is represented by an integer from 0 to |R|-1. For the convenience of description, it is usually assumed that the number of failed nodes is m, and the number of entire service nodes is |R|=3m+1, where m is the maximum number of replicas that may fail. Although there can be more than 3m+1 replicas, the additional replicas cannot improve reliability other than reducing performance.

PBFT requires the joint maintenance of a state, and the actions taken by all nodes are consistent. To this end, three types of basic protocols need to be run, including consistency protocols, checkpoint protocols, and view replacement protocols. Our main focus is on consistency protocols that support the daily operation of the system. The consensus protocol includes at least several phases: request (request), sequence number allocation (pre-prepare) and response (reply). Depending on the protocol design, it may include phases such as mutual interaction (prepare) and serial number confirmation (commit).

Figure PBFT protocol communication mode The above picture shows the PBFT protocol communication mode. Each client request needs to go through 5 stages, and the client's request is executed after the server reaches an agreement by using two pairwise interactions. Since the client cannot obtain any information about the running status of the server from the server, whether the master node in PBFT has an error can only be monitored by the server. If the server cannot complete the client's request within a period of time, the view replacement protocol will be triggered. Among them, C is the client, N0~N3 represent the service node, in particular, N0 is the master node, and N3 is the faulty node. The basic process of the entire agreement is as follows:

The client sends a request to activate the service operation of the master node. When the master node receives the request, it initiates a three-phase protocol to broadcast the request to each slave node. (1) In the sequence number allocation phase, the master node assigns a sequence number n to the request, broadcasts the sequence number allocation message and the client's request message m, and constructs a PRE-PREPARE message to each slave node;

(1) In the interactive phase, the PRE-PREPARE message is received from the node, and the PRE-PREPARE message is broadcast to other service nodes;

(2) In the sequence number confirmation stage, after each node verifies the request and order in the view, it broadcasts a COMMIT message, executes the received client's request and responds to the client.