The experiment began with a practical question: could researchers test a blockchain’s scaling claims without renting a small cloud’s worth of computing power? It ended with a stranger puzzle. In one test, moving the software’s database off a hard drive and into memory didn’t just fail to make the system faster. At one shard count, the chain stopped.
The system was NEAR Protocol’s Nightshade, which divides blockchain work among smaller groups called shards. In principle, more shards mean more work can happen at once. But a blockchain cannot simply let each group go its own way: the network must check that transactions are valid and agree on the order of events. The challenge is to gain parallel speed without losing coordination.
To investigate, Sohini Sahukar, Om Amit Gandhi, and Ioan Raicu ran the software on one bare-metal server with 48 hyperthreaded Intel Xeon cores, 128 GB of RAM, and a hard drive. They ran from one shard to 24, with each validator process sharing the same machine. After a 30-second ramp-up, each run was measured for 180 seconds. This was a test of a particular software version and setup—not a measurement of how the live network performs.
The first clue was a curve that bent the wrong way. With one shard, the test reached 1,070 transactions per second. At eight shards, it reached 1,498—40% more. But at 16, throughput fell to 1,204, and at 24 it was 1,110. More strikingly, throughput per shard dropped from 1,070 at one shard to 46 at 24. The extra lanes helped, until the work of keeping them in step began to outweigh the benefit.
Why? Each shard produces a “witness”: evidence that its part of the blockchain changed according to the rules. Other validators need to receive and check that evidence before a block can be finalized. So adding shards also adds messages and coordination. The authors found that, at medium shard counts, sending and checking witnesses took about 600 ms per chunk, regardless of storage speed. At high counts, the system struggled to keep witnesses in sync with the blocks they depended on.
One suspect seemed obvious: the hard drive. If storage was slowing everything down, replacing it with something faster should help. The researchers moved the database to tmpfs, which uses RAM rather than disk. The result was a mixed clue. At four shards, throughput improved by 12%; at eight, by 25%. Those gains suggested storage could matter, but they were modest—and the most dramatic result pointed in the opposite direction.
At 16 shards, the RAM-backed test stalled: throughput fell to zero. The CPU was at 47%, not fully occupied. Meanwhile, the rate of “orphan” witnesses—evidence arriving before the parent block it belonged to had finalized—spiked 29-fold. The hard drive, apparently a drag on performance, had been slowing parts of the system in a useful way.
The authors’ explanation is that disk-write delays were acting as an unintended brake. With that brake in place, chunk production was paced more closely to block finalization. When the delay disappeared, witnesses could race ahead of their parent blocks. Orphaned witnesses then triggered retries and more gossip, adding traffic to a system already struggling to coordinate. In their account, that feedback loop tipped the chain into a stall.
That explanation fits the clues, but it is not the last word. The test put all validators on one machine, with a local network connection; real validators communicate across a network. Moving the database into RAM also changes more than disk latency: it changes how the workload interacts with shared memory and other resources. The paper proposes follow-up tests on multiple machines and with deliberately added network delay to find out whether the same hidden brake appears there. So the result is a warning about this setup, not proof that faster storage generally harms blockchains.
The broader puzzle is how systems behave when several processes must agree on a shared timeline. More parallel workers can mean more coordination, and a delay that looks wasteful may accidentally keep that coordination stable. The researchers’ scaling test found its best throughput at eight shards, but even there, measured time to full finality was 77.5 seconds. Their findings point toward a more deliberate fix: build flow control into the protocol, rather than relying on a hard drive to provide it by accident.
