Comparing Byzantine Fault Tolerance Consensus Algorithms

Consensus algorithms are the backbone of blockchain networks, ensuring agreement among participants in a decentralised environment.

In this blog post, we will delve into three prominent Byzantine fault-tolerant (BFT) consensus algorithms: PBFT (Practical Byzantine Fault Tolerance), IBFT (Istanbul Byzantine Fault Tolerance) and QBFT (Quorum Byzantine Fault Tolerance). We will examine their mechanisms, how they work, and highlight the differences between them.

Part 1: PBFT - Practical Byzantine Fault Tolerance

PBFT is a consensus algorithm introduced in the late 1990s by Castro and Liskov. It provides a robust solution for achieving consensus in distributed systems, even in the presence of Byzantine faults. PBFT assumes a network of N validators, with a fault tolerance threshold of F, meaning it can tolerate up to F faulty nodes.

Consensus Mechanism:

1. PBFT employs a three-phase consensus mechanism:

• Pre-Prepare: The consensus process begins with a primary node (proposer) broadcasting a proposed block to all other validators. Validators verify the proposal's validity and sequence number before entering the pre-prepared state.
• Prepare: Upon receiving a valid proposal, validators broadcast prepare messages to indicate their agreement on the proposed block. Validators wait to receive 2F + 1 prepare messages from other validators before progressing to the next phase.
• Commit: Once a validator receives enough prepare messages, it broadcasts a commit message to signal its commitment to the proposed block. Validators wait to receive 2F + 1 commit messages to ensure agreement before finalising the block.

​​

Fault Tolerance and Security:

1. PBFT guarantees safety and liveness properties, ensuring that the system reaches agreement on the correct block ordering and progresses even in the presence of Byzantine faults. By tolerating up to F faulty nodes in a network of N = 3F + 1 validators, PBFT achieves resilience against malicious or faulty behaviour.

Message Complexity:

1. One of the challenges with PBFT is its high message complexity. In the normal case, PBFT requires N² messages for each consensus round, which can impact scalability in large-scale networks.

Part 2: IBFT - Istanbul Byzantine Fault Tolerance

IBFT is a consensus algorithm inspired by PBFT, specifically designed for blockchain networks. It aims to address some of the challenges encountered when applying PBFT in a blockchain context.

Consensus Mechanism:

1. IBFT inherits PBFT's three-phase consensus mechanism: pre-prepare, prepare, and commit. However, there are some notable differences:

• Block Proposal: In IBFT, a proposer is continuously selected in each round to create a block proposal for consensus. This ensures the blockchain progresses with new verifiable blocks instead of individual read/write operations.
• Block Finality: IBFT guarantees block finality, meaning there are no forks, and any valid block must exist in the main chain. This prevents malicious nodes from creating alternative chains.
• Consensus Proof: IBFT leverages the consensus proof, which includes commitment signatures from validators. These signatures are appended to the block's extraData field, making blocks self-verifiable and enabling support for light clients.

Optimisation and Efficiency:

1. IBFT introduces optimisation techniques to enhance the consensus process's efficiency:

• Message Complexity Reduction: IBFT optimises the message complexity by allowing validators who receive 2F + 1 commit messages before 2F + 1 prepare messages to jump directly to the committed state. This optimisation speeds up the consensus process.
• In PBFT, the New-View message is used to initiate a new view or epoch when the primary replica is suspected to be faulty or when a new primary replica needs to be elected. This message allows the replicas to coordinate and agree on a new primary replica for the next view. In contrast, IBFT simplifies this process by using a round-robin mechanism. In a round-robin scheme, the role of the primary replica is cyclically rotated among the participating nodes. Each node takes turns being the primary replica for a particular block or round of the consensus process. The round-robin approach eliminates the need for explicit New-View messages and the associated complexity of primary replica election.

Validator List Voting:

1. IBFT incorporates a validator voting mechanism similar to Clique. Validators can cast votes to propose changes to the validator list, and proposals reaching majority consensus come into effect.

