zakura

Release: Zakura 1.0.5

We have released Zakura 1.0.5, a stability and performance release. It significantly improves restoration of p2p connectivity after long blocks, fixes two failures that could prevent a fresh node from syncing, improves peer discovery, and significantly reduces CPU overhead in address-book and metrics processing.

We recommend that all node operators update.

This release also mitigates an issue discovered yesterday on Testnet that affects both Zakura and Zebra. We identified a bug that prevents nodes from reconnecting to honest peers after a large chain reorganization. After discussion with the Zcash Foundation, both of our teams agreed to fix the issue in parallel releases ahead of the NU6.3 network upgrade.

Peer discovery and recovery

Zakura's default P2P stack now recovers more deliberately when its peer set becomes depleted:

  • Periodic crawls replenish outbound connections. When fewer than 27% of the configured outbound connection slots are active, Zakura queues enough connection attempts to reach that target while still respecting the configured hard limit.
  • Liveness stall detection waits longer. The threshold at which stall tracking begins—and peers can consequently be disconnected—rises from Zebra's 6 minutes to 20 minutes. We believe this will help reduce the frequency of very high-latency Mainnet blocks.
  • Peer discovery returns a larger sample. Refreshed GetAddr responses now contain approximately half of the eligible address book instead of one quarter, still capped at 1,000 addresses and protected by the existing ten-minute response cache.
  • Bans remove every address for the affected IP. A peer can advertise multiple ports for one canonical IP. Banning that peer now removes every matching address-book entry so stale aliases cannot interfere with later connection management.

Fresh-sync reliability

This release fixes two independent failures in the path from genesis to the network tip:

  • Verified-commitment-tree fast sync completes its handoff. At the exact handoff height, the header-authentication lane cannot produce a database row for the Sapling, Orchard, and Ironwood roots. The commit path now uses the reviewed roots embedded in the release at that height. Heights below the handoff still require authenticated database roots, and heights above it cannot use the embedded data.
  • Legacy genesis sync no longer livelocks under ordinary peer-set saturation. Zakura 1.0.4 attempted to route historical block downloads only to peers advertising the full chain. This had a live-lock, and is removed in v1.0.5. We will re-introduce this with more fixes in a subsequent release.

Address book and performance

We identified the address book and its related metrics as performance bottlenecks through several independent signals. Live profiles indicated that nodes with metrics disabled still spent 30% of their CPU time in metrics code. The address book also contained ordering errors and several O(N) operations. We found timeouts and sleeps delaying time-sensitive work that appeared to exist only to avoid contention while these operations held locks.

  • The address-book get, update, and ban operations are now O(log(N)) or O(1). We now maintain direct address, priority, and per-IP indexes. Batched address changes also publish metrics once per batch instead of rebuilding the same summary after every accepted entry.
  • Fix metrics growth from disconnected peers. The zakura.net.connection.state Prometheus gauge is now aggregated by command rather than carrying a per-peer addr label. Previously, disconnected peers left zero-valued time series behind indefinitely, allowing /metrics and Prometheus cardinality to grow throughout long syncs. Operators whose dashboards query this gauge by addr should update those queries.

Other improvements

  • Mined blocks are not advertised twice when gossip events race. A completed or newly submitted mined-block event now takes priority over the committed-tip fallback when both are ready.
  • Public mempool testing tools. We added a load-testing harness for Mainnet and Testnet that verifies transactions gossip correctly.

End-of-support halt

Zakura 1.0.5 retains the 1.0.4 support window. It supports Ironwood (NU6.3) activation and reaches end of support roughly eleven days afterward, by which point the first post-Ironwood release will be available.

The first post-Ironwood release will have a substantially longer EOS.

Updating

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