# Testing 25-Second Blocks for NU7

Engineering post dated 2026-08-23 about an 80-node, equal-hashpower Zakura stressnet
that mined full 2MB blocks with 25-second target spacing. The experiment
distributed the nodes evenly across 11 regions.

What the post says:

- Zakura's team is proposing to reduce Zcash's block spacing to 25 seconds in
  NU7, down from 75 seconds today. The proposal is ZIP 218
  (https://zips.z.cash/zip-0218). The post says tripling the rate of block
  production would only be a security risk for the network if it increased
  the rate of orphan blocks.
- An earlier 100-node Zebra stressnet measured a 4.86% orphan rate at 25-second
  spacing under deliberately adverse conditions. The 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) and measured a 3.43% orphan
  rate. The stressnet's mining topology is far more geographically distributed
  than Mainnet's.
- The two experiments were not a controlled A/B test, and their 95% Wilson
  confidence intervals overlap.
- For comparison, the same stressnet mining full blocks at the current 75-second
  spacing measured a 1.57% orphan rate, and recent data shows 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.
  The post expects
  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
  2026.
- Orphan rate matters because every other miner keeps working on the previous
  tip until its node receives a new block, verifies it, and builds a new
  mining template. Stale work consumes hash power, and a shorter target
  spacing makes every delay a larger share of the interval between blocks, so
  NU7 needs node software changes, not just a parameter change.
- The experiments did more than measure the final orphan rate; they showed
  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.
  Re-measuring before Zakura 1.2.0 surprised the team: orphan rates had
  increased significantly since the first experiment.
- Zebra 4.3.0's optimization returned a cached mempool result when a block
  contained a transaction the mempool had already accepted. It had a critical
  soundness bug (the cache stored more than the validity of the stateless
  checks), and the fix that shipped
  in Zebra 4.3.1 (PR #10494) 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.
- Zakura does not restore the old shortcut. Since 1.2.0 it has cached the
  stateless components of shielded bundle verification. A cache hit skips 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 subsequent Zakura Common
  work improved these numbers further. Verification is no longer on a
  block's critical path.
- Both 25-second experiments set `net.ipv4.tcp_slow_start_after_idle=0` so
  Linux retained each peer connection's congestion window between blocks.
  Zebra now warns operators about this setting.
- Beyond standard speedups, the new experiment included several Zakura
  changes that further shorten the path to a new mining template, in
  particular un-merged Zakura PR #748 (nodes advertise a newly admitted mined
  block earlier) and PR #754 (nodes serve the cached block body while its
  commit continues).
- The experiment's CPU miners gained safe cancellation points from Zakura
  PR #643 and draft librustzcash PR #75, so stale solver work stops when the
  chain tip changes. CPU miners solve much more slowly than production ASIC
  or GPU miners, so the cancellation keeps the test harness from inflating
  the orphan rate. The external mining path used by production ASIC miners is
  unchanged.
- The earlier stressnet's analysis models expected orphan blocks per accepted
  block as `phi = tau_eff / T`. The new run found 22 orphan blocks and 619
  accepted blocks, giving `phi` of 3.55%. At the observed mean spacing of 25.3
  seconds, the point estimate implies an effective stale-work window of about
  0.90 seconds and places the 5% boundary at 18 seconds.
- The 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 final collection contains all 80 nodes, and the canonical walk covers
  922 heights across them. The linked data and analysis scripts reproduce the
  3.43% result and include the 1.57% result from the earlier 75-second
  experiment.

The post concludes that the result supports 25-second spacing, with the point
estimate well below the 5% boundary in an environment more adverse than
Mainnet, and that node performance work should remove avoidable delay before
the consensus parameter changes.

---

Canonical HTML version: https://zakura.com/engineering/25-second-block-time-update/