NEAR protocol sharding performance tested on everyday computer hardware
Shards on a Shoestring: Empirical Characterization of NEAR Protocol Nightshade Sharding on Commodity Hardware
Distributed, Parallel, and Cluster Computing
Summary
NEAR Protocol uses a method called sharding to handle a lot of transactions quickly, but past tests used expensive cloud computers. The authors tested the system on a more common, affordable setup and found how different parts limit speed as more shards are added. Surprisingly, slower hard drive writing helps control data flow, and removing it can cause the system to stall. They show that increasing shards only helps performance up to a point before it gets worse.
What this means in practice
- •For blockchain developers: Assess real-world performance limits of NEAR Nightshade on common hardware to optimize shard configurations.
- •For cloud infrastructure engineers: Plan cost-effective blockchain deployment by understanding hardware bottlenecks and trade-offs for sharded systems.
Authors
Sohini Sahukar, Om Amit Gandhi, Ioan Raicu
Abstract
NEAR Protocol's Nightshade architecture targets one million transactions per second (TPS) through horizontal sharding of both state and computation. Published benchmarks were produced on expensive Google Cloud Platform infrastructure costing approximately \$700 per hour, leaving a significant reproducibility gap for academic research. We present the first independent empirical characterization of NEAR Nightshade sharding on commodity hardware: a Chameleon Cloud bare-metal node with 48 hyperthreaded Intel Xeon cores, 128\,GB RAM, and HDD storage at 80--100\,MB/s. We systematically sweep shard count from $N{=}1$ to $N{=}24$, measuring aggregate TPS, per-shard TPS, block time, BFT finality, memory, and disk I/O. We identify three distinct bottleneck regimes: L3 cache pressure at low $N$, witness gossip pipeline saturation at mid $N$, and coherence collapse at high $N$. A key unexpected finding is that HDD write latency acts as implicit flow control for the witness gossip pipeline. Removing it via RAM-backed tmpfs causes complete chain stall at $N{=}16$, with a 29$\times$ spike in orphan witness rate at 47\% CPU utilization. Aggregate TPS peaks at $N{=}8$ (+40\% over $N{=}1$) then reverses, with per-shard TPS collapsing 23$\times$ by $N{=}24$. Our dataset provides the first commodity-hardware calibration baseline for the companion SimPy sharding simulator.