Byzantine fault tolerance in the blockchain

Over the last few decades, the cryptocurrency industry has grown significantly. New projects are constantly appearing, forcing developers to find new ways to solve existing problems in the industry. One fairly common term is the BFT consensus mechanism. BFT stands for Byzantine Fault Tolerance and is considered to be theoretical problem of computer systems, which the creators had to deal with long before the appearance of Bitcoin.

However, many developers of blockchain-based protocols are dealing with problems with Byzantine fault tolerance, so let's look at the nature of the problem and the implications we face when this problem arises.

The problem of Byzantine fault tolerance

Issue Byzantine fault tolerance is one of the most frequently considered theoretical situations when discussing the nuances of consensus. This problem was first recognized as existing in the study "Major Problems of Byzantine Failure" by Leslie Lappport, Robert Szostak and Marshall Pease which appeared in 1982.

The study found:

A reliable computer system must cope with the failure of one or more components. A failed component can behave in a way that is often overlooked, namely sending conflicting information to different parts of the system. The problem of solving this kind of failure is called in abstract "Byzantine Fault Tolerance General Problem".

The name comes from the analogy presented in the study.

More precisely, the authors describe a theoretical situation in which several units of the Byzantine army were stationed outside the enemy city. Each detachment had its commander and each detachment was in a separate camp. The commanders had to devise a plan of joint action (advance or retreat), but could only communicate through messengers. On the other hand, there could be traitors among the generals who could prevent loyal generals from reaching a common denominator (consensus).

Therefore, the generals had to find a way to ensure that:

• all loyal generals follow the same plan of action,
• a small handful of traitors will not be able to prevent the generals from adopting the right plan.

So we are talking about a system that can solve the problem described above and it is called Byzantine Fault Tolerance Solution (BFS). This is where the BFT consensus algorithm comes from. Overall, the Byzantine Fault Tolerance solution prevents system crashes due to unreliable (invalid) participants.

Solving the problem of Byzantine generals

To solve the Byzantine generals problem and make a Byzantine Fault Tolerance Solution (FTS), most generals must use the same strategy. This is achieved in different ways depending on the nature of the system and its purpose. In blockchain, two mechanisms, proof-of-stake and proof-of-work, can also reach a consensus on a Byzantine contingency solution by using different approaches.

Most proof-of-stake blockchains can work when one-third of its existing nodes will fail, giving free rein to the "3f+1" rule, where F i refers to the number of non-working nodes. The formula itself calculates the number of nodes that must be present in the system for it to function properly.

For example, to satisfy the (3f+1) rule, in a system with 4 nodes, three nodes must be fully functional.

How can blockchain solve this problem?

Blockchain-based technology would have several ways to solve the problem of Byzantine generals. The only difference is the consensus algorithm needed and how the BFTS is applied. Different solutions can be found on both the proof-of-work and proof-of-stake side.

Interestingly, Satoshi Nakamoto did not mention the “Byzantine generals problem” in the original bitcoin whitepaper. However, after the launch of the Bitcoin network, the unknown creator of the first cryptocurrency proposed a solution to the aforementioned problem using a "proof-of-work" consensus. Satoshi has created a way to use cryptographic security and public key encryption on a digital network. To prevent any data leakage, cryptographic security uses hashing, and the identity of the network user is verified using a public key.

Transactions are captured in blocks that are linked to the rest at the expense of hashing and are cryptographically protected. It should also be noted that the blockchain uses a Merkle tree to verify hashes coming from the main block. Everyone the block coming from the genesis block is valid. These blocks are verified by miners who solve cryptographic puzzles in a consensus block creation competition.

Bitcoin has established a clear and definitively objective set of rules that the blockchain must follow in order to overcome the Byzantine generals problem. A network participant must publish a proof of work in order to add information to the blockchain (hence Proof of work). This is costly for the participant and discourages them from sharing false information as it will be refuted by other participants in the network.

All rules are clear and objective, meaning that information cannot be changed.

What about proof-of-stake?

Networks ruled by the proof-of-stake consensus algorithm are not based on mining, but on staking. To become a network validator, a user must first deposit funds in the system. Those who hold a larger share can also commit more blocks and receive bigger rewards. Those who try to falsify information risk losing their stake.

Different systems deal with this problem in different ways. For example, Ethereum 2.0 uses the Casper algorithm. It requires that at least two-thirds of the majority of nodes have agreed to a given blockbefore it is created and added to the network.

There are different attempts to solve the problem depending on the need of the system and the approach of the team. For example, with delegated proof of participation (dPoS), consensus is achieved much faster. On the other hand, some systems use Byzantine fault tolerance in practice.