Comparison of Raft and PBFT Consensus Algorithms in Private and Consortium Blockchains

Consensus algorithms are a core component of blockchain technology. This article explains the Raft algorithm used in private (permissioned) chains and the PBFT algorithm used in consortium (permissioned) chains, and analyzes their basic processes, fault‑tolerance limits, and communication complexities.

What is consensus? In the real world, consensus means a group of people reaching agreement on one or more statements. In distributed systems, consensus means multiple nodes agreeing on the same data (point consensus) and on the order of multiple data items (line consensus). Achieving agreement on data order is the essential challenge for most consensus algorithms.

Types of chains

Private chain: uses traditional distributed‑system consensus (e.g., Zookeeper’s Zab, a Paxos‑like protocol). It assumes no malicious nodes, only crash or network failures.

Consortium chain: exemplified by Hyperledger Fabric (PBFT in version 0.6). It must tolerate both crash failures and Byzantine (malicious) nodes, and new nodes must be vetted before joining.

Public chain: similar to consortium chains regarding fault tolerance, but nodes can join or leave freely without strict verification.

1. Raft algorithm Raft has three roles—follower, candidate, leader—and two main processes: leader election and log replication (recording and committing logs). It tolerates up to (N‑1)/2 crash‑only failures, where N is the total number of nodes. An external animation (http://thesecretlivesofdata.com/raft/) illustrates leader election, log replication, and recovery from network partitions.

2. PBFT algorithm PBFT was created to solve the Byzantine Generals Problem. It tolerates up to (N‑1)/3 Byzantine (malicious or crash) failures, requiring at least 3f+1 nodes to tolerate f faulty nodes. The algorithm consists of three phases—pre‑prepare, prepare, and commit—followed by a client‑side verification that f+1 identical replies have been received. Detailed message formats (e.g., <pre-prepare, v, n, d> ) and the role of view numbers, checkpoints, and high/low watermarks are described.

Core three‑phase flow of PBFT The primary node (leader) sends a pre‑prepare message to replicas, replicas broadcast prepare messages, and finally broadcast commit messages. When a node receives 2f+1 commit messages (including its own), the request is considered committed and the response is sent back to the client.

ViewChange If the leader crashes or is suspected, a view‑change procedure (view‑change, view‑change‑ack, new‑view) is triggered, incrementing the view number and electing a new leader.

3. Comparison of Raft and PBFT The article presents a table (omitted here) comparing the two algorithms in terms of applicable environments, communication complexity (Raft: O(N), PBFT: O(N²)), maximum fault tolerance ((N‑1)/2 vs. (N‑1)/3), and workflow differences. Raft elects the fastest candidate as leader, while PBFT rotates leaders by identifier. In Raft, followers never reject the leader’s commands; in PBFT, replicas may reject commands they deem inconsistent.

Conclusion Raft and PBFT are the classic consensus mechanisms for private and consortium blockchains respectively. Their fundamental differences lie in fault‑tolerance (crash‑only vs. Byzantine) and in how nodes interact during the consensus process.