Testing 25-Second Blocks for NU7

We are proposing to reduce Zcash's block spacing to 25 seconds in NU7, down from 75 seconds today. Tripling the rate of block production would only be a security risk for the network if it increased the rate of orphan blocks. Our earlier 100-node Zebra stressnet measured a 4.86% orphan rate at 25-second spacing under deliberately adverse conditions.

We built a new stressnet to measure where Zakura stands now.

This new 80-node Zakura stressnet reproduced the same conditions: every block filled with 2MB of shielded transactions, and equal-hashpower miners spread evenly across 11 regions, including Singapore and Australia. That mining topology is far more geographically distributed than Mainnet!

The new run measured a 3.43% orphan rate.

For comparison, the same stressnet mining full blocks at the current 75-second spacing measured a 1.57% orphan rate, and recent data shows that Zakura has reduced Mainnet's live orphan rate to 0.085%. Mainnet's mining is far more geographically concentrated and its blocks far emptier than the stressnet's, so we expect Mainnet's orphan rate to stay under 1% after the change to 25-second blocks, even at full blocks. Mainnet itself ran near 1% as recently as July.

Why Orphan Rate Matters for NU7

When one miner finds a block, every other miner keeps working on the previous tip until their own node receives the new block, verifies it, and builds a new mining template. Work performed during that delay uses a stale template. Most of that work never finds a block but still consumes hash power, and when it does find one, the resulting block competes with a block that already had a head start.

Shorter target spacing makes every delay a larger share of the interval between blocks. NU7 therefore needs more than a parameter change: the node software must shorten the path from receiving a block to giving miners new work.

Orphan Rates Exposed Repeated Verification

Our experiments did more than measure the final orphan rate. They showed us where Zakura spent its time maintaining consensus.

The first 100-node experiment ran Zebra 4.3.0, and Zakura is a fork of Zebra 5.0.0. When we re-measured before our 1.2.0 release, we were surprised to discover that orphan rates had increased significantly since the first experiment.

It turns out that Zebra 4.3.0 had an optimization that returned a cached mempool result when a block contained a transaction the mempool had already accepted. The optimization had a critical soundness bug: the cache stored more than the validity of the stateless checks. The fix, PR #10494, shipped in Zebra 4.3.1 and removed the caching.

Removing the optimization made nodes verify the same shielded proofs and signatures twice: once when a transaction entered the mempool, and again, where latency matters more, when a block arrived that mined it.

Cache the Result That Does Not Change

Zakura does not restore the old shortcut. Since 1.2.0, it caches the stateless components of shielded bundle verification. Each cache entry records only that this exact shielded bundle verified, with this signature hash, against this circuit's verifying key.

Cache hits skip only the repeated proof and signature work. Everything that depends on block height, chain state, or time is checked again, and a transaction with different proofs or signatures gets a different cache key.

The cache cuts median transaction verification time from 50.0 milliseconds to 1.8 milliseconds, and total block verification time across gossip hops from 89.5 milliseconds to 38.0 milliseconds. The Zakura Common work has since improved these numbers further. Verification is no longer on a block's critical path.

The Rest of the 25-Second Stack

Both 25-second experiments set net.ipv4.tcp_slow_start_after_idle=0. This setting stops Linux from resetting a peer connection's congestion window during the quiet interval between blocks, so the next large block can use the window the connection already built. Zebra now warns operators about this setting.

The new experiment also included several Zakura changes that further shorten the path to a new mining template, beyond standard speedups. In particular, the un-merged PR #748 advertises a newly admitted mined block earlier, and PR #754 serves the cached block body while its commit continues.

We also changed the experiment's CPU miners to stop stale solver work. CPU miners solve much more slowly than production ASIC or GPU miners, so one solver pass can continue long after the chain tip changes. Zakura PR #643 and draft librustzcash PR #75 add safe cancellation points, which keep the test harness from inflating the orphan rate. The external mining path used by production ASIC miners is unchanged.

What the Result Means for NU7

The earlier stressnet's analysis models expected orphan blocks per accepted block as

where is the effective time that miners keep working on the old tip and is the target spacing.

The new run found 22 orphan blocks and 619 accepted blocks. In the model's units, is 3.55%. The observed mean spacing was 25.3 seconds. These values imply an effective stale-work window of about 0.90 seconds.

The same point estimate places the 5% boundary at 18 seconds.

That 18-second figure is not a deployment limit. The measured orphan rate has a 95% Wilson interval of 2.28% to 5.14%, and Mainnet's orphan rate will also depend on its real network topology, miner behavior, block contents, and software adoption.

The result supports 25-second spacing, with the point estimate well below the 5% boundary in an environment more adverse than Mainnet. It also shows why NU7 performance work belongs in the node implementation: a shorter target spacing works best when the network removes avoidable delay before the consensus parameter changes.

Data

The final collection contains all 80 nodes, and the canonical walk covers 922 heights across them. The data and analysis scripts reproduce the 3.43% result and include the 1.57% result from the earlier 75-second experiment.