zakura

Release: Zakura 1.3.0

Zakura 1.3.0 paired with Common on a pale gridded blueprint: the solid pink zakura flower logo above the version number 1.3.0 on the left, a double-headed equivalence arrow in the centre, and a wireframe blueprint drawing of the same flower above the word COMMON on the right.Zakura 1.3.0 paired with Common on a dark navy gridded blueprint: the solid pink zakura flower logo above the version number 1.3.0 on the left, a double-headed equivalence arrow in the centre, and a wireframe blueprint drawing of the same flower above the word COMMON on the right.

We have released Zakura 1.3.0, our largest update yet. This is the first release built on Common, the accelerated cryptography stack we recently announced, directly translating to improved transaction and block processing time for all users.

This release also features a brand new consensus engine built for speed and security. Currently located within our experimental P2Pv2 stack, its architecture addresses security issues by targeting vulnerabilities at their root causes. It is also designed in anticipation of higher throughput, and supports better integration with lightwalletd.

Several features requested by explorers, indexers, infrastructure operators and users migrating from zcashd have been integrated into this release. We recommend that all node operators update for better performance and security, and we recommend miners update for reduced orphan rates.

Experimental Consensus Engine

Earlier releases of Zakura closed P2P vulnerabilities one at a time. Most of these issues were due to underlying architectural problems that would require a new proof-of-work consensus engine to truly resolve. So, we built it.

In our redesign, every byte communicated must be verifiable, useful, and within a node's work budget. This is the same kind of design philosophy underlying light clients. In fact, our new implementation is naturally light client first.

Verified Header Chain

Zakura's experimental consensus engine downloads and verifies headers and tracks competing consensus branches in a bounded, authenticated DAG, selecting the best eligible chain. It verifies each header's proof-of-work, difficulty and contextual rules before the node acts on it. Then, it authenticates every block body against the verified header chain.

finalizedBEST CHAINtipforkforkEvery header is verified before it enters the DAG.

The engine separates the block body downloading logic between catch-up and chain tip, without duplicating consensus logic. The catch-up downloader optimizes for raw throughput, while the chain tip downloader balances throughput with latency. Both of them use the same verified header chain.

This architecture addresses many P2P security vulnerabilities by design:

  • Unverified headers and unauthenticated bodies cannot steer expensive work.
  • The engine is fork-aware and persists the header chain atomically across crashes.
  • All peer-supplied data is authenticated and tracked.

As an example, the redesign could allow two Zakura peers to gossip blocks after proof-of-work verification but before every zk-SNARK proof finishes verifying, reducing orphan rates significantly.

The bounded header DAG makes block reorganization safer and the fork-choice rules explicit. This matters in the context of attacks like selfish mining, especially because Zcash's difficulty adjustment algorithm is applied every block. We plan to harden these rules in later releases; if adopted, ZIP-218's difficulty adjustment changes would reduce this risk.

Experimental Support

The new engine is disabled by default for Mainnet. If you want to enable it, you must add

p2p_stack = "dual"

to your Zakura configuration. It is enabled for Testnet by default.

Serving Light Clients (on P2Pv2)

The verified-commitment-tree (VCT) fast sync in our P2Pv2 stack already allows a new node to reach the chain tip quickly. It achieves this by skipping historical node commitment trees. However, current lightwalletd architectures expect all full nodes to maintain historic frontiers and full subtrees. This meant that lightwalletd was unable to serve queries from P2Pv2-synced nodes. (As mentioned, this stack is still experimental and disabled by default.)

We consider this a design flaw of lightwalletd itself. Beyond some historic distance, it should be sufficient to maintain frontiers of full subtrees or a fixed block interval, such as every 10,000 blocks.

Nevertheless, we updated Zakura so that it could produce these exact queries for historic data without significant disk space costs. This was achieved with a combination of offline checkpoints and online recomputation: the node ships a small checkpointed list of tree frontiers at historic blocks, and to answer a query, we replay the block bodies from the nearest frontier and rebuild the tree.

Thanks to our new Common cryptography stack, this replay is very quick, which means lightwalletd operators should have seamless functionality from all Zakura archive nodes.

Speaking of Common...

Running on Common

