First, some news from just after this update’s window: the NU6.3 (Ironwood) network upgrade activated on Mainnet on 28th July — we’ll cover it properly in the next update.
Over the last two weeks we published four Zebra releases — v6.1.0, v6.2.0, v6.2.1, and v6.2.2 — containing security fixes, a new experimental zcashd-compat mode for services migrating off zcashd, and the first releases produced by our newly automated release process. We also updated our DNS seeders ahead of the Ironwood activation, and made good progress on two larger efforts: serving light wallets directly from Zebra, and a much faster initial sync.
Security
Zebra v6.1.0 and v6.2.1 include fixes for several security issues. The v6.1.0 issues could let peers briefly stall a node’s sync in specific situations. v6.2.1 fixed an issue where a peer sending invalid data could delay a node from downloading the newest block, and added protections against peers trying to waste a node’s CPU: transactions that don’t pay the required fee are now rejected before any expensive checks run, and peers that send transactions with invalid proofs are banned. None of these issues put funds at risk or affected consensus. We recommend node operators upgrade to the latest release; the release posts have more details.
CI / DevOps
Much of our CI and DevOps work this period went into automating Zebra’s release process, and the four releases above were the first ones shipped through it. Releases are now prepared and published largely automatically: we built a reusable Cargo Release action that can safely resume a partially failed publication of the workspace’s crates, gated publishing on complete changelogs, and made changelog finalization automatic. We also restored automated checkpoint update PRs and improved merge queue throughput.
Other Zebra work
Zebra v6.2.0 introduced an experimental zcashd-compat mode, aimed at exchanges and other services that still depend on the zcashd wallet now that zcashd has reached end of support. In this mode, Zebra acts as the consensus node on the Zcash network while a supervised zcashd wallet build runs alongside it, keeping the familiar zcashd wallet RPC and ZMQ interfaces available. It ships with an interactive installer and a new Zebra Book chapter, and builds on work from the Zakura project — see our blog post Zebra, Zakura, and the road through NU6.3 for the background.
We also fixed the indexer gRPC streams used by Zaino and Zallet so that a slow consumer is asked to catch up instead of being disconnected, made freshly started nodes save their discovered peers to disk sooner for faster restarts, and updated Zebra’s documentation to reflect zcashd’s end of life.
Work in progress
Two larger efforts are underway but not merged yet. The first is a lightwalletd-compatible gRPC server built into Zebra, which would let light wallets connect to a Zebra node directly without running a separate lightwalletd instance. The second is a new initial block download engine that downloads and verifies checkpointed blocks far more aggressively in parallel — early testing has synced the first 1.7 million Mainnet blocks in about 90 minutes. Both are drafts and still subject to change.
Work on other repositories
On zeeder, we updated the crawler to only recommend peers that are ready for NU6.3 ahead of the Ironwood activation, and released this as v1.5.0.
Thanks to external contributors
Thank you to @CodeMongerrr for two security hardening fixes that shipped in v6.2.2: keeping the Elasticsearch password out of Zebra’s startup log output, and making the zebrad-log-filter helper script safe against crafted log lines. Thanks to @aphelionz for adding the getstandardfee RPC, and to @zmanian for making the getblock, getblockheader, and gettxout RPCs return consistent results when the chain changes mid-request.
Thanks also to @daira for fixing Zebra’s Testnet block templates so they no longer trigger spurious minimum-difficulty blocks, and, on FROST, to @StackOverflowExcept1on for raising the minimum supported Rust version and updating the RustCrypto dependencies.
And also thanks to @syszery, @weifanglab, and @nuttycom for their contributions.