Consensus Mechanisms

Last updated 2 months ago

The process of keeping the ledger transactions synchronized across the network — to ensure that ledgers update only when transactions are approved by the appropriate participants and that when ledgers do update, they update with the same transactions in the same order — is called consensus. Source.

Chainstack supports the following blockchain protocols and their respective consensus mechanisms. You will see that in most cases, the consensus mechanism being employed is the default one. In other words, there is no need for the user to choose a specific consensus mechanism, since it is already being implemented under the hood.

Hyperledger Fabric

There are three types of nodes in Fabric — an Orderer, a Peer, and a Client. It’s the Orderer node that is responsible for establishing consensus. Further, there are multiple Orderers, so an Orderer being the single point of failure in a Fabric network can be ruled out.

In the current stable version 1.3, Fabric supports two consensus mechanisms SOLO and Kafka. SOLO is not intended for production, while Kafka is crash fault-tolerant. No date has been set yet to provide a BFT version of the ordering service.

On Chainstack, we are using Kafka under the hood, so there is no need for a user to choose any consensus algorithm.


MultiChain uses a distributed consensus between identified block validators. It's close in spirit to something like PBFT (Practical Byzantine Fault Tolerance), but instead of multiple validators per block, there is one validator per block, working in a round-robin manner.

On Chainstack, the round-robin consensus is implemented under the hood, so there is no need for a user to choose a consensus algorithm.


In Quorum the choices offered are an etcd implementation of Raft and IBFT. By default Raft is used to provide a consensus mechanism that is Crash Fault Tolerant, and IBFT is its Byzantine Fault Tolerant counterpart.

Raft is recommended for a situation where all parties in a network are trusted and follow a leader-follower model. Achieving consensus in the presence of Byzantine nodes is a relatively time consuming process. This is because of the number of encrypted messages that need to be passed back and forth to tackle any Byzantine node. In the absence of a Byzantine scenario, however, Raft delivers faster block times and transaction finality.

IBFT, on the other hand, is used in situations where you want to run a network despite the presence of mutually distrusting nodes (a Byzantine situation). Consider a scenario where you are forming a consortium that includes competitors. The possibility of a competitor-owned node being compromised or turning malicious cannot be ruled out. You might want to consider IBFT for such scenarios.

Chainstack offers both options allowing the user forming the network to choose the appropriate one.