Byzantine Fault Tolerance in Blockchain: A Closer Look

The field of cryptocurrencies has expanded tremendously in the last couple of years. The emergence of new projects also presents different ways developers tackle existing problems in the field.

A term that gets thrown 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 associated with Byzantine fault tolerance, and the following takes a closer look at the matter and all that stems from it.

The Byzantine general problem explained

The Byzantine general problem is one of the most discussed theoretical situations when the topic of consensus is raised.

The problem was first recognized in a 1982 paper called The Byzantine general problem by Leslie Lamport, Robert Shostak and Marshall Pease. The newspaper reads:

A reliable computer system must be able to cope with failure of one or more of its components. A failed component can exhibit a type of behavior that is often overlooked—namely, sending conflicting information to different parts of the system. The problem of dealing with this type of error is expressed abstractly as the Byzantine generalization 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 encamped outside an enemy city. Each division is commanded by its own general, who all sit in different camps. The commanders must come up with a joint plan of action (whether to attack or retreat), and they can only communicate by 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 on the same plan of action.
• A small number of traitors cannot make the loyal generals adopt a bad plan.

A system capable of solving the above is considered to have Byzantine fault tolerance (BFT). This is where the BFT consensus algorithm originates.

Essentially, Byzantine fault tolerance is a condition that prevents the system from suffering from unreliable (disloyal) participants.

Solving the Byzantine general’s problem

To solve the Byzantine general problem and achieve Byzantine fault tolerance (BFT), there must be a majority agreement among the generals on their strategy.

This is achieved in different ways depending on the system and its needs. In the blockchain context, 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 defective, allowing room for 3f+1 rule where F is the number of disloyal nodes, and the formula gives the number of loyal nodes the system must 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 an article presenting a solution to the problem through the so-called Practical Byzantine fault tolerance.

How Does Blockchain Solve the Byzantine General Problem?

Blockchain-based technology presents several solutions to the Byzantine general 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 general problem?

Interestingly, in the original white paper, Satoshi Nakamoto did not mention the Byzantine General 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 linked to other blocks by their hash value and secured with cryptography. It is important to note that the blockchain uses a Merkle tree to verify the hash that comes from the genesis 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 in order to overcome the byzantine generalization problem. A network member must publish proof that they have completed work in order to add information to the blockchain (hence proof of work). This has a high cost to the member and makes it a disincentive for them to share misinformation, as it will be refuted by the other state members.

All rules are clear and objective, which means that the information cannot be tampered with.

How does Proof-of-Stake solve the Byzantine general problem?

Networks governed by the proof-of-stake consensus algorithm do not rely on mining – they rely on stakes. To become a network validator, the user must first deposit money into the system. Those who own a larger stake can also validate more blocks and earn larger rewards. Those who attempt to tamper with the information risk losing their stake.

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

There are different attempts to solve the problem based on the necessity of the system and the approach of the team. For example, with Delegated Proof of Stake (dPoS), reaching consensus is significantly faster. On the other hand, some systems implement the practical Byzantine fault tolerance.