zakura

Release: Zakura 1.0.4

We have released Zakura 1.0.4, a performance and stability release. Typical blocks now verify about 20% faster. This release also fixes bugs in the experimental P2P v2 stack, including authentication of verified-commitment-tree (VCT) fast-sync data. We also harden the default P2P networking code like in our previous two releases.

We recommend that miners and RPC operators update to take advantage of these significant performance improvements.

Faster block execution

Zakura verifies signatures and proofs in batches. Near the chain tip, a partially filled batch often waited for a 100 ms timer before its cryptographic work could begin. We now immediately process these batches at block boundaries, while retaining the existing size and time triggers and leaving mempool batching unchanged.

In a mainnet block-processing experiment, steady-state latency fell from 681 to 591 ms per block, saving about 90 ms. This roughly 20% improvement applies to live sync as well as catch-up, with no measurable regression when verifying blocks concurrently.

P2P v2 authentication and reliability

This release contains the largest reliability pass on Zakura's experimental P2P v2 stack since launch:

  • VCT fast-sync data is now authenticated. During checkpoint sync in the P2P v2 stack, we use additional data committed in block N+1's header to authenticate the commitment-tree data needed to execute block N. We now authenticate that additional data in the P2P layer. This prevents a malicious peer from stalling P2P v2 checkpoint sync with incorrect data. Cached data written under the previous rules is refreshed automatically during the upgrade.
  • Connections recover after temporary failures. Healthy peers can reopen block sync, header sync, discovery, and legacy-gossip services after cooldowns instead of remaining unusable until they reconnect. Closing an old service session can also no longer disconnect a newer session on the same peer connection.
  • Peer discovery finds new v2 nodes faster. Zakura now advertises usable addresses, safely connects to peers learned through discovery, refreshes their records, and discards them when they expire.
  • Block sync recovers missing downloads. If a block falls out of the download queue while later blocks are still pending, Zakura requests it again instead of buffering later blocks indefinitely and stalling sync.

P2P and sync hardening

The inherited P2P stack remains the default networking path for live consensus nodes. Zakura 1.0.4 further hardens it against malformed responses and difficult network conditions:

  • Malformed chain extensions no longer disrupt sync. Legacy chain sync rejects peers that echo the requested block locator inside their advertised extension.
  • Duplicate blocks no longer leave checkpoint sync with a permanent stall. A normal resubmission of an already queued block can no longer trigger a stale verifier reset after completed blocks have left the queue.
  • Historical sync avoids pruned peers. Block requests prefer peers that advertise the full chain, reducing delays from asking pruned peers for bodies they are unlikely to retain. We remain connected to pruned nodes during live sync. This was already handled in P2P v2 and is now also handled in legacy P2P.
  • Local zcashd sidecars connect reliably under inbound load. A sidecar could previously time out while waiting behind a large queue of public connections. Zakura now accepts queued connections in bounded, faster bursts and begins configured sidecar handshakes immediately, while retaining rate limits for public peers.

Other improvements

  • Faster Orchard and Ironwood block template refreshes. Like the Sapling prover in 1.0.2, the Orchard and Ironwood proving keys used for shielded coinbase transactions are now prepared once per process and reused, instead of being recomputed for every getblocktemplate refresh.
  • CI is substantially faster. In representative runs, a merge to main uses roughly one-seventh as many runner-minutes and completes about three times faster. A pull request uses about 30% fewer runner-minutes and completes roughly three times faster. Final release builds run five times faster.
  • The experimental Elasticsearch exporter is removed. External service behavior no longer runs inside the finalized-state commit path. Operators who used the exporter should contact the Zakura maintainers so we can prioritize a safer indexing API around their requirements.
  • Unused binaries are removed. The block-template-to-proposal and search-issue-refs binaries and their runtime dependencies are gone. The supported zakura-checkpoints tool remains.
  • Rust crate APIs now enforce authenticated VCT data. This is a breaking change for crate consumers: zakura-chain moves to 3.0.0, while zakura-network and zakura-state move to 5.0.0. Removing the developer binaries moves zakura-utils to 2.0.0. These changes do not affect node operators.

End-of-support halt

Zakura 1.0.4 retains the 1.0.3 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.4 via Cargo. See the download page for installation and verification instructions.