# Release: Zakura 1.2.0, 87% faster full block processing

Announcement dated 2026-08-14 for Zakura 1.2.0, a performance release focused
on orphan rates.

What the announcement says:

- All node operators should update. Mining pools benefit the most because the
  removed work directly affects miner revenue.
- Since `zcashd` reached end of support, the network has seen elevated orphan
  rates. This release removes the largest cause the team found: nodes were
  performing redundant proof verification during block acceptance.
  On full Ironwood blocks with regular
  transactions, block processing time on the team's benchmark machines drops
  from 2.5 seconds to 0.32 seconds, nearly a 5% reduction in wasted work for
  median block times.
- Background: the team profiled orphan rates on Zebra 4.3.0 months ago
  (https://x.com/evansforbes/status/2051350281967870267). Mainnet was around
  0.1%, and their simulated, far more decentralized testnet was around 1%.
  Since `zcashd` reached end of support, outlier block times increased with far
  more 10+ minute blocks than statistically expected, and on July 31st the
  network's orphan rate reached nearly 1%, against an old 0.1% to 0.2%
  baseline. First fixes patched peer connectivity and removed disconnects on
  slow blocks, reducing the initial spikes, but the baseline orphan rate
  settled around 0.3% with spikes to 1% on days with many quarter-filled
  blocks.
- Re-running the analysis on Zakura showed orphan rates of 3.2% with 75-second
  blocks and 42% with 20-second blocks. The cause: every proof was
  verified twice, once when the transaction arrived over mempool gossip and
  again when it arrived inside the block that included it, slowing block
  processing and the miner's switch to the new block.
- Zebra used to avoid the duplication with a proof-check cache. It was removed
  in Zebra 4.3.1 (https://github.com/ZcashFoundation/zebra/pull/10494) as part
  of a critical security fix
  (https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-3vmh-33xr-9cqh):
  the old cache stored the verdict `valid(transaction, height, block time,
  spent outputs)` under a key that did not determine that proposition.
- Zakura 1.2.0 instead caches the stateless proof verification itself rather
  than the verdict. Verifying a single Halo2 item against a verifying key is a
  pure function of its inputs, so a cache hit is bit-identical to the
  computation it replaces. Nothing else is skipped: on a cache hit,
  transaction verification still runs end to end at the block's own height,
  with the block's time and the block's spent outputs, and the cache key
  commits to the full transaction, so a malleated transaction cannot reuse a
  cache hit. The change is https://github.com/zakura-core/zakura/pull/597; it
  moves the duplicated work out of the critical path between receiving a block
  and updating the miner's block template.
- Benchmarks: in the team's globally distributed full block experiments (an
  internal testnet of 77 to 80 nodes with CPU miners and deliberately
  compressed block-time bands, so the absolute numbers describe that
  environment, not Mainnet), the orphan rate in the 25-second band fell from
  roughly 30% to about 3.6%, and the 75-second band measured 1.57%. More CPU
  improvements are planned.
- New metrics: `zakura.consensus.halo2.cache.hit`, `miss`, `insert`, and
  `evict` counters and the `zakura.consensus.halo2.cache.size` gauge.
- A new indexer gRPC `GetBlockRange` call (proposed and contributed by
  @maxdesalle) streams a height range of finalized blocks in ascending order,
  served from the stored raw bytes. It replaces one unary `GetBlock` per
  block, which fully deserialized every transaction and re-serialized the
  block. The stream covers only blocks committed to the finalized state and
  ends at the finalized tip. Serving block ranges requires building with the
  `indexer` compile-time feature.
- Security: mutual TLS is now required for indexer RPC listeners on
  non-loopback addresses, indexer connections and streams are bounded, blocks
  without a coinbase height are rejected before state preparation, and Zakura
  protocol services now enforce their declared frame caps for inbound and
  outbound application frames rather than declaring them and accepting larger
  ones.
- Other improvements: block work and cumulative chain work are now stored at
  their full 256-bit width, so valid hard targets are representable instead of
  failing conversion (fork choice and the committed chain history root are
  unchanged for Mainnet and Testnet, and no database migration is required).
  The maximum-block-time activation height is now a per-network parameter:
  configured networks and Regtest activate the MTP-plus-90-minutes rule at
  height 2, generated local networks activate it after their seed chain, and
  Regtest accepts a `max_block_time_start_height` config field. Mainnet and
  public Testnet behavior is unchanged.
- End of support: Zakura 1.2.0 keeps the 40-day window introduced in 1.1.1.
  Mainnet nodes running this release halt at height 3,495,707 (~2026-09-23);
  upgrade warnings begin ~2026-09-20.
- Update using signed release binaries or the `zakura` crate 1.2.0.
  Installation and verification instructions are at
  https://zakura.com/download/.

---

Canonical HTML version: https://zakura.com/announcements/zakura-1-2-0-orphan-rate/