# Release: Zakura 1.8.0

Announcement for Zakura 1.8.0, released 2026-11-02. The announcement
was checked against the tagged v1.8.0 release and separates release
changes from further improvements measured on development builds.

The headline framing: 1.8.0 is a security and stability release. It
eliminates unnecessary dependencies (reducing supply chain risk,
release download size), building on the reductions shipped in
1.7.0 (https://zakura.com/announcements/zakura-1-7-0/), and improves
block announcement and validation performance. Unlike earlier Zakura
release announcements, it does not instruct every node to update:
NU7 activates on Zcash's Mainnet at height 3,543,405 (expected around
5 November 2026) days after the release, 1.7.0 nodes are fully
prepared for that activation, and updating before it is optional.
1.7.0 nodes halt at height 3,640,098, estimated 4 December 2026.

Claims by section:

## Fewer dependencies

- The Prometheus metrics endpoint is in-tree, replacing
  `metrics-exporter-prometheus`; metric names and output format are
  unchanged. Histogram quantiles now use every sample from the last
  minute within 0.1%; the previous exporter dropped samples recorded
  before a histogram's first scrape and lost accuracy for samples
  spanning more than a factor of about 700.
- Building Zakura no longer requires libclang (RocksDB bindings are no
  longer generated with bindgen at build time), removing the build
  prerequisite introduced in 1.1.1.
- The bundled RocksDB compiles without unused features (SST file
  ingestion, remote compaction, tracing) via `zakura-rocksdb` 0.24.4,
  leaving out more than 500 KB of code and shortening clean builds;
  RocksDB behavior and the on-disk format are unchanged. This retries
  the trimmed build that 1.7.0 disabled over a GCC 16 link failure.
- The dependency lock file lists 341 packages, down from 350 in 1.7.0.

## Faster block announcements

- Benchmark (two nodes, time from a block being mined on one node to
  the connected node building a block template on it): median 833 ms
  before, 7.5 ms after (range 5.5-10.7 ms), up to about 110x faster; Zebra
  v7.0.0 measured 6.5 ms on the same setup with no statistically
  significant difference. The 833 ms median was a worst case for a
  quiet node (few peers, all in sync): most samples waited out a
  pending sync request's 6 s timeout. The announcement design is
  adopted from Zebra. A bar chart shows 833 ms before the fix and 7.5 ms
  in 1.8.0 on the same linear scale starting at zero.
- Mainnet observation (small sample, three receiving nodes, 16 blocks
  before / 13 after): after a mining pool upgraded its sending node to
  Zakura 1.8.0-rc.1,
  the median time from pool submission to local acceptance fell 43-56%
  (medians 1.15-1.56 s down to 0.63-0.69 s across receivers), and the
  slowest observed deliveries fell 74-82% (7.44-7.55 s down to
  1.35-1.91 s).
- New-block announcements no longer wait behind a pending `getblocks`
  request (previously up to several seconds) or behind an earlier
  block's announcements.
- Nodes with an empty mempool reply to inventory requests immediately
  instead of timing out, removing block relay delays of up to 6 seconds
  for sparsely connected nodes.
- A block announced while a discovery reply is pending on the same
  connection downloads immediately instead of after the discovery round
  (up to 6 seconds); a gossiped block arriving before its parent
  requests the parent at once after proof-of-work checks.
- Legacy announcement peer sets refresh while idle, and announcements
  retry against fresh peers when a selected connection loses
  authorization.
- `sendrawtransaction` and other local submissions no longer wait an
  extra 50 ms per transaction before entering the mempool and block
  templates.

## Faster block validation

- Accepting a block built from the node's own template takes about half
  as long: a 1.9 MB block drops from 375 ms to under 200 ms. The node
  skips repeated logging and Merkle checks, reads output addresses from
  scripts, and reuses template transactions instead of parsing them again.
- Verifying a previously unseen block takes up to 34% less time:
  transparent 1.9 MB blocks drop from 2.14 to 1.41 seconds, mixed blocks
  from 882 to 742 ms, and Orchard verification takes about 11% less time.
