Choose a Consensus Protocol

Catalyst Blockchain Manager supports the permissioned version of Hyperledger Besu. We can employ three different Proof of Authority consensus protocols, IBFT2, QBFT, or Clique. Each of these protocols has its own specific characteristics and requirements, making it better suited to certain use cases, and less appropriate for others. The best choice is determined by the specifics of the use case.

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

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

In PoA consensus algorithms, the focus is placed on the identity and reputation of decision makers, rather than on these nodes staking coins or proving work. Certain nodes or participants are selected from trusted members of the network and are designated as validators (either by participants raising this question to a vote or via smart contracts). This means that PoA-based networks inherently require certain highly-trusted participants to operate.

Validators must collectively reach agreement on data, staking their identity in the voting process. This makes it appropriate for permissioned consortium networks. There is, of course, a degree of fault tolerance: consensus can still be reached despite a proportion of disagreement (or even bad actors) existing within the network.

Catalyst supports Hyperledger Besu implementations using three distinct consensus protocols: IBFT, QBFT, and Clique.

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 use in large scale blockchain networks.

QBFT (Quorum Byzantine Fault Tolerance): An enterprise-grade evolution of IBFT developed by ConsenSys and designed to be more suited to the scalability and processing requirements of enterprise networks. Among the improvements, QBFT incorporates a more efficient leader election process and reduces the number of communication rounds required to achieve agreement among nodes. It is, however, a more complex undertaking and certain organizations might prefer IBFT, as the simpler alternative.

Clique: Developed to approximate the Ethereum mainnet for use in test environments, Clique employs the existing Ethereum block data structure while adding voting functionality. Clique employs forking, but is faster than the other options and requires only a single validator. It is not suitable for in-production networks.

The most important considerations are the needs of the use case. Does it require immediate transaction finality? How many participants will be involved in the network and how likely are they to be available to handle voting requirements?

The central question is whether or not immediate finality is required for a given blockchain project.