What Is Practical Byzantine Fault Tolerance in Blockchain?

From a blockchain and crypto perspective, Byzantine Fault Tolerance (BFT) is a blockchain consensus mechanism. However, its origins stretch back before the blockchain. Understanding BFT and pBFT requires understanding the Byzantine Generals’ Problem and its application to the blockchain.

The Byzantine Generals’ Problem (BGP) is a thought experiment that was defined by Leslie Lamport, Marshall Pease, and Robert Shostak in 1982. It describes a military scenario where a set of armies led by Byzantine generals are laying siege to a city.

According to BGP, each army is distributed around the city, and the generals must stay with their armies. This means that they can only communicate with one another via messengers.

One of the key goals of the scenario is for the generals to come to an agreement on whether to attack or retreat. To succeed, the armies must all attack or retreat together. Therefore, the generals need to not only come to an agreement but also be aware of what that agreement is.

The scenario is made more complicated by the fact that some of the Byzantine generals may be traitorous. These generals can send manipulated messages to other generals that either misstate their own votes or what they have heard that others have said.

BFT is an algorithm designed to solve the Byzantine Generals' Problem. It ensures that the loyal generals will come to a consensus even in the presence of traitors. The primary assumption of BFT is that a certain percentage of the generals are honest.

BGP is an interesting thought experiment, but it has real-world applications as well. One of the most common uses of BGP and BFT is in blockchain technology.

In a nutshell, the BGP thought experiment describes a situation where a group of mutually distrusting actors needs to reach a shared consensus. In the BGP problem, this is whether to attack or retreat from the besieged city. In the context of blockchain, the BGP perfectly describes the situation that the blockchain network faces when trying to determine the contents of the next block on the blockchain.

One of the big selling points of blockchain technology is that it is trustless. Unlike traditional, centralized systems, there is no single authority responsible for determining and maintaining the “official” version of the distributed ledger. Instead, a network of independent nodes determines the content of the ledger in a decentralized fashion.

In blockchain consensus and similar problems, the main challenge isn’t reaching consensus. This is possible with much simpler algorithms than BFT. Blockchain consensus is challenging because none of the nodes can be trusted.

In the blockchain, each node is assumed to be working in its own self-interest. Blockchain protocols are designed to make good behavior the best and most profitable option for these nodes. A key part of this is a consensus algorithm that is Byzantine fault tolerant, meaning that it is capable of reaching a consensus even though some of the nodes in the network may attempt to lie and cheat to twist the result to their own benefit.

Practical Byzantine Fault Tolerance (pBFT) is a particular type of BFT. It was designed as an optimization to the original algorithm that removes some of the main barriers to using BFT in large networks like blockchains.

The Limitations of BFT

BFT provides a usable solution to the Byzantine Generals' Problem. As long as a certain percentage of the nodes in the network are honest, the blockchain will come to a consensus on the current state of the distributed ledger.

However, BFT’s approach to doing so is inefficient and unscalable. One of the main limitations of BFT is that it relies on direct communications between each pair of nodes in the blockchain network.

This means that, for a network with n nodes, there will be n(n-1) messages to achieve consensus. While this might be workable for small networks, it means that the total number of messages scales with the square of the number of nodes. While a network of 4 nodes needs to send a total of 12 messages to achieve consensus, a network twice its size (8 nodes) would send 56 messages, over four times as many.

At the time of publication, the Bitcoin network had over 17,000 active nodes, meaning that achieving consensus would require over 289 million messages. This would need to be accomplished for each block in the blockchain, making it an unworkable and unscalable solution.

Another issue with direct node-to-node communications is the potential for nodes to be spun up and go down unexpectedly. This happens regularly on the Bitcoin network and other blockchains, making it nearly impossible for nodes in the network to maintain an up-to-date list of the nodes that they would need to communicate with to achieve consensus.

pBFT is an optimization of the BFT algorithm designed to make BFT practical for large networks. One of the main ways that it accomplishes this is by eliminating the communications between every node in the blockchain network.

pBFT increases efficiency by defining an ordering of the nodes in the network with a primary node and backup nodes. The consensus process is broken into a few phases in which the leader proposes a block, and each node in the network validates it and publishes a message stating that they have validated and approved it. Once a certain number of nodes have accomplished this, the block is considered finalized.

Variants of pBFT are used by some blockchain protocols as a consensus algorithm.

Some of the advantages of pBFT for blockchain consensus include:

• Fault Tolerance: pBFT is specifically designed to be a fault-tolerant algorithm, enabling it to deal with node failures. This is important in applications like blockchain consensus where nodes may go down without warning.

  
  

• Transaction Finality: Many blockchain consensus algorithms, such as Proof of Work or Proof of Stake, only have probabilistic finality, meaning that an accepted block may be removed from the distributed ledger after a reorganization. pBFT offers finality, where a transaction approved by a certain number of nodes cannot be reverted.

  
  

• Byzantine Fault Tolerance: pBFT is a Byzantine Fault Tolerant algorithm. This means that it can handle the presence of a certain number of malicious nodes in the network.

In addition to these benefits, pBFT also has its downsides. Some of these include:

• Centralization: pBFT uses a leader node to define the content of the next block on the blockchain and drive the process of getting it approved. This creates a level of centralization that may run counter to the core principles of blockchain.

  
  

• Scalability: pBFT requires messages from a certain percentage of the nodes in the network to finalize a block’s contents. This means that the number of messages scales with the size of the network, which limits its scalability.

• Network Overhead: Network bandwidth usage is a concern for pBFT for the same reason as scalability. The more nodes that need to communicate with one another, the more bandwidth it consumes.

  
  

• Sybil Attacks: pBFT makes decisions based on receiving messages from a certain number of nodes in the network. If an attacker controls many different nodes, they have an outsized vote and may be able to approve malicious blocks.

The scalability concerns of pBFT have led it to be used in conjunction with other blockchain consensus algorithms. For example, a consensus algorithm may combine Delegate Proof of Stake (DPoS) with pBFT so that the pool of nodes that participate in pBFT is limited to the number of delegates elected via DPoS.

pBFT is an effective solution to the BGP, enabling the nodes in the network to achieve consensus even in the presence of malicious nodes. However, its scalability and network bandwidth concerns mean that it is rarely used on its own by blockchains.

Instead, the blockchains that use a variant of BFT like pBFT commonly combine it with another algorithm to cut down on the number of voting nodes. This could be a decentralized consensus algorithm like DPoS or use a centralized authority to choose the delegates in a permissioned blockchain.

Regardless of the mechanism used, it’s vital to ensure that the consensus algorithm is well designed and properly implemented to ensure that it guarantees consensus and can function even in the presence of malicious nodes. 

For help in developing and testing a pBFT-based consensus algorithm for your blockchain protocol, get in touch with Halborn.