Comparison: PBFT vs. IBFT

• In IBFT there is no client submitting requests to the network, instead, all of the validators can in turn propose a block to the network of validators.
• IBFT allows for two types of nodes: validators that take part in the consensus protocol and standard nodes that validate blocks but do not participate in the consensus protocol.
• The set of validators in PBFT is static whereas IBFT features a dynamic validator-set where validators can be added to, or removed from, the set (validators may be voted in and out as needed).
• IBFT specifies a simplified version of the so-called View-Change message of PBFT and does not include the so-called New-View message included in the PBFT protocol. 
• In IBFT, the concept of explicit checkpoints is not utilised. However, each IBFT block can be viewed as an equivalent of a PBFT checkpoint. This means that at the completion of each IBFT block, a stable global state is reached, similar to the purpose of a checkpoint in PBFT.

Part 3: QBFT - Quorum Byzantine Fault Tolerance

One prominent and the recommended enterprise-grade consensus protocol designed for private enterprise networks is the Quorum Byzantine Fault Tolerance (QBFT). QBFT, developed by ConsenSys in partnership with JP Morgan, is an extension of the Istanbul Byzantine Fault Tolerance (IBFT) consensus algorithm, incorporating modifications and enhancements tailored for enterprise use cases.

It is implemented by ConsenSys in both Quorum and Besu. Besu is an open-source Ethereum client developed under the Hyperledger umbrella, offers robust support for QBFT(and now backed by Web3 Labs through our Hyperledger Besu support), allowing organisations to leverage its features for building and deploying secure and scalable private blockchains. 

Messages overview: 

Message shapes

• Signatures - All messages are signed by the transmitting node to prevent byzantine behaviour
• Round specific - Every message specifies which Round it targets

Messages are 1st class citizens

• Need to be ordered (prior, current, future)
• Validated
• Gossipped

QBFT Header Details

• Similarly to IBFT and IBFT2 the block header extra data field contains - RLP encoded data containing seal, current set of validators, round block was sealed on and optionally a vote
• Mix hash value has a fixed value same as IBFT
• Unlike in IBFT the nonce and beneficiary fields are not used

Validators

• Can be added and removed by voting
• RPCs to add and remove validators
• Each validator maintains a vote tally and includes a vote when they next propose
• To change the validators set a quorum of (n/2) + 1 votes is required

As compared to IBFT, QBFT is optimised, modified and enhanced 

• Ambiguous Specification in IBFT:  IBFT's specification have been ambiguous or left open to interpretation due to the use of natural language and pseudocode
• Reduction of the number of messages exchanged - Round Change message complexity reduced from n³ to n²
• Chain Forking Prevention: Chain forking was possible in IBFT in different scenarios
• Weak-liveness of the IBFT: Block production could get stuck

To read more about these limitations and modifications please refer to this paper.

PBFT, IBFT, QBFT are all Byzantine fault-tolerant consensus algorithms that provide robust solutions for achieving agreement in decentralised networks. While PBFT serves as the foundation, IBFT builds upon it by tailoring optimisations and enhancements specifically for scaled blockchain systems. Building upon IBFT and solving its current limitations QBFT is the recommended enterprise-grade consensus protocol designed for private enterprise networks developed by ConsenSys, and supported by Web3 Labs through our Hyperledger Besu support.

Understanding the mechanisms and differences between PBFT, IBFT and QBFT empowers blockchain developers and architects to make informed decisions when choosing the appropriate consensus algorithm for their specific use cases. These consensus algorithms play a vital role in ensuring the integrity and trustworthiness of decentralised systems.

At Web3 Labs, we offer comprehensive support for QBFT/IBFT2 through our Hyperledger Besu support program. Our expertise in blockchain development and deployment allows us to assist organisations in setting up and maintaining private network infrastructures based on QBFT and IBFT2 protocols. Whether you need guidance in implementing or require production support for your private blockchain network, our team is here to help.