The Byzantine generals’ problem
To understand the obstacles associated with achieving consensus on a distributed system we will first examine the Byzantine generals’ problem.
Due to the possibility of the message/reply being intercepted, the possibility of a traitor among generals or the messenger being held hostage or replaced by a spy, the generals can never be 100% confident they reached an actual agreement.
Nodes lie and collude, resulting in malicious attacks and software errors. Therefore consensus is needed to ensure validity. The Byzantine Fault Tolerance Algorithm is used to tolerate possible failures as seen from above. Due to the decentralised nature of blockchains, no central authority exists to restore any destructive actions. Therefore, reactive measures are not an option and thus, the nodes have to act proactively to ensure the transaction is valid.
Practical Byzantine Fault Tolerance (PBFT)
First, nodes pre-prepare, in which a unique sequence # is recognized, also known as a public key. Second, the nodes prepare for consensus by agreeing on this sequence number through digital signatures. Finally, all of the nodes commit, meaning all nodes accept the request and thus consensus is reached and the transaction is valid.
Federated Byzantine Agreement (FBA)
Another class of solutions to the Byzantine Generals Problem, is the Federated Byzantine Agreement. This solution requires each general (validator) to be responsible for their own messages to determine validity of all messages. Cryptocurrencies including Stellar and Ripple use Federated Byzantine Agreement to achieve consensus. However, the two vary slightly. Ripple’s generals (validators) are pre-selected by the Ripple foundation, while Stellar allows anyone to be a validator. Thus, each user on the Stellar network chooses which validators to trust.
There will inevitably be more use-cases of the Federated Byzantine Agreement to achieve consensus. Let us know in the comments below if you find any worth mentioning missing in this post.