Raft vs PBFT: Detailed Comparison of Consensus Algorithms for Private and Consortium Blockchains

Consensus algorithms are the core of blockchain technology, enabling a group of nodes to agree on the state of a distributed ledger. In public blockchains like Bitcoin and Ethereum, Proof‑of‑Work (PoW) and Proof‑of‑Stake (PoS) are used, while private and consortium chains rely on traditional distributed‑system consensus protocols.

Private chains typically adopt algorithms such as Zookeeper's Zab or Paxos, assuming no malicious nodes, whereas consortium chains (e.g., Hyperledger Fabric) must tolerate both faulty and malicious nodes, requiring more robust protocols like PBFT. Public chains must handle open participation and potential attacks.

Raft Algorithm – Raft defines three roles (follower, candidate, leader) and operates through leader election and log replication (record and commit phases). It tolerates up to (N‑1)/2 faulty nodes, assuming only crash failures. An illustrative animation of Raft is referenced in the original article.

PBFT Algorithm – PBFT solves the Byzantine Generals problem by requiring a reliable communication channel and tolerating both crash and malicious (Byzantine) faults. It guarantees safety when the number of faulty nodes f satisfies 3f+1 ≤ N, giving a maximum fault tolerance of (N‑1)/3. The protocol consists of three phases: pre‑prepare, prepare, and commit, followed by view‑change mechanisms, checkpoints, and high/low watermarks to manage state and memory.

The comparison shows that Raft’s communication complexity is O(N) because only the leader communicates with followers, while PBFT’s three‑phase broadcast results in O(N²) messages. Raft elects a leader based on speed and fails over only when the leader crashes; PBFT rotates leadership and requires a majority (2f+1) of nodes to agree on each request, providing stronger guarantees against Byzantine behavior.

In conclusion, Raft is suitable for environments without malicious actors, offering simpler implementation and lower communication overhead, whereas PBFT is designed for consortium blockchains where Byzantine faults must be tolerated, at the cost of higher message complexity and stricter quorum requirements.