zakura

Release: Zakura 1.4.0

We have released Zakura 1.4.0, a performance release. We published 1.3.1 and 1.3.2 without blogging about them at the time; this post covers their changes as well.

This release reduces block propagation latency for miners, improves polling latency for lightwalletd operators, and continues improving the experimental P2Pv2 stack. It also updates to Zakura Common 1.2.0, reducing shielded coinbase proving latency enough for mining pools to use it in block templates.

We recommend that all node operators update. Miners and lightwalletd operators benefit the most.

21× Faster Mobile Proving

This release includes Zakura Common 1.2.0, which delivers significant further improvements to mobile proving times, benchmarked across several phones.

The net impact is that proving on an iPhone 17 is now 21 times faster than it was before Zakura. For context, the Sprout-to-Sapling transition brought a 5.3x proving speedup. This improvement is four times as large, measured on real devices.

Shortly after our initial release of Common, users on older devices reached out about benchmarks. We've now added several older phones to our benchmark suite. Cold proving latency across the devices we tested is now:

  • iPhone 17 (2025): 3 s to 142 ms (21x faster)
  • Galaxy S25 (2025): 4.7 s to 173 ms (26x faster)
  • Pixel 7 (2022): 10.5 s to 550 ms (19x faster)
  • iPhone 8 (2017): 8.6 s to 360 ms (23.8x faster)

These proving times also make shielded coinbase mining far more competitive; the latency that previously made it impractical continues to fall with each Common release. We continue to invite wallets to switch to our wallet libraries (see zakura-core/wallet-libraries and zakura-core/common, which it depends on) so they can benefit from the performance improvements on today's Zcash network.

Unique Problems in Mobile Proving

Early in the development of Zakura Common we noticed that a 15% prover speedup on desktop translated into only a 3% speedup on mobile. The cause was a cold-CPU problem on iPhones: the first few proving phases ran six times slower on a cold CPU than on a warm one, while warm-CPU proving tracked desktop closely. The beginning of a two-action proof involved single- or two-threaded work with high memory traffic, leaving most of the phone's cores idle exactly when the proof started.

The challenge was to use those cores as efficiently as possible from the start: parallelize more of the early work or remove it from the critical path. We changed how we commit to and transform the public input, reduced algebra and memory traffic while creating ZKP witnesses, and cached duplicated circuit-construction work in the proving keys. Together, these changes reduced CPU warmup time by about 12 ms on the iPhone 17, a significant part of the nearly 30% proving speedup since Common 1.0.0. The cold-start penalty has fallen to 28 ms, about 25% of proving time, and work remains to saturate every core as early as possible on phones.

Faster Block Propagation

Miners now begin their final block verification check as soon as they create a block template, and a submitted block reuses the prepared work of the template it came from. Once they mine a block, Zakura advertises its availability as soon as expected-work validation and state admission succeed, instead of waiting for the final local verification path. The caching we shipped in 1.2.0 substantially reduced this work, and 1.4.0 removes it from the propagation-critical path entirely.

This faster path is guarded carefully:

  • Rejected templates are withdrawn. Zakura withdraws rejected mining templates, stops the affected internal mining work, and validates empty-template recovery before returning a replacement.
  • Submissions are bounded. Mined submissions and contextual writes are bounded, and a mined block that must wait for its parent or for verification capacity returns inconclusive.
  • Relay waits when the tip can still move. Optimistic relay is blocked while earlier contextual writes or operator changes can move the selected tip.
  • Blocks are not advertised twice. Zakura avoids duplicate all-peer inventory delivery.

Operators can use the recently added block-gossip metrics to see whether legacy TCP or Zakura's native P2P stack first delivered each complete block body (the source label on sync.block.first_received.count, added in 1.3.2) and to track how long blocks spend in verification.

Faster lightwalletd Polling

The getblockchaininfo query is also significantly faster; it now reuses the periodic database disk-size measurement. lightwalletd calls it as part of GetLatestBlock, and operators report that its p95 latency has dropped from 24 ms to 0.28 ms, a roughly 86x improvement. This reduces end-to-end GetLatestBlock p95 latency from 25 ms to 6 ms, an improvement of more than 4x.

P2Pv2 Improvements

Our experimental P2Pv2 stack received another reliability pass across these releases:

  • Checkpoint catch-up handles large gaps better. Header sync repairs contiguous ranges of missing verified-commitment-tree roots in one request, checkpoint commits resume immediately after a header-chain commit instead of polling on a timer, and a parked checkpoint clears its own resource-stall alarm instead of waiting for an insertion the alarm would refuse. The stalled-height diagnostic now measures a parked block's complete wait, so a changing missing height no longer postpones the operator error.
  • Repair suppliers are managed more strictly. Header sync no longer admits verified-commitment-tree data that durable state already retains or has rejected, rotates suppliers after peer-attributed failures, and charges a supplier that withholds its response like any other timed-out peer, without ending the scheduling round for the remaining candidates. Retention also frees admission capacity before delivery limits are enforced.
  • Block sync recovers from more failure modes. Peer serving and misbehavior-report traffic no longer consume the capacity reserved for needed-body refill recovery, invalid-body evidence and retry state are preserved until persistence accepts them, and failed needed-body state queries are retried through action-queue contention. If the critical block-sync driver ever exits unexpectedly, the node now stops instead of leaving native services running without block application.

Security

  • Administrative RPCs require an authenticated listener. Administrative RPC methods on Mainnet and Testnet are restricted to authenticated listeners, and remain available through an optional rpc.admin_listen_addr loopback listener. The unauthenticated listener remains intended for protected downstream connectivity, not arbitrary Internet traffic.
  • Chain value pools are checked in combination. We added a check on the combined chain value-pool balance as defence in depth.
  • Dependency hygiene. The yanked transitive chacha20 0.10.1 dependency is replaced with 0.10.2, whose SSE2 backend no longer emits an SSE4.1 instruction that crashes zakurad on x86 CPUs without SSE4.1 support.

Other Improvements

  • Transparent-heavy transactions verify faster. UTXO lookups during block verification of transactions with many transparent inputs no longer wait on each other serially; the verifier overlaps responses while preserving state responsiveness.
  • Legacy sync preserves checkpoint work. Temporary tip refresh timeouts no longer discard checkpoint progress during legacy synchronization.
  • End-of-support visibility. Metrics, dashboards, and alerts now cover the Mainnet end-of-support schedule.
  • The minimum supported Rust version is now 1.97 for zakurad and the internal crates.

End of Support

Mainnet zakurad nodes running 1.4.0 halt at height 3,504,731 (estimated 2026-10-03), the same halt height and date as 1.3.2; upgrade warnings begin three days earlier.

Updating

You can update using our signed release binaries or by upgrading the zakura crate to 1.4.0 via Cargo. See the download page for installation and verification instructions.