zakura

Release: Zakura 1.0.3

We have released Zakura 1.0.3, a security and stability release. It marks the zcashd compatibility mode as stable for the Ironwood (NU6.3) network upgrade. It also addresses some security issues, continues to harden the inherited P2P stack, and fixes edge cases in mempool behavior.

All node operators should update both their Zakura and zcashd compatibility binaries.

zcashd compatibility mode

As with our last release, this release fixes several bugs in zcashd compatibility mode, thanks to battle-testing from partners. Most importantly, the managed zcashd process could previously fail to follow the NU6.3 network upgrade on mainnet even though the underlying zakura process did, leaving the zcashd wallet stalled.

After extensive compatibility and network-upgrade testing, Zakura 1.0.3 pins valargroup/zcashd 1.1.0 for both managed installations and the split-container Docker image, and we now consider the compatibility mode stable and ready for Ironwood.

P2P, mempool, and sync hardening

We continue to harden the legacy P2P stack inherited from Zebra, which remains the default networking path for live consensus nodes:

  • Peer banning is now O(1). Adding and evicting retained bans previously became more expensive as the ban list filled, because each operation copied or shifted the existing list. Membership checks, insertions, and evictions now take constant time.
  • Equivalent IP representations can no longer bypass enforcement. IPv4 and IPv4-mapped IPv6 addresses are now treated as the same peer when applying bans, inbound rate limits, and per-IP connection limits.
  • Malformed block-discovery responses no longer disrupt sync. There were several ways a peer could reply with hashes that would disrupt the node's active sync attempt. These responses are now rejected.

This release also fixes two cases where the mempool and outbound gossip state could disagree:

  • Mempool gossip no longer silently drops legitimate transactions. When the mempool was at capacity, valid transactions could be silently dropped from outbound gossip and never announced to peers. The gossip flow no longer permanently omits them when it falls behind.
  • The mempool no longer gossips transactions whose parents were removed. When an expired transaction caused its descendants to be removed, only the directly expired transaction was previously reported to the gossip layer. All removed descendants are now cleared from pending gossip as well.

We also harden consensus state and syncing behavior:

  • Corrupt history-tree caches now fail closed. Malformed bytes, caches from the wrong network, and invalid caches that are empty or predate Heartwood now produce clean errors instead of crashing the node. The valid database format is unchanged.
  • Mainnet checkpoints are updated, and refreshing them is now automated. Zakura 1.0.3 extends checkpoint sync from height 3,358,006 to 3,418,406. Checkpoint and verified-commitment-tree frontier refreshes now run through an automated pipeline: an offline export produces a provenance record that CI verifies, refreshed data is checked against its expected digests before landing in reviewable draft pull requests, and pre-release checks confirm that checkpoints, frontiers, and provenance stay consistent.

Security (GHSA-x93j-mj2f-q338)

In coordination with the Zcash Foundation, Zakura 1.0.3 extends the hardening for GHSA-x93j-mj2f-q338 that shipped in 1.0.2. Rejected non-finalized block hashes are now drained before known-block checks, allowing an honest block body with the same hash to be retried immediately instead of waiting for another state request to process the rejection.

The issue allowed a remote, unauthenticated peer that won a block-propagation race to deliver a rejected block body sharing its header hash with a valid block. A stale rejection could then prevent the valid block's children from being accepted, stalling the node for roughly 2,000 blocks. The issue could not cause a crash, state corruption, consensus divergence, or acceptance of an invalid chain.

During this release cycle we built a hotfix release path, rehearsed it against private staging infrastructure, and hardened the checklist and process documentation that a security release follows.

Security (GHSA-2p4c-3q4q-p463)

GHSA-2p4c-3q4q-p463 was reported to the Zcash Foundation by craftsoldier. Zakura had already mitigated the reported issues in 1.0.2.

The report found that Zebra's mempool exposed nodes to a denial-of-service attack involving transactions as large as 2 MB, and that peers were not banned in many real-world error paths. An attacker could repeatedly submit transactions containing large numbers of invalid Orchard proofs. When batch verification failed, the verifier entered a slow path that checked each proof individually, causing substantial CPU load. Because the offending peer was not banned, the attacker could sustain this load and delay block processing.

Zakura proactively addressed these issues as part of the mempool-hardening work released in 1.0.2. Among other changes, Zakura now bans peers that submit invalid Orchard proofs and rejects transactions larger than a configurable limit (250,000 bytes by default) from the mempool.

RPC and indexer reliability

Zakura deployments can run a separate read-only database for RPC and indexing. This release closes several synchronization races in that path: subscriptions resume from the read-only database's known chain tips, streamed blocks use bounded backpressure instead of being dropped, and a lagging read-only instance can fetch the finalized blocks needed to bridge a gap. Catch-up handoffs, retries, and stream timeouts are also bounded, so RPC availability recovers cleanly after restarts or delays.

Verbose block-header metadata now stays bound to the block that was originally resolved, even if the best chain reorganizes during the request.

This release also cleans up user-facing text: getrawtransaction now reports Transaction not found in mempool or best chain, and remaining references to Zebra in logs, errors, RPC responses, CLI help, and operator tooling now say Zakura. We thank @dismad for suggesting the clearer RPC wording and @ambimorph for reporting the stale branding.

Other improvements

  • disable_pow now applies to native header sync. Header sync now honors disable_pow = true on configured testnets, matching the block-verification paths that already honored it.
  • The zakura-chain public API is slimmer. Unused public errors, constants, and helper methods have been removed to keep the library API focused. This is a breaking change for crate consumers; it does not affect node operators.
  • Transaction digests are faster. Fixed ZIP-244 hashes for absent transaction bundles are now cached. In an Ironwood-only benchmark, computing the authorizing-data digest was 2.8% faster, and computing the transaction ID and authorizing-data digest together was 5.6% faster.
  • Tests are more deterministic. Acceptance tests now wait for observable readiness instead of fixed sleeps, removing avoidable test latency, and zakurad test binaries no longer hit a log-capture race that could corrupt tracing span bookkeeping.
  • Header sync groundwork continues. We added a specification for a fork-aware header chain engine, preparing for the next stage of native header sync.

End-of-support halt

Zakura 1.0.3 supports Ironwood (NU6.3) activation and reaches end of support roughly eleven days after it, by which point the first post-Ironwood release will be available.

Updating

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