[Paper Review] Correctness Analysis of IBFT

Roberto Saltini, Hyland-Wood, David|arXiv (Cornell University)|Jan 22, 2019

Distributed systems and fault tolerance21 references14 citations

TL;DR

This paper formally analyzes the Istanbul Byzantine Fault Tolerance (IBFT) consensus protocol and identifies critical flaws in its persistence and liveness guarantees under an eventually synchronous network model. It proposes two protocol modifications—inspired by PBFT and Tendermint—to restore Byzantine-fault-tolerant persistence and liveness, ensuring correct finality in private and consortium blockchains.

ABSTRACT

In this paper we analyse the correctness of Istanbul BFT (IBFT), which is a Byzantine-fault-tolerant (BFT) proof-of-authority (PoA) blockchain consensus protocol that ensures immediate finality. We show that the IBFT protocol does not guarantee Byzantine-fault-tolerant consistency and liveness when operating in an eventually synchronous network, and we propose modifications to the protocol to ensure both Byzantine-fault-tolerant consistency and liveness in eventually synchronous settings.

Motivation & Objective

• To formally verify the correctness of the IBFT consensus protocol in a distributed environment.
• To identify and analyze failures in IBFT's persistence and liveness guarantees under an eventually synchronous network model.
• To propose protocol modifications that restore Byzantine-fault-tolerant persistence and liveness in IBFT.
• To evaluate two distinct architectural approaches—PBFT-like and Tendermint-like—for enhancing IBFT's fault tolerance.
• To provide formally verified, implementable changes to IBFT that ensure correct finality in production private and consortium blockchain networks.

Proposed method

• Formal modeling of IBFT using process algebra notation to precisely define protocol behavior and message flows.
• Identification of failure scenarios where IBFT fails to maintain consistency (persistence) or progress (liveness) under network delays or Byzantine proposers.
• Proposal of a PBFT-like solution involving extended Pre-Prepare messages with locked round values and relocking logic to improve liveness and finality.
• Design of a Tendermint-like solution based on relocking mechanisms, where validators can re-lock on higher rounds using quorum Prepare messages and Pre-Prepare messages with matching locked rounds.
• Specification of five protocol modifications to ensure Byzantine-fault-tolerant persistence, including message validation and state tracking enhancements.
• Comparison of the two solutions in terms of communication efficiency, round-trip performance, and resilience to proposer failures or network delays.

Experimental results

Research questions

• RQ1 Does IBFT guarantee Byzantine-fault-tolerant persistence in an eventually synchronous network model?
• RQ2 Does IBFT guarantee Byzantine-fault-tolerant liveness in an eventually synchronous network model, even under fail-stop failures?
• RQ3 Can the IBFT protocol be modified to ensure both persistence and liveness under eventual synchrony?
• RQ4 How do PBFT-inspired and Tendermint-inspired modifications compare in terms of performance and correctness?
• RQ5 What specific protocol changes are required to restore fault tolerance in IBFT while maintaining backward compatibility with existing implementations?

Key findings

• IBFT does not guarantee Byzantine-fault-tolerant persistence in an eventually synchronous network, meaning honest nodes may diverge on the blockchain state.
• IBFT does not guarantee Byzantine-fault-tolerant liveness in an eventually synchronous network, even when only fail-stop failures occur, due to message delay and proposer faults.
• The PBFT-like solution ensures decision within a single round if the current proposer is honest and messages are delivered within the round timer, improving liveness under optimal conditions.
• The Tendermint-like solution reduces overall bandwidth usage during round changes compared to the PBFT-like approach, offering better scalability in high-latency environments.
• The PBFT-like solution can achieve finalization in two communication phases (Pre-Prepare and Prepare) when no Byzantine validators are present and network delay exceeds the round timer.
• The proposed modifications, particularly the relocking mechanism with locked round tracking, are critical to restoring liveness and preventing indefinite consensus stalls.