View source for Byzantine fault tolerance

{{#seo:
                     |title= Byzantine Fault Tolerance (BFT) — Decimal Wiki
                     |titlemode= append 
                     |keywords= Byzantine Fault Tolerance (BFT)
                     |description= Byzantine Fault Tolerance (BFT)
                    }}
[[File:Art Problem of Byzantine generals.jpg|400px|right|thumb]]
'''Byzantine fault tolerance''' is a property of a system capable of resisting a class of failures arising from the «problems of Byzantine generals». Having «Byzantine fault tolerance», the system can continue to work even if some of the nodes do not function or act maliciously.
 
The participants of the [[cryptocurrency]] [[network]] need to regularly coordinate the current state of the [[blockchain]]: this is what we call achieving [[consensus]], but what if some of the [[node]]s act dishonestly? This is a fundamental question about the so-called «problem of Byzantine generals», which gave rise to the concept of «Byzantine tolerance» (BFT).

== History ==
[[File:Wiki Problem of Byzantine generals.png|600px|right|thumb|The Problem of Byzantine generals]]
The «Byzantine Generals Problem» was coined in 1982 as a logical dilemma that illustrates how a group of more than two people at a great distance from each other can have communication problems when trying to agree on the next step.
 
The dilemma assumes that each general has his own army and each group is in different places around the city, intending to attack it. The generals need to agree either to attack or to retreat. The main problem is that messages can somehow be delayed, lost or destroyed. In addition, even if the information is successfully delivered, one or more generals may act (for whatever reason) maliciously and send a fraudulent message to confuse others, which will lead to a general failure.

== «The task of the Byzantine generals» (original wording) ==
Byzantium. The night before the great battle with the enemy. The Byzantine army consists of N legions, each of which is commanded by its own general. The army also has a commander-in-chief, to whom the generals report.
 
At the same time, the empire is in decline, and any of the generals and even the commander-in-chief may be traitors to Byzantium, interested in its defeat.
 
At night, each of the generals receives an order from the commander-in-chief, what to do at 10 o’clock in the morning (the time is the same for everyone and is known in advance). Variants of the order are «attack the enemy» or «retreat».
 
'''Possible outcomes of the battle:'''
# If all the loyal generals attack, Byzantium will destroy the enemy (a favorable outcome).
# If all the loyal generals retreat, Byzantium will retain its army (intermediate outcome).
# If some loyal generals attack and some retreat, the enemy will eventually destroy the entire Byzantine army in parts (an unfavorable outcome).
 
It should also be borne in mind that if the commander—in-chief is a traitor, then he can give different generals opposing orders to ensure the destruction of the army. Therefore, the generals need to take into account this possibility and prevent uncoordinated actions.
 
If each general acts completely independently of the others (for example, makes a random choice), then the probability of a favorable outcome is very low.
 
Therefore, the generals need to exchange information among themselves in order to come to a common decision.

== Application in blockchain ==
In the context of blockchain, generals are network [[node]]s, and they need to reach [[consensus]] on the current state of the system. In other words, the majority of participants in a distributed network must agree and perform the same action in order to avoid a complete failure. Therefore, the only way to achieve consensus in these types of distributed system is to have (at least ⅔ or more) reliable and honest network nodes. This means that if a large part of the network decides to act maliciously, then the system is prone to error (for example, a 51 % attack).

== Conclusions ==
If there is no «Byzantine fault tolerance» in the network, then a [[peer]] can independently create and confirm false [[transaction]]s, thereby discrediting the entire system. Since there is no regulatory body in the blockchain that could take responsibility to confirm or cancel certain actions to correct or prevent damage, [[decentralization]] would play a negative role.
 
The «Byzantine Generals problem» is a dilemma that gave rise to BPT systems, and now they are widely used in various systems. In addition to the blockchain industry, these are the aviation and space spheres, as well as nuclear energy.
 
«Byzantine fault tolerance» is being studied by many cryptocurrency startups — [[algorithm]]s are being upgraded and successfully integrated into their own distributed systems.
 
[[Decimal]], [[Hyperledger]], [[Cosmos Network]], [[Minter]], [[Zilliqa]] — all these and not only projects use «Byzantine fault tolerance» as the main component of their infrastructure.
 
Effective communication of network nodes and a good consensus mechanism are vital for any blockchain [[ecosystem]]. Existing [[consensus algorithm]]s have yet to overcome several barriers (e.g. scalability). Nevertheless, [[PoW]] and [[PoS]] are very interesting and working approaches to BFT.

== See also ==
* [[Consensus algorithm]]
 
[[Category:Commoninfo]]
[[Category:Crypto security]]