zakura

Release: Zakura 1.0.2

We have released Zakura 1.0.2, a stability and performance release. It makes the zcashd compatibility mode substantially more reliable, and fixes a number of other bugs. We recommend that all node operators update.

zcashd compatibility mode

zcashd compatibility mode runs a real zcashd process with the Zakura node as its only peer, so software that still speaks the old RPC interface keeps working. Its most visible problem, zcashd occasionally stalling behind the chain tip, turned out to have three distinct causes, and this release fixes all of them:

  • Block announcements are no longer dropped. An announcement to a momentarily busy zcashd was silently skipped with no retry, and on nodes that mine locally, queued announcements were canceled before ever reaching the wire. Announcements are now queued and delivered as soon as zcashd is ready.
  • Zakura no longer disconnects its own zcashd. Under heavy load, Zakura's denial-of-service protection could randomly disconnect the operator's own zcashd, and per-IP connection limits could stretch one disconnect into a multi-second blackout. The configured zcashd is now never disconnected: its requests are still shed under load, and protection for every other peer is unchanged.
  • Supervision is more complete. Zakura now shuts down its managed zcashd process when it exits, enables the complete legacy wallet RPC surface by default (with -allowdeprecated=none as the opt-out), works when Zakura itself runs pruned, and reports an actionable error when zcashd requests a block body that pruning has dropped.

Other improvements

  • Mempool hardening. The mempool now favors protecting miners and RPC operators, with trade-offs chosen to preserve every real usage pattern we have seen. Transactions larger than a configurable limit (250,000 bytes by default) are now rejected, many kinds of rejection are faster and cheaper, and peer penalties follow the root cause of what actually went wrong, limiting what a malicious peer can do. We also avoid an edge case where peers can get banned at the NU6.3 upgrade boundary.
  • Faster block template refreshes. The bundled Sapling proving parameters are now parsed once per process and the prover is shared, instead of being re-parsed on every getblocktemplate refresh, and mempool metrics are maintained incrementally rather than recomputed from a full mempool scan after every change.
  • Faster transparent signature checks. Signature-hash components that are shared across a transaction's inputs are now computed once and reused for every transparent signature check, instead of being recomputed per signature.
  • Pruned nodes no longer advertise blocks they cannot serve. Responses to legacy peers no longer include blocks whose bodies pruning has dropped.
  • Peer addresses stay out of logs by default. Peer activity logs and metrics keep using redacted, privacy-preserving peer IDs; operators who need raw addresses in their trace files can opt in with the new network.expose_peer_addresses setting.
  • Sync fixes. Early-chain difficulty validation now applies the proof-of-work limit correctly at the averaging-window boundary, and header sync now schedules only forward ranges from the durable verified tip instead of backfilling backward.

Sprout history repair in experimental fast sync

Fresh verified-commitment-tree (VCT) fast sync, part of Zakura's experimental P2P stack, did not persist the chain's historical Sprout note-commitment history. An affected node runs normally until a transaction spends against a historical Sprout anchor, which the node can then no longer validate against its local state. Only mainnet databases created by fast sync over the experimental transport are affected, and the experimental stack is off by default.

Zakura 1.0.2 fixes the bug and repairs affected databases automatically. At startup, Zakura restores the missing history from a reviewed copy of the mainnet Sprout history, distributed as exact-versioned crates.io packages, and validates it before writing any repaired state. The repair is crash-safe: an interruption restarts it rather than skipping it, and an affected database refuses to run until its repair completes.

You can also audit the result yourself: a new read-only command, zakurad validate-vct-sprout-history, checks the historical Sprout anchors of any mainnet database, archive or pruned, against the reviewed history. And if you would rather not repair in place, redownloading a snapshot or resyncing from genesis also produces a correct database.

End-of-support halt

Zakura 1.0.2 supports Ironwood (NU6.3) activation and reaches end of support roughly ten days after it, by which point the first post-Ironwood release will be available. Nodes still on 1.0.1 reach end of support roughly one week after activation: they will begin warning about the required update a few days beforehand and then halt. We recommend updating now rather than during the activation window.

Updating

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