Understanding Hyperledger Fabric — Byzantine Fault Tolerance
The architecture of Hyperledger Fabric factors out consensus into its own component — the orderer service. This is an unusual feature because it means Fabric can support different consensus algorithms by just switching out the orderer implementation. Not every blockchain platform supports this.
For example, Bitcoin’s consensus algorithm is baked in. It makes sense for Bitcoin to only support its proof-of-work system. Bitcoin expects to be a massive untrusted network, and its consensus algorithm works great for that scenario. On the other hand, Hyperledger Fabric is a generic platform — meant to be applied in a wide variety of environments. There isn’t a one-size-fits-all consensus algorithm, so Fabric is designed to let users choose.
What is Consensus?
Consensus means all parties agree on a particular decision. In the case of a blockchain network, members of the network arrive at a consensus on the contents of the blockchain. It’s telling that consensus is part of the ordering step of Fabric’s execute-order-validate architecture. The orderer determines which transactions to add to the blockchain and in what order. All members of the network rely on what the orderer says.
In a distributed system, there’s a variety of threats that a consensus algorithm must be resilient against. Processes can crash. Machines and devices can fail. Network connections can be interrupted. Furthermore, since components of the system may be controlled by different organizations with different goals, they may act maliciously as well. Crash fault tolerance (CFT) is one level of resiliency, where the system can still correctly reach consensus if components fail. Byzantine fault tolerance (BFT) is more complex and deals with systems that may have malicious actors.
The Byzantine Generals Problem
The name Byzantine fault tolerance is derived from a 1982 paper called The Byzantine Generals Problem. (excerpt below)
We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action.
This analogy fits distributed computation because individual machines (generals) are connected only via the network (messengers). Each is only aware of what it observes and the messages it receives. Likewise, every component is a possible source of failure or malicious activity.
- Networks can fail — messengers can be captured or killed.
- Man-in-the-middle attacks can send forged messages — messengers can be compromised.
- Hardware or software components can break or crash — generals can be killed.
- Malicious components can send malicious messages — generals can be traitorous.
The analogy also fits the topic of consensus because the generals must act together. The army only succeeds if its divisions act together. Either all divisions attack or all divisions retreat. If only some divisions attack, the city can defeat them, and the retreating divisions will be too weak to resist being chased down. In a blockchain, consensus is also paramount. The power of the blockchain is that it is a shared source of truth. If different parts of the network have different blockchain states, they can no longer work together — they’re operating in different worlds.
Byzantine Fault Tolerance
The goal of the Byzantine generals is for every (non-traitorous) general to agree on the same decision. In a blockchain network, this means every non-malicious entity has the same blockchain state. The implication for Hyperledger Fabric is that the orderer service should be jointly controlled by the network’s members using a BFT algorithm that resists malicious activities by bad actors. It’s insufficient for one organization to control the orderer, because that organization itself may not be trustworthy. After all, one of the motivations to use blockchain is so that organizations can cooperate while only partially trusting one another.
The Big Picture
The Hyperledger Fabric architecture lets users choose an orderer service that implements a consensus algorithm that fits their application. One desirable property is Byzantine fault tolerance (BFT), which says the orderer can do its job even in the presence of malicious actors.
It’s important to note that BFT, however it’s implemented, only applies to the ordering of transactions in Hyperledger Fabric. Its job is to ensure that every peer has the same list of transactions on its ledger.
In order to get on the ledger in the first place, the transactions first have to get past endorsement policies and the endorsing peers that ran the transactions’ chaincode. (More details in a previous post.) Then after they’re on the ledger, the transactions are checked a final time by each peer’s validation step. Every step of the way, Fabric has a system in place to prevent bad things from happening.
