bench: add criterion benchmark suite and CI workflow

[oxarbitrage]

Motivation

Zebra had minimal benchmarking coverage (only block serialization and RedPallas signatures). This makes it difficult to evaluate PRs for performance regressions or improvements — for example, PR #10436 removes groth16 abstractions but had no way to verify it was performance-neutral.

Solution

Adds a comprehensive benchmark suite covering Zebra's most expensive code paths, plus CI automation for tracking and comparison.

New benchmarks

• Groth16 (zebra-consensus/benches/groth16.rs) — Sprout JoinSplit proof verification, single and unbatched at sizes 2-64, plus input preparation cost
• Halo2 (zebra-consensus/benches/halo2.rs) — Orchard proof verification, single and unbatched at sizes 2-32
• Sapling (zebra-consensus/benches/sapling.rs) — both unbatched and true batch verification at sizes 2-64 using sapling_crypto::BatchValidator
• Transaction (zebra-chain/benches/transaction.rs) — per-version (V1-V5) deserialization and serialization from real mainnet blocks

CI workflow (.github/workflows/benchmarks.yml)

• workflow_dispatch: runs all benchmarks, stores results on gh-pages via github-action-benchmark, generates a summary table in the Actions UI
• PR comparison: adding the C-benchmark label to a PR runs benchmarks on both base and PR branches, posts a critcmp comparison table as a PR comment

Benchmark dashboard

Adds a step to book.yml that copies benchmark data from gh-pages into the docs output, making the historical trend chart available at zebra.zfnd.org/dev/bench/.

Test data

All benchmarks use real transactions from the hardcoded mainnet blocks in zebra-test. Items are cycled (repeated) to fill larger batch sizes — this is valid because cryptographic verification cost is constant per proof regardless of specific bytes. This limitation is documented in each benchmark file.

Alternatives considered

• Bencher.dev — purpose-built SaaS for continuous benchmarking with statistical regression detection and confidence intervals. Free for open source. Could replace both github-action-benchmark and critcmp with a more sophisticated solution.
• Codspeed — runs benchmarks in their own infrastructure for consistent results, eliminating CI runner noise. Also free for open source.

We chose github-action-benchmark + critcmp as a lightweight starting point with no external dependencies. Migration to Bencher or Codspeed can be evaluated as the suite matures and if CI runner variance becomes a problem.

Test plan

• All benchmarks compile and produce valid output locally (cargo bench, cargo criterion --message-format=json)
• CI workflow tested end-to-end on the benches branch (successful run)
• Benchmark data stored on gh-pages branch
• Used locally with critcmp to evaluate PR cleanup(zebra-consensus): remove remaining groth16 abstractions #10436 — found zero regressions and 8.65x V5 deserialization improvement

AI disclosure

Used Claude Code for benchmark implementation, CI workflow development, and testing.

[oxarbitrage]

Follow-up: Additional Benchmark Candidates

Analysis of the sync hot path identified several operations that are not yet benchmarked. These are candidates for follow-up PRs, prioritized by expected impact on sync time.

High Priority

Operation	Call frequency	Notes
Equihash solution verification	Per-block	Memory-hard PoW check, called for every block. Pure computation, easy to benchmark with test vectors.
Transparent script validation	Per-transparent-input	FFI to C++ zcash_script. Variable cost by script type (P2PKH vs P2SH). Requires previous outputs for sighash.
UTXO lookups	Per-transparent-input	RocksDB reads to fetch previous outputs. Often the sync bottleneck due to I/O. Harder to benchmark in isolation.
Sighash computation	Per-transaction + per-input	BLAKE2b-heavy precomputation and per-input finalization. Pure computation, easy to benchmark.

Medium Priority

Operation	Call frequency	Notes
Note commitment tree updates	Per-block (scales with output count)	Sprout/Sapling/Orchard incremental merkle trees.
Block finalization (state writes)	Per-block	Full RocksDB write batch: UTXOs, trees, indexes. Requires a populated database to benchmark realistically.

Easiest Next Steps

Equihash and sighash are the most straightforward to add — they are pure computation with no database or FFI setup required, and can reuse the existing test vector pattern from the current benchmarks.

Script validation and UTXO lookups are the biggest real-world sync bottlenecks but require more setup (FFI + previous outputs for scripts, populated RocksDB for UTXOs).