TL;DR
- Zebra is the fastest Zcash node: 9.6× faster than Zebra 7.0.0 and 3-4× faster than Zakura on prepared mixed blocks.
- Built from miner feedback: our initial work after listening to miners at Zcon7.
- Made for mining: less waiting and better mining pool support.
- Ready to test: try Zebra Ándale and help shape the release.
We listened to miners and made Zebra faster
At Zcon7 in Cancún, one of the Zcash Foundation’s biggest takeaways came from listening to miners. The messages were clear: miners told us that Zebra took too long to turn new transactions into work, too long to accept a solved block, and too long to tell the rest of the network about it. Node operators told us that initial sync took too long and used too much memory.
Zebra Ándale, version 7.1.0-alpha.0, is a performance release built for the people who keep Zcash running: miners, mining pools and the operators who run nodes for them. It is faster than Zebra 7.0.0 at every mining job we timed, and faster than Zakura v1.7.0 at building templates, accepting pre-validated blocks, and relaying them. It is the first step in a broader effort to improve Zebra, and it is available today.
We gathered as a team during Zcon7 and agreed that the right response was not a roadmap but a release. Ándale is that release. The name is Mexican Spanish for “come on, hurry up”, and that is what this release does. This post explains what changed, why it matters, and who benefits.
Making Zebra Faster by Cutting the Wait
On top of a full validator’s regular work, a mining node builds block templates for miners and accepts their solved blocks, both over RPC. Three things decide how fast it is.
- How quickly it generates a block template from a new chain tip or a change in the mempool.
- How quickly a block is validated once it is submitted, usually after a solution is found (approx. 25 seconds after template generation).
- How quickly that validated block, the new chain tip, is sent to Zebra’s peers.
Zebra Ándale is faster at all three.
Zebra 7.0.0 checked for verified transactions every five seconds and rebuilt the block template on a separate five-second timer. Proof batches waited 100 milliseconds for more work, blocks a pool had already validated were verified again, and miners waited for the disk write.
Zebra Ándale reacts instead of waiting. Verified transactions wake the mempool immediately, and each change triggers a template rebuild, at most about once a second under a burst. Proof batches start after 5 ms of quiet. A block matching a proposal the pool already validated skips repeat verification, and the node answers the miner before finishing the disk write. A large burst that took over eight minutes to reach a template now takes about four seconds.
Improvements
Zebra Ándale changes the mining path in five ways without relaxing any validation rules. Every block is still validated, and work already done on the exact same bytes is not repeated. What changes is when the work happens, whether it happens multiple times, and how much of the machine it uses.
| Improvement | What changed | Who benefits |
|---|---|---|
| React right away | Verified transactions wake the mempool instead of waiting for a poll. Templates rebuild when the mempool changes. Proof batches start after 5 ms of quiet instead of 100 ms. | Miners and pools: fresh work within seconds of a burst, and a new template about 2 ms after an empty peer block. |
| Send less over the wire | Zebra can relay compact blocks: the block header, a short ID for each transaction, and the coinbase. Peers rebuild the block from their own mempool and fetch only what is missing, falling back to the full block if needed. | The network: a 2 MB block whose transactions peers already hold can shrink to ~20 KB, so opted-in peers download 100x less data. |
| Reuse what is already verified | A pool can ask Zebra to validate a block before mining it. When that exact block comes back solved, Zebra doesn’t repeat the work and checks only what can change: proof of work, time, size and parent. A peer’s block reuses the mempool’s verdicts on its transactions. | Pools that validate proposals: a solved 1.9 MB block is accepted in about 25 ms instead of 264 ms. |
| Answer first, write later | The node reports a submitted block as accepted, and announces it to peers, before it finishes writing the retired block to disk. The database work still happens; the miner just stops waiting for it. | Miners: a faster reply to submitblock. The network: blocks reach peers sooner. |
| Use the whole machine | Sapling verification now spreads across more cores. Verifying keys are built in the background at startup. Memory copies in the state layer were removed. | Node operators: 2.6 times faster full verification and a third less peak memory. Wallets and indexers: double the RPC throughput for one client. |
The first two rows are where the largest factors come from, because they change when work starts rather than how fast it runs. That is why the gains are so large: a timer that fires every five seconds costs the same whether your machine is fast or slow.
The Numbers
These measurements compare Zebra Andale (7.1.0-alpha.0) vs Zebra 7.0.0 vs Zakura.
The largest speedup, 124× faster for a burst of transactions to reach a template, comes from removing timer delays in Zebra 7.0.0, rather than computing 124 times faster.
- Against Zebra 7.0.0, prepared mixed blocks: 9.6× faster, 17 ms against 164 ms, saving 147 ms per block.
- Against Zakura v1.7.0, prepared mixed blocks: 3-4× faster, 17 ms against 65 ms, saving 48 ms per block.
- Small blocks: most Mainnet blocks are small, and on those the development build answers in about 2 ms, whereas 7.0.0 took 12 ms.
- New work: an empty peer block becomes a template in 2 ms, where Zakura took 2.6 s.
- Transaction bursts: 1.9 MB of transparent transactions reaches a template in 4.1 s, whereas Zebra 7.0.0 took over eight minutes, and Zakura took 9.9 min.
- Solved blocks: a pre-validated block is accepted in 25 ms, whereas Zakura took 99 ms.
- Relay: an empty solved block reaches a connected peer in 2.6 ms, whereas Zakura took 1.1 s.
Most figures in these charts come from our own benchmarks. For the live view, our public dashboard sends every new Mainnet block to all three nodes at once, with no peers and empty mempools, so you can watch what happens block by block. The dashboard does not measure the prepared case, so it will show different numbers from those above.
Your Feedback Shapes What Comes Next
This release grew out of candid feedback from miners, pool operators, and node operators at Zcon7. Thank you for telling us where Zebra needed to improve. We’ve addressed the first set of concerns, and we’re working through the rest.
If you run Zcash mining infrastructure, please test it. Run it beside 7.0.0, watch the metrics, and tell us what you find. Your reports decide what goes into the stable 7.1.0 release and what we fix first.
Further reading
- Zebra on GitHub: source, releases and issues
- Live Mainnet comparison: every new Mainnet block sent to Zebra 7.0.0, a development build of Zebra and Zakura at the same time
- See the Zebra book and Getting new work to mining pools for how to mine Zcash with Zebra
- Mining on Zebra by Marek: all the technical details behind these improvements and how we measured them. See zebra-benchmarks for more details.