> For the complete documentation index, see [llms.txt](https://docs.catalyx.solutions/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catalyx.solutions/catalyx-blockchain-manager/hyperledger-besu/version-1.1.0/choose-a-consensus-protocol.md).

# Consensus Protocols

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

{% columns %}
{% column %}
**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
  {% endcolumn %}

{% column %}
**Use Clique if:**

* You are in a test or development environment
* You need only a single validator
* Immediate finality is not required
  {% endcolumn %}
  {% endcolumns %}

## Questions to guide your decision

<details>

<summary>What are my finality requirements?</summary>

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

</details>

<details>

<summary>How many validators does my network need?</summary>

* 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.

</details>

<details>

<summary>What fault tolerance does my network require?</summary>

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 ½.

</details>

<details>

<summary>How fast do I need to create new blocks?</summary>

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

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.catalyx.solutions/catalyx-blockchain-manager/hyperledger-besu/version-1.1.0/choose-a-consensus-protocol.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.