[Paper Review] Impact of network delays on Hyperledger Fabric

Thanh Son Lam Nguyen, Guillaume Jourjon+2 more|arXiv (Cornell University)|Mar 21, 2019

Blockchain Technology Applications and Security6 references7 citations

TL;DR

This paper evaluates the impact of network delays on Hyperledger Fabric, a permissioned blockchain using PBFT consensus. By deploying the system across geographically distant clouds (France and Germany) with controlled delays up to 3.5 seconds, the study demonstrates that block propagation delays cause severe ledger desynchronization—resulting in a 134-second offset for the 100th block—rendering the system unsuitable for critical applications like banking due to lack of consistency guarantees.

ABSTRACT

Blockchain has become one of the most attractive technologies for applications, with a large range of deployments such as production, economy, or banking. Under the hood, Blockchain technology is a type of distributed database that supports untrusted parties. In this paper we focus Hyperledger Fabric, the first blockchain in the market tailored for a private environment, allowing businesses to create a permissioned network. Hyperledger Fabric implements a PBFT consensus in order to maintain a non forking blockchain at the application level. We deployed this framework over an area network between France and Germany in order to evaluate its performance when potentially large network delays are observed. Overall we found that when network delay increases significantly (i.e. up to 3.5 seconds at network layer between two clouds), we observed that the blocks added to our blockchain had up to 134 seconds offset after 100 th block from one cloud to another. Thus by delaying block propagation, we demonstrated that Hyperledger Fabric does not provide sufficient consistency guaranties to be deployed in critical environments. Our work, is the fist to evidence the negative impact of network delays on a PBFT-based blockchain.

Motivation & Objective

• To investigate the impact of network delays on the consistency and performance of Hyperledger Fabric, a PBFT-based permissioned blockchain.
• To evaluate whether Hyperledger Fabric maintains strong consistency guarantees under realistic network conditions with significant transmission delays.
• To identify failure points in the system's architecture when delays exceed a threshold, particularly in block propagation and consensus coordination.
• To assess the system's resilience under high-latency conditions, especially in long-distance deployments across cloud regions.
• To provide empirical evidence that current versions of Hyperledger Fabric are not suitable for low-latency, high-consistency critical applications such as financial trading or real-time settlement systems.

Proposed method

• Deployed Hyperledger Fabric across two cloud environments in France (Sorbonne University) and Germany (Heidelberg University) to simulate long-distance network conditions.
• Introduced controlled network delays using traffic control tools (e.g., tc) to simulate transmission delays of up to 3.5 seconds between nodes.
• Measured block propagation times and ledger synchronization offsets by tracking block timestamps across peers in both locations.
• Monitored system behavior under increasing delays, including buffer overflow and peer disconnection events, using network analysis tools like Wireshark.
• Conducted experiments with increasing transaction loads (up to 30,000 transactions) to assess performance degradation and offset growth under high load.
• Analyzed the communication pattern between orderers and peers, particularly the feedback loop where peers signal receipt before receiving the next block, which amplifies delays.

Experimental results

Research questions

• RQ1 How do network delays affect block propagation and ledger synchronization in Hyperledger Fabric’s PBFT-based consensus?
• RQ2 What is the maximum network delay that Hyperledger Fabric can tolerate before experiencing significant desynchronization or system failure?
• RQ3 How does the system’s behavior change when delays exceed 3.5 seconds, particularly in terms of peer disconnection and consensus halting?
• RQ4 To what extent does the orderer’s buffer size contribute to the accumulation of propagation delays in high-latency environments?
• RQ5 Can Hyperledger Fabric maintain strong consistency guarantees in production-grade, long-distance deployments with realistic network delays?

Key findings

• With a 3.5-second network delay, the 100th block was synchronized with a 134-second offset between the French and German peers, indicating severe desynchronization.
• At a 3.5-second delay, the system experienced a 128-second offset for the first block and a 134-second offset for the 100th block, demonstrating exponential delay growth.
• When network delay exceeded 3.5 seconds (e.g., 3.58 seconds), the Sorbonne node was detected as disconnected by the Docker swarm, leading to system-wide failure.
• The system’s failure was traced to the feedback mechanism: peers send acknowledgment signals to the orderer, which delays the transmission of the next block by the same round-trip time, amplifying delays.
• With 30,000 transactions and a 3.5-second delay, the offset increased to over 1 hour and 10 minutes, showing that high transaction volume exacerbates desynchronization.
• The orderer’s buffer size was identified as a key factor in delay accumulation; when the buffer reached capacity, the orderer halted, causing the entire system to stop.