# Release: Zakura 1.3.0 Announcement for Zakura 1.3.0, which moves the full node onto the Common cryptography stack. Published 2026-08-31; the release tag v1.3.0 was published 2026-08-29. All node operators should update. What the announcement says: - 1.3.0 is the first Zakura release built on Common (https://github.com/zakura-core/common), the accelerated Zcash cryptography we recently announced (https://zakura.com/announcements/zakura-common/). Every part of the node that touches shielded transactions is faster as a result, and no network upgrade was required. - What Common means for a full node: it speeds up the shielded cryptography the node runs constantly. On the Common announcement's benchmark hardware, 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. Because the node touches this cryptography nearly everywhere it handles shielded transactions, the benefit is broad: verifying the proofs in every block it accepts and every transaction it relays, building the Orchard note commitment tree during sync (Ironwood's tree is the same code and inherits the speedup once NU6.3 activates; it is not built before then), assembling block templates that include shielded transactions (`getblocktemplate`, for miners), and relaying transactions and propagating blocks, which helps reduce orphan rates for miners. - The headline proof-generation numbers in the Common announcement (mobile more than 14x, desktop more than 5x) and trial decryption (more than 1.5x) are wallet workloads and do not describe the node: a full node verifies proofs rather than generating them or decrypting notes. - In our measurements the Orchard note commitment tree updates are about twice as fast, evaluating MerkleCRH^Orchard with the new weighted fixed-length Sinsemilla evaluator (https://zakura.com/engineering/position-weighted-sinsemilla/), for a one-time 3.75 MiB in-memory table. - This release also caches Sapling bundle verification, extending the Orchard and Ironwood verification cache added in 1.2.0 to the last remaining shielded pool. A transaction's Sapling proofs and signatures are verified once, when it arrives over the mempool, not a second time when the block that mines it arrives, under the same transaction-ID key. - This release adds a full proof-of-work consensus engine in the standalone `zakura-header-chain` crate. Zakura's P2P philosophy has always been that all bytes must be verifiable, useful, and within the node's work budget. Applying that philosophy to proof-of-work consensus makes the engine a light client first. It downloads and fully verifies headers (PoW/Equihash, difficulty, and contextual header rules), retains competing branches in a bounded, authenticated DAG, and selects the best eligible chain. It then authenticates block bodies against that verified header chain. - Zakura uses separate block-body downloaders for catch-up and the chain tip. The catch-up downloader optimizes raw throughput. The chain-tip downloader balances latency and throughput. Both downloaders use the same consensus engine and verified header chain. This separation lets Zakura change how it downloads block bodies without duplicating consensus logic. It prevents unverified headers or unauthenticated bodies from steering expensive work. The engine is fork-aware and bounded. It persists the header chain atomically across crashes, validates headers in context, resumes startup reconstruction, and authenticates peer-supplied VCT metadata when it processes headers. - The header-chain engine remains experimental and opt-in on Mainnet. `P2pStack` defaults to `legacy` on Mainnet and `dual` on every other network. The native header and block sync runs only under `v2_p2p()` in dual or Zakura mode. A default Mainnet 1.3.0 node therefore runs only the legacy sync path. Operators can set `network.p2p_stack = "dual"` to run both paths side by side. One lifecycle coordinator prevents legacy fallback from applying blocks while a native apply is active. The test networks already use the dual stack by default. This release also adds in-place migrations across several header-chain disk formats, bounds reads from disk and peers, and recovers from crashes and hostile peers. One fix corrected a header-chain throughput collapse caused by tombstone accumulation during finality-history eviction. Before the fix, a dual-stack Mainnet sync fell from 254 to 8.6 blocks per second. The fix makes eviction O(1) and requires no migration. - Applications embedding `zakurad` can now register their own Zakura peer-to-peer services and advertise them through peer discovery. - Light-wallet (lightwalletd) serving is restored on Mainnet fast-synced archive nodes. VCT fast sync skips the historical note commitment trees that `z_gettreestate` and `z_getsubtreesbyindex` need, which regressed lightwalletd; 1.1.0 (not 1.1.1) made those calls return a typed archive-mode error instead of a wrong answer, and 1.3.0 serves them properly again. This is default-on for a Mainnet archive node with no configuration: the reviewed frontier grid is embedded in the binary; the `state.historical_frontier_artifact` setting only overrides it, for tests and custom networks. The mechanism pairs an offline checkpoint with online recomputation: the binary embeds a reviewed, cost-weighted grid of note-commitment-tree frontiers sampled across the chain (about 2 MB, ~2,281 entries), with a frontier near every height, and a query in the fast-synced band replays the retained block bodies from the nearest frontier and rebuilds the tree, accepting the result only if it reproduces the authenticated root already stored. The nearby anchors bound how many blocks a query replays, and the same fast batched hashing that builds trees during sync makes that replay cheap (Orchard/Ironwood use Sinsemilla; Sapling uses Pedersen). The grid is spaced to a ~2 s cold-replay budget per entry; measured cold reconstruction is ~1 s median (p90 ~2.5 s, tail higher), and repeat queries are far cheaper. This needs an archive node that retains block bodies; a pruned node still returns the typed error. The restored calls are `z_getsubtreesbyindex`, `z_gettreestate`, and the verbose `getblock`/`getblockheader` tree sizes, across the fast-synced band, with no configuration. - RPC: - `getchaintips` is now answered natively by `zakurad` instead of the `zcashd` compatibility sidecar, where it scanned the whole block index under a global lock and could stall other RPCs for seconds. Zakura reads only the forks it tracks, so the cost is bounded by the number of live forks rather than the chain height. Zakura lists live tips only (best chain, non-finalized forks, recently invalidated branches, and the selected header chain when some bodies are missing) and does not report zcashd's `valid-headers` or `unknown` statuses, so the two nodes report different tips. - `getpeerinfo` now includes each peer's advertised software identifier (`subver`) and protocol version. - Security: - A dedicated security review of the new header-chain engine found nine issues in its authority, recovery, finality, and replay logic, all fixed here. Recovery binds durable state to the full network policy and checks independent authority before accepting a full-state path or finality witness. - Disabling proof of work now requires an authenticated custom-network configuration. `disable_pow` claimed for Mainnet or the default public Testnet is refused rather than silently waiving Equihash verification, and the waiver path still validates solution shape. - A peer-declared byte-vector length is now bounded before allocation, so a short message declaring a near-maximal length no longer forces a large allocation before rejection. - Block and checkpoint verification reject an invalid header version or an unrepresentable timestamp before hashing the header, closing a gap for in-memory headers (such as block proposals) that never pass through the parser. - Dependencies were updated to address published security advisories, and many were removed outright to reduce supply-chain surface. - Other operator-facing changes: - `zakurad` warns at startup when its RPC TLS certificate is expired or not yet valid, naming the file and the failing date, instead of opening the listener silently. - Network Prometheus counters are no longer labeled by peer address, so `/metrics` cardinality stays bounded on long-lived public listeners. - Contextual block verification is faster (redundant UTXO copies removed, immutable contextual UTXO maps shared), and transaction-verifier and mempool reads are routed around the serialized read-write state buffer. - Custom-network parameters that could panic block validation at a later height (overflowing funding-stream numerators, a receiver configured twice in one funding stream, non-P2SH funding or lockbox addresses, lockbox amounts that do not sum to a valid amount, slow-start intervals that make the founders reward inexact) are rejected when the configuration is read. - The unsupported `copy-state` debugging command was removed. - Crate consumers: the published dependency graph now resolves the Zakura cryptography crates instead of their upstream equivalents, and `zakura-rpc` removed a set of deprecated type aliases and constructors. RPC endpoints and wire formats are unchanged. The exact replacements are in the changelog (https://github.com/zakura-core/zakura/blob/v1.3.0/CHANGELOG.md). - End of support: the window is shortened 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. - Update using the signed release binaries (https://github.com/zakura-core/zakura/releases/tag/v1.3.0) or the `zakura` crate 1.3.0. Installation and verification instructions are at https://zakura.com/download/. --- Canonical HTML version: https://zakura.com/announcements/zakura-1-3-0/