BFT Consensus in Hyperledger Fabric 3.0: SmartBFT Guide

Hyperledger Fabric 3.0 introduces Byzantine Fault Tolerant (BFT) consensus to enterprise blockchain, allowing networks to remain secure even when up to one-third of ordering nodes are compromised or malicious. This is the most significant consensus upgrade since Fabric moved from Kafka to Raft.

TL;DR: Fabric 3.0 replaces the crash-fault-tolerant Raft consensus with BFT consensus powered by the SmartBFT library. This means your ordering service can now tolerate malicious nodes, not just crashed ones — a critical upgrade for multi-organization consortiums.

What is Byzantine Fault Tolerance (BFT)?

Byzantine Fault Tolerance (BFT) is a property of a distributed system that allows it to continue operating correctly even when up to one-third of nodes are faulty or malicious. In Hyperledger Fabric 3.0, BFT consensus replaced the crash-fault-tolerant Raft as the recommended ordering service for multi-organization networks.

Byzantine Fault Tolerance (BFT) is a property of a distributed system that allows it to continue operating correctly even if some of the nodes are faulty or malicious.

Before Fabric 3.0, Hyperledger Fabric used the Raft consensus mechanism, which is not Byzantine Fault Tolerant. This means that if a node in the ordering service was compromised, it could send incorrect blocks to the network, potentially causing a fork in the blockchain. While this scenario is uncommon in controlled enterprise environments, it represents a real security risk for multi-organization deployments.

How does SmartBFT work?

SmartBFT is a Go library that implements Byzantine Fault Tolerant consensus for Hyperledger Fabric. It tolerates up to one-third of malicious ordering nodes, making it suitable for consortiums where ordering nodes are operated by different organizations. As of Fabric v3.1.4 (February 2026), SmartBFT is stable and production-ready.

SmartBFT is a Go library that implements a Byzantine Fault Tolerant consensus mechanism. It has been integrated into Hyperledger Fabric 3.0 as the new ordering service consensus.

Pros

Tolerates malicious nodes — up to one-third (1/3) of the ordering network
Suitable for truly decentralized consortiums where ordering nodes are operated by different organizations
Enhanced security against data tampering at the ordering level
Capable of handling various network conditions and fault scenarios

Cons

Higher resource consumption compared to Raft (more message rounds per block)
Integration complexity when migrating existing Raft-based networks
Scalability considerations with large numbers of orderer nodes

How do I deploy Fabric 3.0 with BFT on Kubernetes?

You can deploy a Hyperledger Fabric 3.0 network with BFT consensus using the Bevel Fabric Operator. The operator manages Certificate Authorities, peers, and BFT-enabled orderers as Kubernetes custom resources. The operator simplifies the deployment process on Kubernetes and supports the BFT consensus configuration.

Watch the deployment walkthrough:

What is Hyperledger Fabric? — Overview of Fabric's architecture and use cases
Hyperledger Besu vs. Fabric — Comparing enterprise blockchain platforms
Hyperledger Fabric V2.3 on Kubernetes — Step-by-step deployment tutorial

References

Hyperledger Fabric Documentation — Official Fabric docs
SmartBFT Library on GitHub — BFT consensus implementation
Hyperledger Fabric 3.0 Release Notes — Official release information
Bevel Fabric Operator — Kubernetes operator for Fabric