Zakura Common speeds up the shielded cryptography a full node relies on. Verifying a shielded zk-SNARK is between 4x and 8x faster, and Sinsemilla hashing, which builds the Orchard and Ironwood note commitment trees, is more than 21x faster.

Nodes touch this cryptography almost everywhere they handle shielded transactions, and so this speedup shows up across the board:

  • Safer mempool operation. Nodes can validate mempool transactions at lower latency, which makes exposing a node's mempool to the public much safer.
  • Verifying blocks and transactions. Every shielded proof the node checks, in each block it accepts and each transaction it relays, is verified faster.
  • Syncing the commitment tree. Building the Orchard note commitment tree during sync is about twice as fast, using our new weighted fixed-length Sinsemilla evaluator and a one-time 3.75 MiB table. Ironwood's tree uses the same code and inherits the speedup.
  • Building blocks. Miners assembling a block template with shielded transactions spend less time on the cryptography, so getblocktemplate returns sooner.
  • Relaying and propagating. Faster verification means transactions and blocks relay and propagate with less delay, helping to reduce orphan rates for miners.

We also cache Sapling bundle verification now. These proofs and signatures are verified once when they arrive over the mempool and not re-verified when they appear in a block. This extends the caching we shipped in 1.2.0 to the last remaining shielded pool.

RPC Changes

  • getchaintips is answered natively. Operators used to send this call to the zcashd compatibility sidecar, where it scanned the whole block index under a global lock and could stall every other RPC for seconds. Zakura reads only the forks it is tracking, so the cost depends on how many live forks there are, not on the height of the chain. It reports only the tips that are still live (the best chain, the non-finalized forks, recently invalidated branches, and the selected header chain when some block bodies are missing), never zcashd's valid-headers or unknown statuses, so the two nodes list different tips.
  • getpeerinfo reports peer software. The response now includes each peer's advertised software identifier (subver) and protocol version. This was requested to better support explorers.
  • Several long-term deprecated endpoints have been removed. See the changelog for more details.

P2P Network Service Discovery

Huge thanks to @distractedm1nd for contributing P2P service discovery into Zakura! This lets applications advertise the extra services they provide over the P2P network, so a wallet can discover nodes that serve additional functionality, such as PIR or lightwalletd interfaces.

We hope that future wallets can connect directly to the Zcash P2P network, instead of bundling every single service type into their software. Thus, we believe this is a step in the right direction.

Security

  • A peer can no longer force a large allocation by declaring a near-maximal byte-vector length in a short message. The allocation is bounded before the message is rejected.
  • Malformed headers are rejected before hashing. Block and checkpoint verification now reject an invalid header version or an unrepresentable timestamp before computing the header's hash. This closes a gap for in-memory headers, such as block proposals, that never pass through the parser.
  • Dependency hygiene. Dependencies were updated to address published advisories, and many were removed outright to reduce supply-chain surface.

Other operator-facing changes

  • Expired RPC TLS certificates are flagged at startup. zakurad now logs a warning naming the certificate file and the date it fails on, instead of opening the listener silently and failing client handshakes later.
  • Bounded /metrics on public listeners. Network Prometheus counters are no longer labeled by peer address, so their cardinality stays bounded on long-lived public listeners.
  • Faster block verification. Contextual block verification drops redundant UTXO copies and shares immutable UTXO maps, and transaction-verifier and mempool reads no longer queue behind the serialized state write buffer.
  • Misconfigured networks fail at load time. Custom-network parameters that could panic block validation at a later height, such as overflowing funding-stream numerators or non-P2SH funding and lockbox addresses, are now rejected when the configuration is read.
  • Removed the unsupported copy-state debugging command.

Crate Consumers

If you build against Zakura's published crates, note two changes. The dependency graph now resolves the Zakura cryptography crates in place of their upstream equivalents, and zakura-rpc removed a set of deprecated type aliases and constructors. RPC endpoints and wire formats are unchanged; the changelog lists the exact replacements.

End of Support

This release shortens the end-of-support window from 40 to 31 days. Mainnet zakurad nodes running 1.3.0 halt at height 3,501,339 (estimated 2026-09-30); upgrade warnings begin three days earlier.

Updating

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