Byzantine Fault Tolerance

Gepubliceerd op 9 oktober 2022 om 11:03

In the Byzantine Empire, there were people who took charge, for example, the army or trade. These people who were in charge of these departments had to make certain decisions. The army had to think of tactics and the person for trade had to think of how to sell the most products. As the Byzantine Empire grew larger, it became more and more difficult to make decisions. After all, you didn't have a landline or WhatsApp that you could use to contact each other. The army on one side of the country could not communicate with the other part of the army on the other side of the country easily. The same can be applied with ships. Ships could not communicate with each other. So a solution had to be found to this problem. The solution is the Byzantine Fault Tolerance (BFT).

The Byzantine Fault Tolerance

In short, the BFT is a way of creating order and being able to exercise control when there are multiple people or systems involved in a specific choice. In the Byzantine Empire, there were many different people involved in different places in the empire. The army was stationed in different places and ships were not in the same port. Each army and each boat had its own boss. That boss made all the decisions.

If one army decided to attack an enemy, the other armies had to know about it. Or if one ship wanted to attack another ship then the other ships had to know that too. These decisions were made by generals of that army or ship (admiral).

The generals did not just decide whether to attack or not. They also had to decide how far and how long to march and how much food to take along for the men. I think you can imagine that consultation between generals is very difficult, especially when it comes to a large army. So a solution had to be devised where the generals could make decisions more easily.

The solution is simple: if a decision had to be made (who to attack, where and with how many troops, etc.) then the option was chosen where more than 50% of the generals would agree. If the 50% limit would be reached, then that is the decision. No further discussion takes place.

This method is very efficient and can be taken quickly. No long discussions were needed. This allowed decisions to be made quickly. With many enemies lurking around, this was a good way to make decisions.

Each general represents a network node, and the nodes need to reach consensus on the current state of the system. Putting in another way, the majority of participants within a distributed network have to agree and execute the same action in order to avoid complete failure.

Therefore, the only way to achieve consensus in these types of distributed system is by having at least ⅔ or more reliable and honest network nodes. This means that if the majority of the network decides to act maliciously, the system is susceptible to failures and attacks (such as the 51% attack).

The Byzantine Fault Tolerance and the blockchain

A blockchain network has the same problem as the generals in the Byzantine Empire had. Namely, the blockchain consists of thousands of nodes (the participants in the network) all doing their jobs for the network (just like the generals in the Byzantine Empire). One of the jobs of nodes is adding transactions to the blockchain and keeping track of the transactions.

If a miner (that is, a node in the network) wants to add a block to the blockchain and solve a puzzle (at the Proof of Work consensus mechanism), then the solution to this puzzle must be approved by the network. So this miner sends the solution to all the nodes and the nodes check if puzzle outcome is valid. If 51% of the nodes approve the block (they approve the solution of the hashing puzzle), the miner who had solved this solution the fastest gets to add it to the blockchain. Conversely, if 51% of the nodes do not approve it, then this transaction (in the form of a block) is not added to the blockchain.

The BFT need not be used only for adding blocks to the blockchain. The BFT can also be applied in the Proof of Stake (PoS) consensus protocol. In the PoS, participants (i.e., nodes) must deploy their crypto (tasks) before they can join the blockchain network. It is a kind of deposit. If the nodes do not do their job properly, they can lose their deposit (or stake). For example, think of approving illegal transactions.

Other participants in the network decide when a node is not doing its job properly. If 51% or more of the network decide that a node has not done its job properly, then this node can lose its stake. Then this node is removed from the network and this node can never participate in the blockchain again.

In a few words, Byzantine fault tolerance (BFT) is the property of a system that is able to resist the class of failures derived from the Byzantine Generals’ Problem. This means that a BFT system is able to continue operating even if some of the nodes fail or act maliciously.

There is more than one possible solution to the Byzantine Generals’ Problem and, therefore, multiple ways of building a BFT system. Likewise, there are different approaches for a blockchain to achieve Byzantine fault tolerance and this leads us to the so-called consensus algorithms.

