Benchmarking Blockchain Latency and Throughput Under Load
Summary
The article proposes a way to compare blockchain performance by measuring transaction latency and throughput together. Latency should reflect the time to valid confirmation, including the extra depth needed when a transaction can be reorganized. Throughput is the handled request rate. Their relationship changes with load: latency tends to stay near a floor when contention is low, while near saturation throughput levels off and queueing can sharply increase latency. The authors recommend evaluating the hot zone where both metrics respond to load.
For realistic tests, they favor open-loop request generation, which can model queued arrivals, and probabilistic interarrival times such as a Poisson process. Preloading requests can bias results, and a warm-up period helps avoid measuring pipeline startup. Comparisons should use throughput at a stated latency service objective and leave capacity for bursts. The method also describes sampling requests or using a low-rate probe generator to measure latency at heavy load. These are benchmarking recommendations, not comparative results for specific networks.
Key ideas
- Blockchain benchmarks should measure latency and throughput together across varying load levels.
- Latency for reorganization-prone consensus should include the wait for sufficient block depth.
- Open-loop workloads with probabilistic arrivals can expose queueing that closed-loop tests may hide.
- Warm-up, preloaded requests, and experiment length can affect measured results.
- Compare systems at a defined latency objective and avoid operating beyond saturation.
- At high load, sampled transactions or a low-rate probe generator can reduce timing overhead.
Tags
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.