Hey folks, today zainod 0.3.1 is officially available on crates.io, dockerhub, and github. There’re a host of improvements over the previous 0.2.0 release that you can find summarized here.
Indexer-side blockchain queries (zaino-state)
gettxoutsetinfo served from Zaino’s own UTXO-set accumulator — the transparent UTXO set is now tracked incrementally in the indexer, so this RPC no longer forwards to the backing validator. (hash_serialized uses an order-independent, incrementally-maintainable XOR-of-BLAKE2b multiset commitment; it is not byte-equal to zcashd’s, by design.)
Transparent-address history RPCs:
get_address_balance
get_address_deltas
get_address_txids
get_address_utxos.
Block lookups by hash or height, subtree-root reporting, and non-finalised-state serviceability policy.
On-disk format (finalised-state DB → v1.2.0)
Promotes the spent outpoint index to core data and adds the txout-set accumulator.
Upgrading triggers a one-time in-place migration (resumable) — no full rebuild required.
zcashd compatibility (zaino-serve / zaino-fetch)
z_validateaddress passthrough, shipped pre-deprecated for bugwards compatibility.
Packaging
LightdInfo.version now reports the running zainod binary version rather than the library version.
Container images published under the new zainod Docker Hub repository (the 0.3.1 re-release tag).
Full per-crate detail (pinned to the release tag):
Hi all, just wanted to share a real-world bootstrap experience running zebrad 5.0.0 + zainod 0.3.1 on a self-hosted node (i7, 32GB DDR5, NVMe SSD via WSL2 ext4 — ~5.9 GB/s write speed).
The main bottleneck identified via htop was single-threaded RPC fetching in sync_to_height — one core at ~56%, zebrad nearly idle, disk barely used.
Replacing the sequential loop with a buffered(64) tokio prefetch pipeline (parallel block fetches, sequential writes) gave roughly x8–x10 speedup in the Sprout zone (17k–120k blocks). The remaining bottleneck is IndexedBlock::try_from() which is inherently sequential due to chainwork dependency.
Current rate in the 120k–200k zone: ~70–80 blocs/min with one core fully saturated. Estimated total bootstrap: several days on high-end hardware.
The patch is posted on GitHub issue #860. Would love to see DbV2 or signed snapshots move forward — bootstrap time is a real barrier for self-hosted node operators wanting sovereignty over their ZEC wallet.
Regarding signed snapshots, Zec.rocks is independently working towards providing monthly signed snapshots of Zebra, Zaino, and Lightwalletd caches to speed up sync performance for anyone comfortable with using them.
I’ll try to get our Zaino snapshot published before July, but we have been publishing Zebra snapshots on our zcash-stack Github for over a year, anyone is welcomed to use those. The July update is that they will be signed.
Thanks for the update on snapshots! That’s great news for users who trust zec.rocks.
However, for users who want full sovereignty (which is kind of the point of running your own node), the real issue remains: bootstrap time on high-end hardware is several days due to single-threaded processing in sync_to_height.
On an i7-13620H (10 cores, 32GB DDR5, NVMe SSD at 5.9 GB/s), we’re seeing ~50-80 blocks/min in the 120k-400k zone with one core at 99% and 15 cores idle. A buffered(64) prefetch patch gave x8-x10 speedup in the Sprout zone — details on GitHub issue #860.
Any plans to address the multi-threading limitation in zaino’s indexing pipeline?
the two backend services merged into a single NodeBackedIndexerService; the config selector renames state → direct and fetch → rpc (old names still accepted)
post-quantum TLS: outbound handshakes now lead with the X25519MLKEM768 hybrid key exchange
Both are working — they’re the same two connection modes as before, renamed and now selected at runtime inside one service instead of by separate service types.
rpc (formerly fetch) talks to the validator over JSON-RPC. It’s the default, and it works with zebrad on another machine, or even another Zaino instance. If you’re unsure, use this one.
direct (formerly state) reads Zebra’s state database directly through its ReadStateService. It’s more efficient, but it requires zainod to run on the same machine as zebrad, with zebra_db_path pointed at Zebra’s cache directory.
The old values state and fetch are still accepted as aliases, so existing zainod.toml files keep working unchanged — but new configs should use direct / rpc.