Fallacies of BFT in Blockchain
Byzantine Fault Tolerance (BFT) is the foundational theory enabling most any blockchain system to validate transactions in a decentralized network. Consensus algorithms strive to implement BFT. Unfortunately, the allegory of the Byzantine Generals Problem, as adopted by the blockchain community, suffers from some logical fallacy in actually providing nonrepudiation in decentralized networks.
The problem is that BFT does not result in as strong a consensus model, regardless of which consensus model, that we have been led to believe.
Let’s start with what the Byzantine Generals Problem is. Suppose that in an Army there are several generals, each leading their own attack force against a fortress. The generals must either all attack at the same time or not attack at all. The question is; how do the generals successfully communicate among themselves as to attack or retreat AND keeping in mind that some of the communications or even the intentions of the generals may have been compromised or may otherwise be erroneous?
In a very simplified manner, if each general were to receive a majority of messages from each other general stating to attack then the attack would commence. Conversely, if a minority of generals or their messages were compromised then the attack may still commence. This method of arriving at a consensus on what the “truth” is defines what Byzantine Fault Tolerance (BFT) is all about.
With blockchain, the same applies. “Truth” is based on what the majority believes to be true. More specifically, if at least 51% of nodes agree upon a given truth then that truth becomes the consensus. Unfortunately, if 51% of the nodes are behaving badly then their truth will become the consensus.
So, BFT is not so much about truth as it is about the rule of the majority. Sometimes the majority is well behaved. Sometimes not. Sometimes the majority is represented as a count (like of people) of the total population. Sometimes the majority is represented as an amount of power (like weapons or computer hashing strength).
The generals from our story are waging a battle within a finite theater of war. There are a fixed set of generals, a fixed objective (the fortress) and fixed communication channels. The integrity of the generals and their communication methods represent uncertainties with trust. The generals devise a system to determine whether to attack or retreat based on a consensus of those messages. Their system allows for a consensus to be arrived at even with those aforementioned uncertainties.
To make the challenge faced by the Byzantine Generals a little more realistic to what we try to accomplish with blockchain let’s add what I call, “the hand of god.” The hand of god can be viewed as an external force outside of the expected and “encapsulated” theater of war. The hand of god can wreak havoc that was otherwise unexpected.
The hand of god may bring about a storm that washes everyone away. The hand of god may introduce multiple additional fortresses instead of one fortress. The hand of god may increase the quantity of generals. The hand of god may mess with the generals’ minds.
The point is to identify whether the theatre of war is truly fixed or infinite.
The connection back to blockchain is this: Blockchain relies upon BFT as its method of arriving at “the truth”. A majority of nodes must agree upon what that truth is. That method of agreement leverages consensus methods such as Proof of Work, Proof of Stake, etc. However, the hand of god can affect the reliability of those consensus methods. Blockchain, it turns out, is not sacrosanct.
The hand of god in the blockchain theater of war would be external forces that can act outside of the expected attack vectors. The most commonly discussed attack vector is a 51% attack where a majority of nodes decide upon a different version of the truth. But, a 51% attack, as the most significant threat facing blockchain makes far too many assumptions about the theater of war that blockchain exists within.
BFT, in my view, does have practical applicability within closed systems that avoid hand of god manipulations. Some may consider sensor networks as one such application.
Additionally, within a closed environment, BFT can be very useful for mitigating the effect of faults. BFT, after all, is a fault tolerance method and not a security architecture.
However, when we look at BFT within the context of an open environment, like public blockchain, then a multitude of attack vectors emerge. These attack vectors are expressed through the entire blockchain stack from the physical network to the application layer.
Interestingly, the primary vulnerability is the reliance upon decentralization. I recognize that it is a bit paradoxical to state that decentralization is the primary risk factor when decentralization is called out as the solution to increasing security of a transactional data set.
Decentralization versus centralization is out of scope for this essay. However, we still need to explore attack vectors across an open blockchain network.
Let’s start with the software that nodes run. Blockchain node software does not magically exist. Rather it was created by a community of programmers. They act upon an agreed upon charter to improve the node software. Most often they act with good intent. But, they have the ability to alter the theater of war by introducing functions that may work in unexpected ways. BFT does not work well in a dynamic theater of war.
And speaking of the community of programmers, with every public blockchain there are folks that provide programming, but there are also folks that provide governance. Often, the folks who provide governance and programming are the same. Regardless, the point here is governance. Every decentralized network has some form of centralized governance albeit typically manifested as “shadow governance”. The risk factor here is that these folks could put in place policies or requests for feature adds/changes that can have an effect beyond what was intended. Or policies could be put in place that are contrary to what the larger community might desire. Again, the theater of war becomes dynamic in scope.
The analogy to the Byzantine Generals would be that the hand of god could manipulate how the generals think and act.
The network is another attack vector that puts blockchain at risk. China has their Great Firewall. China, unfortunately, is not an isolated country for censorship and Internet access controls. Other countries include Russia, Saudi Arabia, as well as many others. This may be surprising, but the United States is not immune from Internet censorship. The point here is that blockchain networks can be blocked. Some might argue that as long as one node is running then the blockchain network survives. This is false. Of course, one may adopt a somewhat loose definition of survival. However, if practical access and use of a system is a requirement for viability then blockchain networks are subject to censure and restriction just the same as most any other site on the Internet.
And again, with the Byzantine Generals, how would they deal with a circumstance where communication were simply no longer possible?
Other attack vectors outside of the defined theater of war include collusion of hardware systems, latency outpacing functionality, exchange manipulation, wallet compromises, etc.
BFT as the underpinning for public blockchain, unfortunately, does not provide the level of trust for broad adoption. BFT does not provide for universal and immutable truth as is claimed by the blockchain community. Arguments that Bitcoin is proof of the benefit of BFT are false. The proof of the failure of BFT in blockchain is with the multitude of Bitcoin forks, each with their own truth. The argument of “my blockchain is the truth and the other blockchains are not the real truth” should be very telling.
In a subsequent article, I will explore some ideas as to how a blockchain system could provide for an increased level of trust without BFT.