读书笔记（四）--PBFT

Castro, Miguel, and Barbara Liskov. “Practical Byzantine fault tolerance.” OSDI.Vol.99.1999.

A. Problem Statement

The paper targets the problem of the original Byzantine fault-tolerant algorithm is not efficient. Particularly, how to do proof-of-work and how to guarantee the correctness of the system in the case of less than one-third of the evil nodes?

B. Problem Significance

The most important of the blockchains is the consensus algorithm. Bitcoin uses POS (Proof of Work). However, for the license chain or private chain that does not require a monetary system but has an effective demand, the traditional PBFT (Practical Byzantine Fault Tolerance) algorithm becomes the first choice. For the first time, compared to the original BFT algorithm, the algorithm reduces the complexity from exponential to polynomial, making the Byzantine-faulttolerant algorithm feasible in practical system applications.

C. State of the Art

PBFT has five phases: request, pre-prepare, prepare, commit and reply. A brief hypothesis is explained below, assuming there are 4 servers: server 0, server 1, server 2, server 3.
Request: the requester C sends a request to any node.
Pre-prepare: after receiving the request from C, the server 0 broadcasts and spreads to server 1, server 2, server 3.
Prepare: server 1, server 2, server 3, after receiving the record and broadcasting again, server 1 broadcasts to server 0, server 2, server 3, server 2 broadcasts to server 0, server 1, server 3, server 3 because of the downtime cannot broadcast.
Commit: The server 0, server 1, server 2, server 3 is in the Prepare phase if more than a certain number of identical requests are received, the Commit phase is entered, and the Commit request is broadcast.
Reply: The server 0, server 1, server 2, server 3 in the Commit phase if more than a certain number of identical requests are received, feedback is given to C.
Why does it have a commit phase? The Commit phase is used to ensure that other nodes have received enough information to reach a consensus. The Commit phase does not send a consent to disagree with the request as the Prepare phase, only to detect if there is enough commit type information. Because in the Prepare phase, other nodes are not sure that enough consent information has been received and should not be written to the new block from the perspective of data validation. At this time, if a view change occurs, the request of the prepare phase is discarded.
Why does it have a commit phase? The Commit phase is used to ensure that other nodes have received enough information to reach a consensus. The Commit phase does not send a consent to disagree with the request as the Prepare phase, only to detect if there is enough commit type information. Because in the Prepare phase, other nodes are not sure that enough consent information has been received and should not be written to the new block from the perspective of data validation. At this time, if a view change occurs, the request of the prepare phase is discarded.

D. Contributions

This paper describes a state machine replication algorithm that solves the Byzantine-fault-tolerance problem. This algorithm provides (n-1)/3 fault tolerance under the premise of ensuring liveness and safety, n is the number of the nodes. The author believes that the PBFT algorithm will become more important as malicious attacks and software errors will occur more and more, and the failed nodes will behave arbitrarily. Any behavior of these nodes may mislead other replica nodes to cause greater harm, rather than just downtime to lose response. Early Byzantine fault-tolerant algorithms or assumptions based on synchronous systems were too low to operate in real systems. The algorithm described in this paper is practical because it works in an asynchronous environment and improves response performance based on early algorithms. The author used this algorithm to implement the Byzantine Fault Tolerant Network File System (NFS), and performance tests proved that the system was only 3% slower than the standard NFS without copy replication.
Beginning with the introduction of the Byzantine issue in 1982 by Professor Lamport, there have been a number of algorithms to solve Byzantine-fault-tolerance. The PBFT algorithm is completely different from these algorithms. In the read-only operation, only one message round trip is used. In the write-only operation, only two message round-trips are used, and the Message Authentication Code is used in normal operations, the public-key cryptography that caused the performance of the previous algorithm to be inferior was only used in the event of a failure. The author not only proposes an algorithm but also uses this algorithm to implement a powerful system (NFS).
Sum up the contributions of the paper here:

First proposed to use the state machine replica replication protocol in an asynchronous network environment
Use a variety of optimizations to significantly improve performance
Implementing a Byzantine-fault-tolerant distributed file system
Provide experimental data support for performance loss of copy replication

E. Remaining Questions

Does the PBFT algorithm has poor scalability in a blockchain system with too many nodes? Is it only suitable for the alliance chain? But combined with the content of the class, I think the basis of the Byzantine-fault-tolerant algorithm works for a large number of nodes. If there are too few nodes, it will easily break through to 51% of the cheat nodes. The advantage of “a large number of nodes + computing power” is tailored for the future public chain. Is that right?