Introduction to Byzantine fault-tolerant systems

Introduction to Byzantine fault-tolerant systems

The original Byzantine fault-tolerant system lacked practicality because of the need to demonstrate theoretical feasibility. In addition, the complexity of the algorithm also increases exponentially with the increase of the nodes. The practical Byzantine fault-tolerant system (practical Byzantine Fault tolerance, PBFT) reduces the operational complexity of Byzantine protocols, from the exponential level to the polynomial level, making it possible to apply Byzantine protocols in a distributed system.

What is a practical Byzantine fault-tolerant system

The practical Byzantine fault-tolerant system is a kind of "state machine" Byzantine system (here the state machine can be understood as "system State", in the case of blockchain bookkeeping, the ledger is updated to a new state every new chunk is added to the system.) As mentioned earlier, the Byzantine fault-tolerant system is a strong consistency protocol, and the system will reach a new state after each accounting. ) requires that all nodes of the system maintain a state together, and that all nodes take the same action.

The practical Byzantine fault-tolerant system requires three basic protocols to be run :

• conformance agreements : Resolving how to reach consensus
• Checkpoint protocol : a restore point similar to the operating system
• View Exchange protocol : Each server node of the system works under the same configuration information, which is referred to as a "view". The configuration information is determined by the master node, the master node is replaced, and the view changes.

We focus on consistency protocols that support the daily operation of the system.

PBFT Consistency Protocol

The conformance protocol contains at least three stages of request, Sequence number allocation (Pre-prepare), and Response (reply). Depending on the protocol design, it is possible to include phases such as mutual interaction (prepare), sequence confirmation (commit), and so on.

PBFT systems generally assume that the number of failed nodes is m, while the total number of service nodes is 3m+1.

Shows a simplified protocol communication mode for PBFT, where C is the client, N0~N3 is the service node, N0 is the primary node, and N3 is the fault node. An abridged process of the agreement is as follows:

1. Request: Client sends requests to activate service operation for master node

2. When the primary node receives the request, it initiates a three-phase protocol to broadcast the request to each slave node

   • Pre-prepare: The master node assigns a sequence number n to the request, broadcasts the sequence number to assign the message and requests the message, and constructs the pre-prepare message to each slave node
   • Prepare: Receive pre-prepare messages from a node and broadcast Prepare messages to other service nodes
   • Commit: After each node validates the request and order within the view, it broadcasts a commit message, executes the received client's request and responds to the client
3. Reply: The client waits for a response from a different node, and if there are m+1 responses the same, the response is the result of the operation

PBFT Demo

In the case of N≥3M + 1, consistency is likely to be resolved, where n is the total number of nodes and M is the total number of rogue nodes. Let's simulate the PBFT:

n = 4, m = 0

node	Get the data	Final Result
A	1111	1
B	1111	1
C	1111	1
D	1111	1

n = 4, M = 1

node	Get the data	Final Result
A	1110	1
B	1101	1
C	1011	1
D	0111	1

n = 4,m = 2

node	Get the data	Final Result
A	1100	NA
B	1001	NA
C	0011	NA
D	0110	NA

It can be seen that the practical Byzantine fault tolerant system can accommodate nearly 1/3 of Byzantine nodes.

The practical Byzantine fault-tolerant system has been applied in many scenarios, and it is generally suitable for the private chain and alliance chain scenarios with strong consistency requirements in blockchain applications. For example, in the IBM-led blockchain Super Ledger project, the practical Byzantine fault-tolerant system is an optional consensus protocol.