Consensus Protocols

A guide to choosing between IBFT 2.0, QBFT, and Clique consensus protocols for Hyperledger Besu

CatalyX Blockchain Manager supports the permissioned version of Hyperledger Besu with three Proof of Authority (PoA) consensus protocols: IBFT 2.0, QBFT, and Clique. Each has specific characteristics that make it better suited to certain use cases.

What are consensus protocols?

Consensus protocols are the programmatic process by which blockchain networks come to agreement on their ledger state. They govern which data or transaction is valid and should be added to the shared ledger, and which should be rejected.

What is Proof of Authority (PoA)?

Proof of Authority (PoA) is a collection of consensus algorithms developed for blockchain to ensure performance improvements over classical Practical Byzantine Fault Tolerance (PBFT). PoA is effective when participants are known to each other and there is inter-party trust.

In PoA, the focus is placed on the identity and reputation of decision makers, rather than on nodes staking coins or proving work. Selected validators stake their identity in the voting process, making PoA appropriate for permissioned consortium networks. There is a degree of fault tolerance: consensus can still be reached despite a proportion of disagreement within the network.

Comparison: IBFT 2.0 vs. QBFT vs. Clique

Consensus Protocol	Validators Required	Chain can fork?	Fault Tolerance
IBFT 2.0	4	No	2/3
QBFT	4	No	2/3
Clique	1	Yes	1/2

IBFT 2.0 (Istanbul Byzantine Fault Tolerance 2.0): A second-generation expression of IBFT, developed to achieve further improvements over PBFT, making it more effective for large-scale blockchain networks.

QBFT (Quorum Byzantine Fault Tolerance): An enterprise-grade evolution of IBFT developed by ConsenSys, designed to better suit the scalability and processing requirements of enterprise networks. It incorporates a more efficient leader election process and reduces the number of communication rounds required to reach agreement. It is more complex than IBFT, however some organizations may prefer IBFT as the simpler alternative.

Clique: Developed to approximate the Ethereum mainnet for use in test environments. Clique employs forking but is faster than the other options and requires only a single validator. It is not suitable for production networks.

Which consensus protocol should I choose?

Finality

QBFT and IBFT 2.0 have immediate finality: there are no forks and all valid blocks are included in the main chain.

Clique does not have immediate finality. Implementations using Clique will experience forks and chain reorganizations.

Liveness / Minimum validators

QBFT and IBFT 2.0 require a minimum of 4 validators to be Byzantine fault tolerant.

Clique can operate with a single validator, though this offers no redundancy if the validator fails. Clique is also faster than the other two protocols.

Summary

Use IBFT 2.0 or QBFT if:

• Immediate finality is required

• You need Byzantine fault tolerance

• You have at least 4 validators

• You are deploying to production

Use Clique if:

• You are in a test or development environment

• You need only a single validator

• Immediate finality is not required

Questions to guide your decision

What are my finality requirements?

Does the use case require block creation to be instantly confirmed? If yes, choose IBFT 2.0 or QBFT.

How many validators does my network need?

• How many validators will the network start with?

• Could validators be added or leave the network over time?

• Would participants need to join without being validators?

IBFT 2.0 and QBFT both require a minimum of 4 validators. Clique requires only 1.

What fault tolerance does my network require?

How many validators can the network afford to have go offline? IBFT 2.0 and QBFT tolerate up to ⅓ of validators being unavailable. Clique tolerates up to ½.

How fast do I need to create new blocks?

Clique has a higher transaction speed than IBFT 2.0. However, Clique is not recommended for production.