Zebra 6.0.0 Launch – Zcash Basis

Zebra 6.0.0: NU6.3 “Ironwood” Mainnet Activation

We’re releasing Zebra 6.0.0 at this time. That is the primary steady launch with help for the NU6.3 “Ironwood” community improve on Mainnet, setting the Ironwood activation peak at 3,428,143. It promotes the work first shipped in 6.0.0-rc.0 to a steady launch, and provides a mempool-verification safety repair, a number of networking and read-state fixes, and a brand new build-time dependency (libclang) made because the launch candidate. All node operators ought to improve earlier than NU6.3 prompts on Mainnet.

NU6.3 “Ironwood” Assist

Zebra 6.0.0 prompts the NU6.3 “Ironwood” shielded pool and v6 transaction format on Mainnet at peak 3,428,143 (anticipated round 13:00 UTC on July 28, 2026), alongside the Testnet activation peak of 4,134,000 launched within the launch candidate. (#10938) Ironwood provides a brand new shielded pool that reuses Orchard’s Motion and Halo2 proof system whereas including its personal word dedication tree, nullifier set, chain worth pool, and chain-history metadata, delivered via a brand new v6 transaction format.

The z_gettreestate, z_getsubtreesbyindex, and verbose getblock RPCs expose the Ironwood word dedication tree and its subtree roots from NU6.3 activation, and the getblockchaininfo and getblock valuePools fields embrace the Ironwood pool. (#10762, #10888)

This steady launch additionally updates the zcash_* and orchard crates from the pre-release variations used within the launch candidate to their launched NU6.3 variations.

For the total set of options first launched within the launch candidate (signed pre-built zebrad binaries, the block-notify command, resumable indexer streaming, and the 2 safety fixes GHSA-x6v8-c2xp-928m and GHSA-m9xx-8rcj-vmgp), see the 6.0.0-rc.0 launch notes.

Safety Advisories

GHSA-84j3-rw4c-gqmj: Excessive-Signature-Operation P2SH Mempool Verification (Reasonable)

Zebra ran full script verification on a mempool transaction earlier than a budget coverage checks that will reject a non-standard, high-signature-operation P2SH script, so a peer sending transactions which can be low cost to supply however costly to confirm might occupy the bounded verification capability and degrade the responsiveness of mempool and block verification whereas the load persevered. The affect is availability degradation solely, with no crash, consensus fault, invalid-block acceptance, or lack of funds, and it clears as soon as the load subsides. Zebra now rejects mempool transactions with non-standard clear inputs earlier than script verification, and script verification now runs on the shared Rayon thread pool fairly than blocking an async runtime employee; block (consensus) validation nonetheless runs full script verification.

Because of ouicate for reporting this concern, supplying a proof of idea, and refining the evaluation throughout triage.

That is the newest in a collection of mempool peer-fairness and resource-accounting hardening fixes, following the per-peer obtain cap (GHSA-4fc2-h7jh-287c) and the direct-push accounting repair shipped in 6.0.0-rc.0 (GHSA-m9xx-8rcj-vmgp).

Bug Fixes Because the Launch Candidate

Mempool Stays Lively By way of Sync Noise

As soon as the mempool has began, Zebra not clears it or cancels its queued transaction verification when a transient sign (which lower-work forks or stale friends can set off) reviews the node is way from the tip. Preliminary mempool activation nonetheless waits till Zebra is close to the chain tip. (#10929)

Peer Connections on the Chain Tip

Zebra not disconnects from friends that return empty FindBlocks or FindHeaders responses when the native node is at or close to the chain tip. (#10732)

Learn-State Syncer Startup Dangle

Fastened a read-state syncer startup grasp the place a co-located client whose finalized state had caught up previous the node’s non-finalized root would re-subscribe endlessly as a substitute of syncing, advancing just one block per newly mined block. (#10841)

Syncer Restarts

Fastened syncer restarts attributable to incorrect error downcasting; wrapped state-commit duplicate errors at the moment are accurately categorized as duplicate requests. (#10916)

Construct and Compatibility Adjustments

• New construct dependency: rocksdb was up to date to 0.24, and the bundled librocksdb-sys now at all times runs bindgen, so libclang is required at construct time (along with protoc and a C++ compiler), even when linking a system RocksDB by way of ROCKSDB_LIB_DIR. Set up libclang-dev (Debian/Ubuntu), clang (Arch), or the equal on your platform. (#10922)
• The workspace (libraries) minimal supported Rust model is raised from 1.85.1 to 1.88. The zebrad binary MSRV is unchanged at 1.91. (#10927)

State Database Format

Zebra 6.0.0 makes use of state database format 28.0.0, launched within the launch candidate for the Ironwood shielded pool. It is a major-version bump that migrates in place from the earlier main format, so no resync is required. Word that downgrading shouldn’t be supported, so if you wish to guarantee you’ll be able to rollback to an older model of Zebra if one thing goes mistaken, then backup the state earlier than upgrading Zebra.

Upgrading

You could find the discharge on GitHub, crates.io, and Docker Hub. As a result of this launch units the NU6.3 Mainnet activation peak, all node operators ought to improve earlier than Ironwood prompts to stay on the right chain.

Thank You to Our Contributors

This launch was made attainable by the work of @conradoplg, @Cosmos-Harry, @dannywillems, @jvff, and @upbqdn. Thanks on your continued contributions to Zebra.

Zebra is the Zcash Basis’s unbiased, Rust-based implementation of the Zcash protocol. Study extra at github.com/ZcashFoundation/zebra.