Byzantine Fault Tolerance in Blockchain: A Closer Look

The field of cryptocurrencies has expanded tremendously over the past couple of years. The rise of new projects also presents various ways developers are tackling existing problems in the field.

One term that is tossed around quite often is the “BFT consensus mechanism.” BFT stands for Byzantine Fault Tolerance, and it presents a theoretical problem in computer systems that existed long before Bitcoin.

However, many blockchain-based protocols are engaged in solving the problems that are associated with Byzantine fault tolerance, and the following takes a closer look into the matter and all that derives from it.

The Byzantine Generals Problem Explained

The Byzantine Generals Problem is one of the most heavily discussed theoretical situations whenever the topic of consensus is brought up.

The problem was first acknowledged in a paper from 1982 called The Byzantine Generals Problem by Leslie Lamport, Robert Shostak, and Marshall Pease. The paper reads:

A reliable computer system must be able to cope with the failure of one or more of its components. A failed component may exhibit a type of behavior that is often overlooked – namely, sending conflicting information to different parts of the system. The problem of coping with this type of failure is expressed abstractly as the Byzantine Generals Problem.

The name is derived from the analogy presented in the paper. More specifically, the authors describe a theoretical situation where several divisions of the Byzantine army are camped outside of an enemy city. Each division is commanded by its own general, all of which sit in different encampments. The commanders need to come up with a common plan of action (whether to attack or retreat), and they can only communicate with messages. However, some of the generals may be traitors and try to prevent the loyal generals from reaching an agreement (consensus).

Therefore, the generals must find a way to guarantee that:

• All loyal generals decide upon the same plan of action.
• A small number of traitors can’t cause the loyal generals to adopt a bad plan.

A system that’s able to solve the above is deemed to have Byzantine fault tolerance (BFT). This is where the BFT consensus algorithm stems from.

In essence, Byzantine Fault Tolerance is a condition that prevents the system to suffer from unreliable (unloyal) participants.

Resolving the Byzantine General’s Problem

To solve the Byzantine Generals Problem and achieve Byzantine Fault Tolerance (BFT), there must be a majority agreement among the generals on their strategy.

This is achieved in various ways depending on the system and its necessities. In the context of blockchain, both proof-of-work and proof-of-stake are capable of achieving Byzantine fault tolerance, but the approach in both is different.

Most proof-of-stake blockchains can tolerate up to one-third of their nodes being faulty, giving leeway to the 3f+1 rule where F is the number of unloyal nodes, and the formula gives the number of loyal nodes the system needs to have.

For example, in a system with 4 nodes, only one of them can be faulty to fit the criteria (3f+1).

In February 1999, Miguel Castro and Barbara Liskov from the Laboratory for Computer Science at the Massachusetts Institute of Technology (MIT), published a paper presenting a solution to the problem through the so-called Practical Byzantine Fault Tolerance.

How Does Blockchain Solve the Byzantine Generals Problem?

Blockchain-based technology presents multiple solutions to the Byzantine Generals Problem. The differences stem from the designated consensus algorithm and their approach to BFT, but both Proof-of-Work and Proof-of-Stake provide viable solutions.

How Does Bitcoin Solve the Byzantine Generals Problem?

Interestingly enough, in the original whitepaper, Satoshi Nakamoto didn’t mention the Byzantine Generals Problem, but with the introduction of the Bitcoin Network, the pseudonymous creator essentially solved it through the Proof-of-Work (PoW) consensus algorithm.

To solve the problem, Satoshi created a way to use cryptographic security as well as public-key encryption in a digital network. To prevent any tampering with the data, the cryptographic security uses hashing, while the identity of a network user is verified through their public key.

Transactions are secured in blocks, which are connected to other blocks by their hash value and secured by cryptography. It’s important to note that the blockchain uses a Merkle Tree to verify the hashes that come from the genesis (initial) block. Every block that comes from the genesis block is valid. These blocks are validated by miners who solve cryptographic puzzles in a competition to produce blocks as part of the consensus method.

Bitcoin has established a clear and definitively objective rulebook for the blockchain to follow to overcome the Byzantine Generals Problem. A network member must publish proof that they completed the work in order to be able to add information to the blockchain (hence, proof of work). This comes at a high cost for the member and makes it disincentivizing for them to share faulty information as it will be refuted by the other state members.

All rules are clear and objective, meaning there can’t be tampering with the information.

How Does Proof-of-Stake Solve the Byzantine Generals Problem?

Networks governed by the proof-of-stake consensus algorithm don’t rely on mining – they rely on staking. To become a network validator, the user must first stake funds in the system. Those who own a greater share can also validate more blocks and earn greater rewards. Those who attempt to tamper with the information are at risk of losing their staked amount.

The way these systems solve the problem varies. For instance, Ethereum 2.0 employs the Casper algorithm. It needs a minimum of a two-thirds majority of all nodes to agree on a specific block before it can be created and added to the network.

There are variable attempts at solving the problem based on the necessity of the system and the approach of the team. For instance, with Delegated Proof of Stake (dPoS), reaching a consensus is significantly quicker. On the other hand, some systems implement the practical Byzantine fault tolerance.