The 51% attack

The BFT has vulnerabilities that should make blockchain to provide additional security. After all, the BFT cannot be abused.

A well-known vulnerability of the BFT is the 51% attack. 51% of the network must agree to a certain decision. In this case, for example, checking a block. But what if one node owns 51% of the network, or if a few nodes work together and own 51% of the network? In this situation we speak of a 51% attack.

If a node or several nodes own most of the network, then their own transactions can always be approved. In fact, they can ensure that the network always represents 51% of the network and the transaction is always approved. Transactions that have to do with money laundering or terrorist financing can also be approved.

A node (or nodes) can then send all crypto sent through the blockchain network to its own wallet.

The nodes that perform a 51% attack obtain no any financial benefits. A 51% is usually often noticed quickly because this attack causes the crypto price to fluctuate violently and often collapse. Often the network is so fast that the hackers do not get the opportunity to convert this crypto to fiat money.

Blockchains today have implemented such security measures that such attacks can hardly occur, if at all. The bitcoin and Ethereum blockchain is so secure that a 51% will not be able to occur there. So you often don't have to worry about this kind of attack. With the lesser-known crypto projects, you do need to pay close attention. The risk with lesser-known crypto projects is bigger.

Consensus mechanism vs BFT

Is the BFT the same as a consensus mechanism? No! These two things must be distinguished from each other. They look similar, but are completely different in technique. The BFT can be applied even if the blockchain has no consensus mechanism (however, this never happens). The BFT is a process where choices can be made through the 51% principle. In principle, a consensus mechanism is totally unrelated to this. Even if there is no consensus mechanism, the 51% principle can be used. The consensus mechanism is an algorithm where a transaction can be placed on the blockchain by a node. Before a miner can do that, however, that node must first have the solution to the hashing puzzle verified by the network. If 51% of the nodes approve this, then the node is allowed to add this transaction to the blockchain. The 51% can be a part of the consensus mechanism, but it is not the same as a consensus mechanism.

Benefits of PBFT
Following are the advantages of the pBFT consensus algorithm:

  • A pBFT doesn’t require carrying out high mathematical computations like PoW.
    It is an energy-efficient consensus model.
  • A block of transactions here does not need to follow multiple confirmations by each node. Hence, it requires less time.
  • As pBFT requires every node to participate and serves the client request, each node gets the reward. Hence low reward variance between each node.

Limitations of PBFT

  • Following are the disadvantages of the pBFT consensus algorithm:
  • pBFT has a high communication overhead that will increase with the number of nodes in the network.
    It has scalability issues with more extensive networks.

In more detail

The Byzantine fault tolerance (BFT) is a concept in distributed systems that refers to the ability of a system to function correctly even when some of its components fail or behave in an unpredictable manner. In the context of blockchain technology, BFT refers to the ability of a blockchain to maintain its integrity and consistency even when some of its nodes (computers that participate in the network) are behaving maliciously or experiencing failures.

In a BFT blockchain, nodes can reach consensus on the state of the blockchain even if some of them are behaving dishonestly or experiencing failures. This is achieved through the use of advanced consensus algorithms and cryptographic techniques that allow the honest nodes to reach agreement on the state of the blockchain despite the presence of faulty nodes.

One of the main benefits of BFT blockchains is that they can achieve high levels of security and reliability even when a significant portion of the nodes in the network are behaving maliciously or experiencing failures. This makes them well-suited for applications that require a high level of security, such as financial systems or critical infrastructure.

There are several different BFT consensus algorithms that have been developed for use in blockchain technology, including PBFT (Practical Byzantine Fault Tolerance), Tendermint, and Casper. Each of these algorithms has its own unique features and trade-offs, and they are used in various blockchain projects depending on the specific requirements of the application.

Overall, BFT is an important concept in the field of distributed systems and is widely used in blockchain technology to ensure the integrity and reliability of the network.

Reactie plaatsen


Er zijn geen reacties geplaatst.