Skip to content
You are reading GoQuorum development version documentation and some displayed features may not be available in the stable release. You can switch to stable version using the version box at screen bottom.

Updated on August 11, 2021

Comparing Proof of Authority consensus protocols

GoQuorum implements the IBFT, QBFT, Raft, and Clique Proof of Authority (PoA) consensus protocols. PoA consensus protocols work when participants know each other and there is a level of trust between them (for example, in a permissioned consortium network).

PoA consensus protocols have faster block times and a much greater transaction throughput than the Ethash Proof of Work consensus protocol used on Ethereum Mainnet.

In the GoQuorum PoA consensus protocols, a group of nodes in the network act as validators (IBFT and QBFT), verifiers (Raft) or signers (Clique). Existing validators, verifiers, or signers vote to add or remove network nodes.


For the rest of this page, the term “validator” is used to refer to validators, verifiers, and signers.


Properties to consider when comparing the PoA consensus protocols are:

  • Immediate finality.
  • Minimum number of validators.
  • Liveness.
  • Speed.

Immediate finality

QBFT and Raft have immediate finality. When using QBFT and Raft there are no forks and all valid blocks get included in the main chain.

IBFT and Clique do not have immediate finality. Implementations using IBFT and Clique must be aware of forks and chain reorganizations occurring.

Minimum number of validators

To be Byzantine fault tolerant, IBFT and QBFT require a minimum of four validators. Byzantine fault tolerance is the ability to function correctly and reach consensus despite nodes failing or propagating incorrect information to peers.

Raft and Clique can operate with a single validator but operating with a single validator offers no redundancy if the validator fails.


Raft and Clique are more fault tolerant than IBFT and QBFT.

Raft and Clique tolerate up to half of the validators failing.


While Clique is Byzantine fault tolerant, Raft is only crash fault tolerant because the Raft leader is assumed to always act correctly.

IBFT and QBFT networks require greater than or equal to two-thirds of validators to be operating to create blocks. For example, a QBFT network of:

  • Four to five validators tolerates one unresponsive validator.
  • Six to eight validators tolerates two unresponsive validators.

Networks with three or fewer validators can produce blocks but do not guarantee finality when operating in adversarial environments.


We do not recommend using IBFT and QBFT networks with three nodes for production purposes.


Reaching consensus and adding blocks is fastest in Raft networks, then in Clique networks. For Clique, the probability of a fork increases as the number of validators increases.

For IBFT and QBFT, the time to add new blocks increases as the number of validators increases.

ConsenSys has acquired Quorum from J.P. Morgan. Please read the FAQ.
Questions or feedback? You can discuss issues and obtain free support on GoQuorum Slack channel.
For paid professional support by ConsenSys, contact us at