When diving into the inner workings of the blockchain, crypto novices might get a little overwhelmed with the terms that get thrown around. Well, the BANKEX team is here to clarify at least one of those terms in this article. Let’s look at what exactly the Byzantine Generals Problem is and how it relates to blockchain.

First, the Story

The Byzantine Generals Problem gets its name from a 1982 paper in which Leslie Lamport and two co-authors described an allegory for the problems of decentralized decision-making. The allegory goes like this: the night before a battle, a group of Byzantine generals in different camps, each with command over a portion of the army, try to decide whether to attack or retreat. Messages between the generals are passed by messengers. However, there is a problem. Some generals and some messengers may be traitors to the cause. Traitorous generals would be interested in sabotaging the plans of loyal generals, and traitorous messengers would be interested in altering the messages entrusted to them by loyal generals. So the loyal generals need to find a way to reach consensus even with the knowledge that betrayal was possible.

What it Means for Blockchain

Obviously, this allegory is intensely relevant to the development of the blockchain environment. It’s easy enough to substitute technical terms for the generals and messengers. The generals, the decision makers, can be replaced by nodes within a decentralized network that may or may not transmit malicious information, sometimes purposely to interfere with the network. The messengers can be replaced by the connections between the nodes, connections that may be faulty, leading to the signal being corrupted or being lost entirely.

So, How do We Fix It?

One of the first methods suggested to deal with this issue came about in 1999 in a paper written by Miguel Castro and Barbara Liskov. They proposed the Practical Byzantine Fault Tolerance protocol — pBFT for short. This protocol was designed to handle both unstable connections and malicious data transmission. It works by creating a leader, i.e. a primary node, as well as backup nodes. A client sends a request to the primary node that an operation be undertaken, and this request is then sent to the backup nodes, who then send a reply to the client. The node that is considered the leader is changed regularly. When the amount of concurring replies from separate nodes exceed the maximum number of nodes that could be faulty, then the operation is undertaken. However, this solution assumes that the majority of nodes are honest.

Not Perfect, but Getting There

Eagle-eyed readers may see that there is an issue here. Namely, that a malicious user could generate fake nodes to overwhelm real nodes so the user’s malicious data would seem to be agreed on by the majority of nodes. This manipulation of data is another real problem, to such a degree that it was even given a name: a Sybil attack. The pBFT was a step in the right direction, but it was not the final system that ended up implemented in early blockchain solutions. The further development of this sort of protection protocol would take a few more years. But that’s a whole different problem for a different article.

So stay tuned to BANKEX to learn more about blockchain. Follow us on social media and be the first in your group of friends to finally say, “You know, I actually do get blockchain!”