Hyperledger Fabric And SmartBFT
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.
There are two main attacks that are considered outside of the crash fault tolerant threat model, but must be protected against in the Byzantine fault-tolerant setting:
Block withholding: A Byzantine orderer might be reluctant to send newly formed blocks to peers that connect to it, either because of malicious intent or to save egress network bandwidth charges from its hosting provider. Fabric architecture relies on peers receiving newly formed blocks as fast as possible because otherwise client transaction submission times out and smart contract simulation results in stale reads.
Block forgery: A Byzantine orderer might try to forge a block and send it to peers or other ordering nodes that replicate from it, in order to alter the smart contract execution on peers by subterfuge. One way of doing this, is to omit a transaction from a block, or re-order transactions within a block.
To circumvent block forgery attacks, the following invariant should be preserved: A set of signatures on a block should only be considered valid if it is impossible for the parties running the protocol to construct a set of signatures on a different block that is also considered valid.
Byzantine Fault Tolerance and Fabric
One of the fundamental properties of a blockchain, be it permissioned or permissionless is achieving a total order of transactions across all nodes. Achieving total order in blockchains is done by having nodes participate in a consensus algorithm, where nodes input to the algorithm a set of transactions, and the algorithm makes all nodes receive back an ordered subset of the transactions.
There are various types of consensus algorithms, and they differ not only in what is done but also in the assumptions on the extent of which nodes may deviate from the algorithm.
In a Crash Fault Tolerant (CFT) consensus algorithm, the assumption is that each node follows the protocol unless it crashes or is unreachable.
A more involved setting is where nodes may not only crash but may also behave arbitrarily. In such a model, the nodes may send other nodes conflicting messages, lie about events they have observed, collude with other nodes and also sign conflicting votes. In such a setting, it is crucial to run a Byzantine Fault Tolerant protocol that can withstand corruption of a subset of the nodes. Otherwise, some peers may be misled to believe a version of the world state, while other peers, a different version. Such a situation may lead to double spending funds or to total service termination.
Hyperledger Fabric has utilized a Raft crash fault-tolerant (CFT) ordering service since version v1.4.Fabric v3.0 is the first release to provide a BFT ordering service based on the SmartBFT consensus library. Byzantine Fault Tolerant (BFT) ordering service can withstand crash failures and a subset of nodes behaving maliciously.
BFT is a desirable property of a consensus algorithm in Hyperledger Fabric that ensures that the orderer can do its job even in the presence of malicious actors. The orderer determines which transactions to add to the blockchain and in what order. Consider using the BFT orderer if true decentralization is required, where up to and not including a third of the parties running the orderers may not be trusted due to malicious intent or being compromised.
The BFT-SMaRt module for Fabric’s ordering service (OSN) consists of an ordering cluster composed of a set of 3f + 1 nodes that execute the BFT-SMART’s replication protocol with the purpose of totally ordering these
envelopes among them. In a Byzantine setting, there is a fundamental assumption that there is an upper bound on the number of malicious or failed nodes among all the nodes that run the protocol, and that upper bound is denoted as f. In BFT, the ordering service is comprised of n>3f for some f>0, so we have up to f nodes which are either offline, unreachable or malicious, and at least n-f nodes that are online, reachable and follow the protocol.
An easy way of ensuring malicious orderers do not refrain from sending newly formed blocks is to simply pull blocks from f+1 distinct orderers. This ensures that even if we happen to connect to all f malicious orderers that will not send us blocks, the remaining orderer will, since it is honest.
Obviously, such an approach increases the network bandwidth utilization of the orderers by a factor of f which is linear in the number of total ordering service nodes that run the consensus protocol.
