A variation of the Practical Byzantine Fault Tolerance (PBFT) protocol, Istanbul Byzantine Fault Tolerance (IBFT) is a Byzantine Fault Tolerant (BFT) consensus procedure. It was introduced as EIP 650 for the Ethereum blockchain and was especially made to function with blockchain networks.
The goal of the voting-based consensus method known as IBFT is to address Byzantine defects. It can be found in Hyperledger Fabric implementations as well as platforms such as Quorum.
Relationship to Practical Byzantine Fault Tolerance (PBFT)
Although IBFT draws inspiration from PBFT, it makes certain significant modifications to better fit blockchain environments:
- Client Concept: In contrast to PBFT, IBFT views the proposer and all validators as clients rather than having a separate idea of a client.
- Dynamic Validators: Unlike PBFT, which uses static nodes, IBFT uses dynamic validators, which allow nodes to be voted into or out of the validator set as needed.
- Node Types: There are two kinds of nodes in an Istanbul Byzantine Fault Tolerance network: “validators” that actively take part in the IBFT consensus process and “nodes” that synchronise with the blockchain without taking part in consensus.
- View/Round Change: In contrast to PBFT, Istanbul Byzantine Fault Tolerance employs a more straightforward structure for its view-change (or round change) signals.
- Checkpoints and Progress: Checkpoints are not a clear idea in IBFT. Rather, each block itself acts as a progress indication (chain height). Additionally, IBFT does not include a waste collection notion.
Network Model and Assumptions
Istanbul Byzantine Fault Tolerance uses a particular network model that consists of:
- Minimum Nodes: According to the usual BFT assumption, it takes at least 3F + 1 processes to tolerate F defective nodes.
- Network Type: A message-passing network that is somewhat synchronous is assumed.
- Cryptography: Digital signatures and pertinent cryptographic hash algorithms are regarded as secure since it is based on sound cryptography.
Phases and Consensus Process
Each round of the IBFT protocol is conducted using a round-robin process to elect a new leader. There are three main stages to the consensus process:
- Pre-prepare: The chosen proposer broadcasts a proposal (block) as a pre-prepared message to start a new round. Every other validator awaits this notification.
- Prepare: (Implicit in the flow; nodes indicate readiness after getting the pre-prepare, just like in PBFT).
- Commit: (Inferred in the flow; nodes validate the agreement, much like in PBFT).
You can also read Remix IDE Blockchain: Online Solidity Compiler For Ethereum
Consensus States
IBFT is a State Machine Replication (SMR) technique, meaning that in order to achieve block consensus, each validator must keep up a state machine copy. Important states of consensus include:
- New round: At this point, the proposer sends out the block proposal and a new round begins.
- Final committed: When the recently suggested block is successfully added to the blockchain, a validator reaches this state, signifying that it is prepared for the following round.
- Round change: Validators wait for a sufficient number of round change messages (2F + 1) for the new round number in this stage.
Validator Management
IBFT’s validator management technique is one of its noteworthy features. This method allows network members to vote for validators to be added or removed, making validator management flexible and efficient.
In conclusion, by adding dynamic validator sets and simplifying the view-change process to the PBFT model, IBFT provides a reliable and secure BFT consensus mechanism for blockchain networks, especially in permissioned contexts.
You can also read Blockchain Performance Metrics, Scalability & Optimization