Byzantine Fault Tolerance (BFT)

This page gives some more detail on what Byzantine Fault Tolerance is.

What is Byzantine Fault Tolerance?

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.

BFT And The Byzantine Generals' Problem

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.

Byzantine Generals And Blockchain

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

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.

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.