Consensus algorithms are one of the core innovations of blockchain, and yet also one of the most confusing. Satoshi Nakamoto created a version of Proof of Work (PoW) that was implemented as a means for simultaneously securing and validating Bitcoin transactions. The blockchain community has built on that core vision to create an alphabet soup of Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant), and many others that are all designed to build consensus in a distributed system, creating the single source of truth that makes blockchain so valuable.

IBFT (Istanbul Byzantine Fault Tolerant) is a consensus mechanism which is an alternative to Proof of Work in an Ethereum network. Like other algorithms, IBFT ensures a single, agreed-upon ordering for transactions in the blockchain, and provides added benefits for enterprises, including settlement finality. IBFT was first implemented in Geth by Amis Technologies, and soon after implemented in Quorum.

Before getting into the operation of the IBFT consensus mechanism, it is worth mentioning when and why one would want to use IBFT. In a public blockchain, the short answer is likely that you probably would not. But when it comes to consortium or private blockchains, IBFT starts to look quite appealing.

The PoW algorithm is famously costly, in both hardware and electricity. This cost is intentional, to prevent anyone from easily taking over the network, and thus PoW is very suitable for situations with full decentralization where anyone (including attackers) can participate. Nodes in the consortium/private chains used by enterprises, however, are intrinsically more trusted than those in a public chain. As such, the PoW consensus mechanism may be overly burdensome, and other mechanisms may provide “enough” trust to run a distributed system.

Proof of Stake, likewise, may be less relevant for enterprises, because paying for gas is less important in a permissioned network. Since nodes do not (necessarily) need to maintain currency in the network, PoS would introduce extraneous requirements.

Considering these tradeoffs, Proof of Authority (PoA) emerges as a possible best solution, utilizing a system whereby nodes in the network are allocated the privilege of producing new blocks for the chain using a round-robin or other arbitrary system.

IBFT is one of the many flavours of PoA and provides the following benefits:

  • Immediate block finality. There’s only 1 block proposed at a given chain height. The single chain thus removes forking, uncle blocks, and the risk that a transaction may be “undone” once on the chain at a later time.

  • Reduced time between blocks. The effort needed to construct and validate blocks is significantly reduced (in particular with respect to PoW), greatly increasing the throughput of the chain.

  • High data integrity and fault tolerance. IBFT uses a group of validators to ensure the integrity of each block being proposed. A super-majority (~66%) of these validators are required to sign the block prior to insertion to the chain, making block forgery very difficult. The ‘leadership’ of the group also rotates over time — ensuring a faulty node cannot exert long term influence over the chain.

  • Operationally flexible. The group of validators can be modified in time, ensuring the group contains only full-trusted nodes.

Here we provided an overview of IBFT, in mostly non-technical terms. For some of the original proposals of IBFT, you can review the EIPs on GitHub:

For the rest of this article, we’ll explore IBFT’s more technical considerations, discussing many of the concepts found in the EIPs and that we have learned through our own research.

Note: IBFT code can also be found in a go-ethereum pull request #16385.

Operation

The IBFT consensus mechanism comprises the following components:

  1. A PBFT inspired group consensus model.

  2. A process by which members can be added/removed from the validating group.

IBFT requires the Block Header to be (subtly) reworked to support all facets of the capability.

Group Consensus Model

Overview

IBFT uses a pool of validating nodes (Validators) operating on an Ethereum network to determine if a proposed block is suitable for addition to the chain.

One node of the Validators is arbitrarily selected as the Proposer and is responsible for constructing a block at the block-interval and sharing said block with the group. If a super-majority of the Validators deem the block to be valid it is added to the blockchain.

At the completion of the consensus round, the Validators may select a new Proposer which will be responsible for providing the candidate Block at the next block interval.

The consensus mechanism is a synchronised state machine which is responsible for ensuring all Validators append the same block to the chain at the same height.

If a block fails to insert, the Proposer is changed, and the process starts anew.

To ensure only one block can be appended to the state machine, IBFT prevents changing the proposed block once a super-majority of validators have agreed to its insertion (but not performed said work), this process is referred to as ‘Block Locking’.

The IBFT consensus mechanism offers system stability provided less than 1/3 of the validating nodes are behaving incorrectly (either due to being compromised or due to faulty code). I.e. to tolerate F faulty nodes the validation group must contain at least 3F + 1 nodes (more than this does not increase system integrity).

Note: Herein F implies the number of faulty nodes tolerated by the system.

State Machine
IBFT State Machine