Istanbul Byzantine Fault Tolerance (IBFT) was first proposed by the team at AMIS. The consensus mechanism is based on an implementation of practical byzantine fault tolerance (pBFT). The consensus mechanism is widely held as the best implementation to the byzantine generals formula, however its drawbacks include the fact that under totally decentralised peers, it does not scale well.
The pBFT consensus was proposed long before bitcoin was invented. In a paper in 1999, Lisk and Castro argued that the async nature allowed the protocol to work in a fully autonomous way without needing central consensus to resolve any conflicts.
Current projects running on variants of this consensus include cosmos (and binance chain), and some concepts have been also been used by projects like Bitshares, EOS and LISK amongst others.
In IBFT, the nodes to faulty nodes relationship is expressed as:
There is a lot of technical documentation already available regarding the consensus mechanism.
Immediate block finality. At any given time, only one block producer can propose a block. This means the chain does not suffer from forks, or orphans. Single block finality is guaranteed on a protocol level.
Reduced computations: Currently Ledgerium runs at 5 seconds per block. This limit can theoretically brought down below one second under controlled networks. The effort to propose and produce a block is minimal for CPU and network propagation.
High data integrity and fault tolerance. IBFT needs a roughly 66% consensus for all decisions on the chain, including producing blocks. This means that node participation and majority lies with the block producers at all times who have the biggest stake in the network.
Governance: In IBFT governance is baked into the protocol level by only allowing proposed peers to be voted in the block producers by a super majority and removed from the consortium by a super majority also.
The state machine and its transitions are given in the diagram and explanation below.
NEW ROUND: Proposer to send new block proposal. Validators wait for PRE-PREPARE message.
PRE-PREPARED: A validator has received PRE-PREPARE message and broadcasts PREPARE message. Then it waits for 2F + 1 of PREPARE or COMMIT messages.
PREPARED: A validator has received 2F + 1 of PREPARE messages and broadcasts COMMIT messages. Then it waits for 2F + 1 of COMMIT messages.
COMMITTED: A validator has received 2F + 1 of COMMIT messages and is able to insert the proposed block into the blockchain.
FINAL COMMITTED: A new block is successfully inserted into the blockchain and the validator is ready for the next round.
ROUND CHANGE: A validator is waiting for 2F + 1 of ROUND CHANGE messages on the same proposed round number.