Release: Zakura 1.0.3

We have released Zakura 1.0.3, a security and stability release. This release officially marks the zcashd compatibility mode as stable for the Ironwood (NU6.3) network upgrade thanks to extensive testing and feedback. We also address some security issues, continue to harden the inherited P2P stack, and fix edge cases in mempool behavior.

It is recommended that all users update both their Zakura and zcashd compatibility binaries.

zcashd compatibility mode

As with our last release, we fixed several bugs in zcashd compatibility mode, thanks to battle-testing from partners. Most importantly, the zcashd wrapper was not following the NU6.3 network upgrade on Mainnet even though the underlying zakura process was, which could lead to the zcashd wallet stalling. This has been addressed.

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 image. We now consider the zcashd compatibility mode stable and ready for the NU6.3 network upgrade.

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 list filled, because each operation copied or shifted the existing list. Zakura now uses constant-time membership, insertion, and eviction.
• 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 are rejected earlier. There were several ways a peer could communicate hashes that would disrupt the node's active sync attempt. These responses are now discarded.

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

• Mempool gossip silently drops legitimate txs. Previously, the mempool at capacity would silently drop txs. Now the gossip flow has been adapted to fix this, so valid transactions are not permanently ommitted when the consumer falls behind.
• Mempool no longer gossips missing-parent transactions. 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.

This release also hardens consensus state and syncing behavior:

• Corrupt history-tree snapshots now fail closed. Malformed bytes, wrong-network snapshots, and invalid empty or pre-Heartwood caches now return typed local-state errors instead of reaching assertions or panicking. The valid database format is unchanged.
• Mainnet checkpoints are updated, and refreshing them is now automated. Zakura 1.0.3 extends the 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 mode produces a provenance record that CI verifies, refreshed data is imported from digest-verified publisher bundles into reviewable draft pull requests, and our pre-release checks confirm that checkpoints, frontiers, and provenance remain coupled.

Security (GHSA-x93j-mj2f-q338)

In coordination with the Zcash Foundation, Zakura 1.0.3 adds additional hardening for GHSA-x93j-mj2f-q338 beyond what shipped in 1.0.2. Rejected non-finalized block hashes are now drained before known-block checks, allowing an honest same-hash block body 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)

This security report was submitted by craftsoldier to the Zcash Foundation. Zakura had already mitigated the reported issues in v1.0.2.

GHSA-2p4c-3q4q-p463

The report found that Zebra's mempool exposed nodes to a denial-of-service attack involving transactions as large as 2 MB and failed to ban peers 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 v1.0.2. Among other changes, it now bans peers that submit invalid Orchard proofs and imposes a configurable transaction-size limit for mempool admission, set to 250 KB by default.

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 secondary's known chain tips, streamed blocks use bounded backpressure instead of being dropped, and a lagging secondary 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 also remains bound to the block that was originally resolved, even if the best chain reorganizes during the request.

We also cleaned 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. Thank you to @dismad for suggesting the clearer RPC wording and to @ambimorph for reporting the stale branding.

Other improvements

• disable_pow now applies to native header sync. Native header sync honors disable_pow = true on configured Testnets, matching semantic and checkpoint verification.
• 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 the Ironwood-only benchmark, authorizing-data digest calculation was 2.8% faster and combined transaction-ID plus authorizing-data digest calculation was 5.6% faster.
• Tests are more deterministic. Acceptance tests now wait for observable readiness instead of fixed sleeps, removing avoidable test latency, and a log-capture race that could corrupt tracing span bookkeeping in zakurad test binaries is fixed.
• Header sync groundwork continues. A specification for a fork-aware header chain engine was added, laying groundwork for the next stage of native header sync.

End of support

Zakura 1.0.3 supports Ironwood (NU6.3) activation and is currently configured to reach end of support roughly eleven days afterward, by which point the next 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.