# Release: Zakura 1.4.0 Announcement for Zakura 1.4.0, a performance release. Published 2026-09-10; the release tag v1.4.0 was published the same day. The post also announces Zakura Common 1.2.0 (released as https://github.com/zakura-core/common/tree/v1.2.0 and included in this Zakura release) and covers the changes shipped in Zakura 1.3.1 (2026-09-02) and 1.3.2 (2026-09-05), which had no announcements of their own. All node operators should update. What the announcement says: - Zakura 1.4.0 is a performance release. It reduces block propagation latency for miners, improves polling latency for `lightwalletd` operators, and continues work on the experimental P2Pv2 stack. It updates Zakura Common from 1.1.0 to 1.2.0, whose lower proving latency makes shielded coinbase practical for mining-pool block templates. All node operators should update; miners and `lightwalletd` operators benefit the most. - Zakura Common 1.2.0 (https://github.com/zakura-core/common/tree/v1.2.0) is included in Zakura 1.4.0 and further improves mobile proving times. Proving on an iPhone 17 is now 21 times faster than before Zakura; the post compares this to the Sprout-to-Sapling transition's 5.3x proving speedup and calls it four times as large, measured on real devices. Cold proving latency on the benchmarked devices: iPhone 17 (2025) 3 s to 142 ms (21x); Galaxy S25 (2025) 4.7 s to 173 ms (26x); Pixel 7 (2022) 10.5 s to 550 ms (19x); iPhone 8 (2017) 8.6 s to 360 ms (23.8x). Several older phones were added to the benchmark suite after users on older devices reached out about benchmarks following the initial Common release (https://zakura.com/announcements/zakura-common/). The post invites wallets to switch to the Zakura wallet libraries (https://github.com/zakura-core/wallet-libraries) and the Common stack they depend on (https://github.com/zakura-core/common). - Mobile proving work behind the Common release: a 15% desktop speedup appeared as only about 3% in noisy mobile results, traced to a cold-CPU problem on iPhones. The first proving phases were six times slower cold than warm (one short phase around 2.5 times slower); warm-CPU proving tracked desktop closely. iPhones run six cores, with four active initially in the team's traces, and the start of a two-action proof was single- or two-threaded with high memory traffic. Fixes: changed how the public input is committed and transformed, reduced algebra and memory traffic during ZKP witness creation, and cached duplicated circuit-construction work in the proving keys. CPU warmup time fell by about 12 ms on the iPhone 17, a significant part of the nearly 30% proving speedup since Common 1.0.0; the cold-start penalty is now 28 ms, about 25% of proving time. Saturating every core early on phones remains open work. - Faster block propagation: miners begin the final block verification check when they create a block template, and prepared mining candidates are reused through `workid` (the BIP 22 `getblocktemplate` field, echoed back in `submitblock`, that matches a submission to its prepared candidate). After mining, Zakura advertises the block once expected-work validation and state admission succeed, without waiting for the final local verification path. The proof-result caching shipped in 1.2.0 (https://zakura.com/announcements/zakura-1-2-0-orphan-rate/) reduced this work; 1.4.0 removes it from the propagation-critical path entirely. Guardrails: rejected mining templates are withdrawn (affected internal mining work stops, empty-template recovery is validated before a replacement is returned); mined submissions and contextual writes are bounded, and a mined block waiting for its parent or verification capacity returns `inconclusive`; optimistic relay is blocked while earlier contextual writes or operator changes can move the selected tip; duplicate all-peer inventory delivery is avoided. The `source` label on the `sync.block.first_received.count` metric (added in 1.3.2) reports whether Zakura or legacy TCP first delivered each complete block body. - Faster lightwalletd polling: `getblockchaininfo` reuses the periodic database disk-size measurement (shipped in 1.3.1), and its p95 latency fell from 24 ms to 0.28 ms, about 86x faster, per operator reports. Because `lightwalletd` calls it from `GetLatestBlock`, end-to-end `GetLatestBlock` p95 latency fell from 25 ms to 6 ms, more than 4x faster. - P2Pv2 reliability work across 1.3.2 and 1.4.0: - Header sync repairs contiguous ranges of missing VCT roots in one request; checkpoint commits resume immediately after a header-chain commit instead of polling every 500 ms; a parked checkpoint clears its own resource-stall alarm. The stalled-height diagnostic measures the parked block's complete wait, so a changing missing height no longer postpones the operator error or clears the gauge early. - Header sync does not admit VCT auxiliary input that durable state already retains or has rejected or disputed; each repair claims its exact durable episode; suppliers rotate after peer-attributed failures and a failed supplier is not retried while it remains connected; disconnected supplier identities are released so connection churn cannot exhaust the supplier history; an unresponsive supplier is charged like a timed-out peer without ending the scheduling round. Auxiliary admission lets retention free aggregate capacity before the planner enforces retained delivery limits; the per-header semantic-payload limit increased from 16 to 32. - Block sync: peer serving and misbehavior-report traffic no longer consume the action capacity reserved for needed-body refill recovery; deterministic invalid-body evidence and retry state are preserved until the driver accepts each persistence action; failed needed-body state queries are retried through action-queue contention; the node stops when the critical block-sync driver exits unexpectedly instead of leaving native services running without block application. - Security (from 1.3.1, 1.3.2, and 1.4.0): - Administrative RPC methods on Mainnet and Testnet are restricted to authenticated listeners, with an optional `rpc.admin_listen_addr` loopback listener; the unauthenticated listener remains intended for protected downstream connectivity, not arbitrary Internet traffic (1.3.2). - A check on the combined chain value-pool balance was added as defence in depth (1.4.0). - The yanked transitive `chacha20 0.10.1` dependency was replaced with `0.10.2`, whose SSE2 backend no longer emits an SSE4.1 instruction that crashes `zakurad` on x86 CPUs without SSE4.1 support (1.3.1). - Other improvements: serial UTXO lookup delays during block verification of transactions with many transparent inputs are fixed (the verifier overlaps up to 64 responses per transaction and admits one lookup at a time to preserve state responsiveness, 1.4.0); legacy synchronization preserves checkpoint work across temporary tip refresh timeouts (1.3.2); metrics, dashboards, and alerts cover the Mainnet end-of-support schedule (1.3.2); the minimum supported Rust version is 1.97 for `zakurad` and the internal crates (1.4.0). - End of support: Mainnet `zakurad` nodes running 1.4.0 halt at height 3,504,731 (estimated 2026-10-03), the same halt height and date as 1.3.2; upgrade warnings begin three days earlier. (The nominal window is 21 days, chosen purely to land on that existing halt height, not a policy change.) - Update using the signed release binaries (https://github.com/zakura-core/zakura/releases/tag/v1.4.0) or the `zakura` crate 1.4.0. Installation and verification instructions are at https://zakura.com/download/. --- Canonical HTML version: https://zakura.com/announcements/zakura-1-4-0/