- Per-block overhead falls 3-5% on every block, and `getblocktemplate`
  uses about 10% less CPU.
- The Common cryptography libraries are updated to 5.0.0
  (https://zakura.com/announcements/zakura-common/): faster Groth16
  proof and RedDSA signature batch verification, faster Sapling proof
  parsing.
- Orchard and Sapling proof batches are prepared on blocking/CPU
  workers instead of the async workers that admit transactions.
- Block verification no longer recomputes transaction IDs for signature
  hashes, network-upgrade lookups no longer rebuild maps per call,
  parent-input checks overlap reads, and block commits no longer open
  per-transaction INFO tracing spans (at INFO, commit logs lose
  per-transaction span names; TRACE keeps them).
- Sprout, Sapling, and Orchard bundles move out of every transaction's
  inline storage, reducing transaction memory use.

## Comparison with Zebra Ándale

The announcement adds a comparison section responding to the Zcash
Foundation's Zebra Ándale release (Zebra 7.1.0-alpha.0, a performance
build for miners; article:
https://zfnd.org/zebra-andale-the-fastest-zebra-yet/). The article reported,
among other figures, 1.1 s block relay for Zakura; the announcement credits
the comparison with highlighting mining-path improvements and supplies
measurements on current builds (Zakura's own benchmark machines, not
the article's setup):

- Mainnet replay (Zakura 1.8.0 vs Ándale): 32,860 consecutive Mainnet
  blocks, heights 3,505,701 to 3,538,560, replayed into each node on the
  same 8-vCPU Intel Xeon cloud server, both built from source with the
  same compiler settings, no peers, empty mempools, full verification and
  commit, three alternating runs per node. Total 461 s vs 1,141 s (2.5x
  faster); average per block 14.0 vs 34.7 ms; median 12.7 vs 26.2 ms;
  99th percentile 81 vs 367 ms; slowest block 396 vs 1,106 ms; Zakura
  faster on 32,368 of 32,860 blocks (98.5%); CPU time over each whole run 1,382 vs 5,632 s.
  Shielded blocks 2.6x faster; on the 1% of blocks slowest for Ándale,
  Zakura 5.3x faster. Per-block times are medians of three runs; totals
  and CPU time are averages.

The announcement reports that over the 24 hours to November 2 (1,154 blocks),
the Foundation's live Mainnet dashboard measured median acceptance of
6.7 ms for Zakura 1.7.0, 5.9 ms for Ándale, and 119 ms for Zebra 7.0.0.
The dashboard is at https://alpha.zfnd.org/.

The comparison uses one machine in the same session, medians of 3 to 18
runs, with minimum and maximum in parentheses where shown. Blocks are
1.9 MB unless noted. Times are in milliseconds unless marked in seconds:

### Block propagation and new work

| Operation | Zakura 1.8.0 | Zebra Ándale |
| --- | ---: | ---: |
| New work after a peer's block, fresh connection | 61 (12–106) | 71 (13–1,998) |
| Same, settled connection | 12 (10–15) | 5.5 (4–16) |
| New work after the node's own block | 4.2 (3–8) | 1.6 (1–2) |
| Relaying an empty solved block to a peer | 62 (14–103) | 46 (21–92) |

### Transaction bursts

| Operation | Zakura 1.8.0 | Zebra Ándale |
| --- | ---: | ---: |
| Transparent transaction burst to block template | 19.0 s (18.3–19.2) | 30.9 s (29.9–31.1) |

On fresh peer connections, Zakura's slowest time to new work was 106 ms
across 18 runs, against 1,998 ms for Ándale. A 1.9 MB transparent transaction
burst reached a template in 38% less time with Zakura, and its slowest run beat
Ándale's fastest. On settled connections and the node's own blocks, both
nodes build new work within about 12 ms. Relaying an empty solved block
is presented as a tie: the 62 vs 46 ms medians differ by less than the
run-to-run spread.

The article's live dashboard uses nodes with no peers and empty mempools,
while its mining benchmarks use separate setups. Empty mempools mean the
nodes have not already verified incoming transactions through their
mempool. A connected node can perform those checks before a block arrives.
The earlier 7.5 ms announcement measurement is compared with Zebra 7.0.0;
the propagation table above adds the fresh-connection, settled-connection, and local
measurements against Ándale.

## Coming next

Further improvements are measured on development builds, separately
from the tagged 1.8.0 release. Blocks are 1.9 MB unless noted:

- Reusing template spend checks, value-pool changes, and body hashes
  brings mixed-block acceptance to 75 ms against Ándale's 76 ms, and
  Orchard acceptance to 41 ms against 46 ms.
- Transparent signature checks take about 29% less time; new transparent
  blocks verify in 822 ms, down from 988 ms in 1.8.0.
- Shielded blocks verify in 6-32% less time with shielded-first scheduling,
  partial proof batches flushing after 5 idle milliseconds, and Orchard
  batches of 128 actions. New mixed 250 kB blocks verify in 63 ms,
  down from 93 ms in 1.8.0.
- Mixed-block relay takes 1,026 ms, down from 1,203 ms; new mixed blocks
  verify in 497 ms, down from 537 ms.

## x86-64 field arithmetic

Default and release x86-64 builds enable BMI2/ADX Pasta field assembly
and require those CPU extensions, checked once at startup with an error
naming what is missing instead of an illegal-instruction crash. This
reverses 1.6.0's portable-by-default published binaries; Intel CPUs
since 2014 and AMD CPUs since 2017 have both extensions, and older
CPUs build with `--features portable`.

## Security hardening (no advisories cited)

- Our experimental P2Pv2 stack's block sync caps decoded block bodies
  queued for submission under the 512 MiB decoded window from 1.7.0;
  past it, bodies wait as raw bytes and are decoded at submission, so a
  slow verifier cannot hold hundreds of decoded blocks in memory.
- Recent Mainnet block downloads require a minimum claimed
  proof-of-work difficulty (defense in depth). Historical sync is
  exempt only below fixed height 3,535,411 and only while the committed
  tip is below it.
- Native-protocol hardening: stream preludes whose frame cap cannot
  carry a payload are refused, an oversized frame no longer closes the
  whole connection, and a handshake ack cannot accept a capability the
  dialer never offered.

## Other changes

- The indexer gRPC server is an optional build feature (`indexer-rpc`);
  default and release builds continue to include it.
- The managed zcashd compatibility sidecar pins zcashd v1.3.1
  (https://github.com/valargroup/zcashd/releases/tag/v1.3.1), fixing
  sync stalls after out-of-order block announcements.
- `z_gettreestate` on pruned nodes returns tree state below the prune
  height; `getblocktemplate` reports "not synced" on a fixed 6-hour
  tip-age threshold instead of a block count; `getpeerinfo` adds
  `startingheight`.
- Metrics: histogram quantiles no longer lose samples across window
  boundaries, `/health` returns `OK`, five new block-sync byte gauges.
- `tracing.filter` applies only level/target directives (span and field
  directives are ignored with a warning); `log`-crate records such as
  rustls messages are no longer forwarded into logs.
- P2Pv2 block-sync stall fixes (resets, reorgs, peers without latency
  samples, checkpoint commit boundaries) and a discovery
  initial-exchange timeout race fix.
- Custom testnets accept compatible peers using the active upgrade's
  protocol version.

## End of support and updating

Verified against the tagged 1.8.0 release: Mainnet nodes support height
3,643,309 and halt above it, projected 5 December 2026 at 00:00:20 UTC.
Warnings begin three days earlier; enforcement follows height, not time.

Zakura 1.8.0 was published on 2 November 2026
(https://github.com/zakura-core/zakura/releases/tag/v1.8.0), and the
announcement carries the same date. Installation and verification
instructions are on the download page (https://zakura.com/download/).

---

Canonical HTML version: https://zakura.com/announcements/zakura-1-8-0/