Skip to content

Add benchmarks for the IVC SNARK recursive circuit #3412

Description

@jpraynaud

Why

We have no performance baseline for the recursive IVC circuit. Its prover dominates the IVC proving time and constrains the minimum epoch duration, which leaves us unable to detect regressions or to measure the impact of the optimizations we make.

What

Add Criterion benchmarks for the recursive IVC circuit prover and verifier in the mithril-stm library, following the structure of the existing halo2_snark benchmarks.

The benchmarks delegate to the production IVC proof-system code (setup, preparation, proving, verification, and accumulator folding) through a thin benchmark-internals-gated façade, so the measured operations are the same code paths run in production. They cover the small committed (degree-13) inner-certificate configuration across the three transition paths (genesis, same-epoch, next-epoch), including the off-circuit accumulator step, with cold and warm caches and the setup cost reported separately.

How

  • Move read-only IVC asset layer out of the test tree for benchmark reuse
  • Add additive genesis benchmark fixture asset for IVC benchmarks
  • Add an ivc_halo2_snark benchmark in mithril-stm/benches, gated behind the future_snark and benchmark-internals features, driven by a benchmark-internals façade that delegates to the production IVC proof-system code (setup / preparation / proving / verification / accumulator)
  • Use the small committed (degree-13) non-recursive certificate as the inner circuit; source fixtures from the committed golden assets plus one additive genesis fixture asset (existing golden assets unchanged)
  • Benchmark the recursive circuit prover (create_proof, Poseidon and Blake2b transcripts), excluding the non-recursive circuit prover and the preparation step from the measurements
  • Benchmark the recursive circuit verification: the KZG opening and the full verification (opening plus folded-accumulator check)
  • Benchmark the off-circuit accumulator fold per transition path (genesis / same-epoch / next-epoch)
  • Measure with cold and warm caches (SRS and circuit keys) through the production providers and report the setup cost separately
  • Update the SNARK book with the results

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions