In the previous article, we provided an introduction to the process by which PBFT works. But now, how do we know whether it is really efficient (and effective)? The two main concepts that shall be studied in order to answer this question are safety and liveness. How does PBFT ensure that both safety and liveness are continuously granted? And how does PBFT implement this differently from classic blockchain protocols?
Ensuring safety implies ensuring that each replica performs the same actions in the same order.
Safety is related to the security threshold. If the total number of Generals is 3f+1, then up to f traitors can be tolerated, so all the protocol steps must obtain a 2f+1 threshold of consent in order to be executed. This is to ensure that if the same sequence number is assigned to two different actions, at least one honest general will reject it.
The three-phase is critical to the protocol’s safety. Why not two-phase only but three-phase? Imagine a situation with two-phase voting. Suppose General 2 directly performs the action “attack” (sequence number 6) after collecting the prepared proof, but General 3 and General 4 initiate the view change due to delay, so General 2 was also forced to change. Since General 3 and General 4 did not receive the action labelled with sequence number 6, the content of sequence number 6 would not be re-executed, and the new leader would assign sequence number 6 to the next action. This would result in General 2 executing again the same sequence number 6, thus violating safety. Therefore, the third phase, i.e. the commit phase, is necessary in order for General 2 to ensure that General 3 and General 4 have collected the prepared certificate of sequence number 6 and returned the “commit” message, and therefore execute the content of sequence number 6. This way, even if a view change occurs, sequence number 6 is no longer repeatedly assigned to different content, and the safety of the protocol is thus guaranteed.
Liveness implies ensuring that the protocol will always eventually proceed. This is granted by the view change action. To overcome the limitations described by the FLP impossibility, PBFT uses the Weak Synchrony assumption, which assumes that the network latency grows slower than the buffer time for each timeout (i.e. the delay T cannot grow indefinitely higher than time). If timeouts occur during the view change process, the Generals simply initiate another view change and extend the wait time from T to 2T/3T/4T… and so on, until the set timer is able to tolerate the communication delay. This implies that the protocol will eventually proceed, even under the worst case scenario, by which a consecutive number of malicious leaders is elected in series.
PBFT is a permissioned, leader-based, communication-based, safety-focused consensus protocol, which is largely different from blockchain. Let’s take a closer look at each of them:
Permissioned: PBFT is not really fit for use in public environments. This is because PBFT needs to enable nodes to verify each other’s messages and the number of nodes active at each moment in time shall always be known. Blockchain is, on the other hand, a permission-less system, i.e. open to anyone. The PBFT-based Proof-of-Stake model allows participants to register in the network with their own assets. This also grants that all nodes are always known at each moment in time.
Leader-based: For each client’s request, the leader is endorsed with the responsibility of sending the proposal to the other replicas. The most direct benefit of this mechanism is that no computing resources are wasted by nodes to win the opportunity to become leaders. However, the disadvantage of this method is that only leaders are replaced only when view changes are triggered by the network. The opportunity to become a leader is therefore unfair and lacks few incentives to join the network are generated. Blockchain elects leaders based on the difficulty of the work performed, which generates incentives, although it wastes computing power. Recent research has shown that leaders may be determined through fair random number, which would ensure that the opportunity to be a leader is fair and save computing resources. However, how to ensure that the random number generator is fair? This is the next big problem that will have to be discussed.
Communication-based: PBFT’s security is based on 3-phase voting. Although it doesn’t consume a lot of computing resources as proof of work does, the huge amount of communication also inevitably creates a bottleneck for scalability: it is, in PBFT, impossible to expand to more than 1000 nodes. Furthermore, PBFT uses message authentication code (MAC) message format, which requires each node to verify a message for each round of voting. It is easy to see that the large number of signatures/verifications cause another potential bottleneck. A further possible problem is that the communication model is >subjective. There is therefore no direct protection toward long-range attacks. In contrast, traditional blockchain is computation-based, therefore its safety is based on a verifiable proof. However inferior in communication efficiency in practice, this model is indeed objective: new nodes follow Nakamoto Consensus by always selecting the most difficult chain.
Safety-focused: Safety is more important than the liveness (Safety over Liveness principle). PBFT, whether synchronous or asynchronous, can ensure the safety assumption, which states that a fork is almost impossible, and instant finality is granted. In contrast, blockchain is more focused on liveness than safety, and its safety depends on a synchronous network. Forks happen quite frequently (multiple consensus) and for a block to be safe its chain shall be longer than a certain number of blocks.
Can I issue a cryptocurrency on PBFT?
Due to the above properties of PBFT: permissioned, lack of participation incentives, lack of resistance to long-range attacks, and excessive communication costs, we are unable to establish a fully decentralized and practical cryptocurrency on PBFT. However, PBFT can be used as a consensus model for proof-of-stake, which can be applied to permission-less context and can provide economic incentives. As an example, Ethereum Casper is a hybrid model based on computational and communication-based models that determined by Proof of Work leaders. A single round of voting is then carried out by the depositor (Validator) to finalize the consensus. Although there are many problems at present, it is very worth keeping a close look into it.
Despite the booming blockchain, PBFT has witnessed a huge amount of research around it during the latest years, and its subsequent development has spawned many novel protocols and ideas, such as Tendermint / HotStuff / Harmony FBFT/ and our soon to be revealed UnityBFT. Taking a look back into PBFT before jumping into these new protocols will surely open the doors to a full understanding of them.