Impact of Network Topologies on Blockchain Performance

This work studies how the underlying network topology affects blockchain performance. Instead of treating the network as a fixed or opaque execution layer, the paper evaluates multiple blockchain systems under controlled topologies, realistic workloads, and reproducible experimental conditions.

Context

Blockchain systems are usually evaluated through throughput, latency, commit rate, and resource consumption. However, those measurements can change significantly depending on the network conditions under which the blockchain is executed. Public clouds are useful for realistic deployments, but they also introduce cost, opacity, and time-dependent variability. This paper addresses that problem by combining reproducible cluster-based execution with programmable network emulation.

The central idea is simple: to compare blockchains meaningfully, the evaluator must also control the shape and behaviour of the network in which validators, clients, and gateways communicate.

Why network control matters

The paper starts from a practical benchmarking problem: cloud network conditions vary across regions and over time. This makes blockchain experiments difficult to reproduce if the network layer is not explicitly modelled. The heatmap motivates the need for controlled experiments that can reproduce cloud-inspired latency and throughput conditions without depending entirely on live cloud variability.

Lilith architecture

The work introduces Lilith as a topology-aware benchmarking framework. Lilith connects experiment parameters, topology generation, network datasets, Docker-based execution, Kollaps network emulation, monitoring and export modules, and Diablo-based blockchain workload execution. This creates a repeatable pipeline for running blockchain experiments under programmable network conditions.

Topologies evaluated

The evaluation compares blockchain behaviour across five network topologies. These topologies are not presented as perfect representations of every real blockchain deployment. Instead, they are controlled network shapes used to expose how different communication structures influence performance and robustness.

Fat-tree

A layered topology often associated with data-center-like infrastructures.

Full mesh

A dense topology where gateways are directly interconnected.

Hypercube

A structured topology inspired by parallel and distributed computing systems.

Scale-free

A topology with highly connected hubs, resembling Internet-like networks.

Torus

A wrap-around grid topology often used in high-performance computing contexts.

What the experiments show

The experiments compare how blockchain systems behave under different workloads and network topologies. The results show that topology is not a secondary detail: the communication structure of the network can change throughput, latency, commit behaviour, and network load. The paper highlights that full mesh, hypercube, and torus-like structures can improve performance under demanding workloads, while different blockchain systems react differently to the same network conditions.

Network dynamics

Beyond static topologies, the paper also evaluates dynamic network conditions such as packet drop, bandwidth congestion, and node crash. This is important because real distributed systems do not operate in perfectly stable networks. The goal is to understand which systems remain robust and which systems are more sensitive when the network degrades.

Packet drop

Stress scenario used to observe how blockchain systems react when packet loss increases.

Bandwidth congestion

Stress scenario used to study the impact of constrained network capacity.

Node crash

Stress scenario used to evaluate behaviour when part of the network becomes unavailable.

Contribution

• Shows that blockchain benchmarking should explicitly account for network topology and network variability.
• Evaluates Algorand, Diem, Ethereum, Quorum, and Solana under controlled topology-aware conditions.
• Uses realistic workload families including transfer transactions and smart-contract-oriented workloads.
• Introduces Lilith as a reproducible framework integrating Diablo workload execution with Kollaps network emulation.
• Connects cloud-inspired network measurements with controlled cluster-based experiments.

Links