Byzantine Generals’ Problem

This allegory has become very common in the blockchain industry and is an extension of the standard “General’s Problem”. The goal is to figure out a way for a network to reach consensus even with malicious actors involved.

The General’s Problem lays focus on two generals that are fighting for the same cause. Each general commands his own army and the armies are attempting to lay siege on a castle. The only way this siege will be successful is if both generals agree to attack on the same day at the same time. The catch? The generals and their respective armies are separated by several miles and the generals can only communicate through the service of messengers. If one general sends a messenger to the second with battle plans, he has no way of ensuring the message was received. In contrast, if the second general does receive the battle plans and sends a messenger with confirmation of said plans, he could never know if that messenger made it back to the first general. This creates an endless loop of messengers and constant doubt between the generals. Not a very efficient way to attack a castle.

The Byzantine General’s Problem expands on this, but with the introduction of multiple lieutenants and an overseeing commander. Imagine a similar situation as before, a fleet of three lieutenants fighting for the same cause are surrounding an enemy castle and plan to lay siege on the castle. The commander can only send battle plans by messenger, and the lieutenants can also only communicate through messengers. There is a commander that provides the battle plans and all messages are unforgeable. The commander sends battle plans for every lieutenant to attack the castle in the morning.

The problem, if one of the lieutenants is a traitor, he can tell another lieutenant that the commander messaged him saying the plan is to retreat. However, since the other two lieutenants have received the plans to attack, a consensus in the network of 2 / 3 has been reached and the attack will be successful despite having a traitor in the mix.

Now, take this up another notch and assume that there is three possible battle plans. Plan 1: attack the next morning. Plan 2: attack the next evening. Plan 3: retreat. This more complex problem revolves around the idea that the COMMANDER is the traitor and for whatever reasons, wants the lieutenants to fail. Now, the commander sends Plan 1 to a lieutenant, Plan 2 to another lieutenant, and Plan 3 to the final lieutenant. How can this network reach a consensus when all lieutenants have been given separate battle plans?

Well, each lieutenant receives his battle plan and sends messengers to the other lieutenants to confirm said plan. By the end of this process the lieutenants have each other’s battle plans. Each lieutenant knows that there has been plans sent to attack in the morning, attack in the evening and retreat. Since each lieutenant has now realized that there has been treacherous information sent by the commander, they are able reach a 3 / 3 consensus to retreat. Reason being, they could not responsibly attack the castle knowing their commander is sending flawed battle plans to the other lieutenants.

These general problems lead to the concept of a Byzantine Fault Tolerance. The Byzantine Fault Tolerance is a way for blockchains to operate and validate blocks of data even with a treacherous or malicious actor involved.