A Unified Framework for Contract-Validated Benchmarking of Zero-Knowledge Proving Systems

Matej Hulek, Martin Peresini and Ivan Homoliak, all of Brno University of Technology. ePrint 2026/1729, received 18 August 2026. The second source in this spoke whose numbers were produced by people with no system in the comparison, and the first to include the zkVM generation.

The problem it names, which is the one zk-bench left standing

zk-bench established that a prover timing does not identify a system: the arithmetic library underneath is worth 14.02× on SHA-256 proving, and a tool's ranking can reverse between two test vectors on circuit optimizations alone. That finding cuts against comparability itself. If two systems express a workload differently, are they even solving the same problem?

This paper's answer is workload-specific semantic contracts. Each benchmark declares the public claim being proved as structured fields; the host checks those fields and the agent's verification flag before a result counts. So systems "are compared on the same declared public claim, even when their circuits, traces, or guest pipelines differ." That is the missing piece — not a faster harness, but a definition of what makes two runs the same run.

What is in it

Eight systems, spanning three generations that this spoke has been describing separately: Groth16, ICICLE, Halo2, Plonky3, Winterfell, Nova, RISC Zero (with CUDA and Groth16 wrapping), and SP1 (with and without AVX). Hardware is stated: 8 CPU cores, plus CUDA GPU acceleration for the systems that support it.

Reported findings:

• Plonky3 and Winterfell have the smallest across-case proving time and RAM.
• Groth16 and ICICLE produce sub-kilobyte proofs.
• Winterfell has the lowest host verification time.
• The zkVMs (RISC Zero, SP1) "exchanged larger proofs and higher memory for programmability" — the cost of running a general program instead of a hand-written circuit, priced.
• GPU acceleration helps most after fixed setup costs are amortized, which is a statement about when to reach for it rather than whether.

What it closes, and what it does not

Most-wanted #22's successor asked for "a third party running Binius against Flock, or either against Plonky3, on stated hardware." This delivers the third party, the stated hardware, and Plonky3 — and holds neither Binius nor Flock. So the edge is half closed for the third time, which is now the finding rather than a disappointment: independent benchmarking in this field consistently arrives one generation behind the systems this spoke is tracking. zk-Bench (2023) predated Binius; this one (2026) covers zkVMs and still not binary fields.

The nearest thing found while hunting is BinarySpartan (Setty, Microsoft Research, ePrint 2026/1656), which borrows "Binius64's byte lookup tables" and reports BLAKE3 at 547,000 hashes/s, SHA-256 at 255,000 hashes/s, and a single SHA-256 of a 2 KiB message in 6.2 ms. Search summaries attribute throughput ratios against Plonky3 and Binius64 to it; the abstract as read carries no such ratios, so they are not recorded here. In any case its author has a system in the comparison, which is the arrangement zk-Bench exists to correct.

The residue

What Plonky3's position means is now genuinely uncertain in a useful way. It leads on proving time and RAM in the one independent harness that measures it, and binius's own material claims a 2.3× margin over Plonky3 — a first-party number, inside a confounder zk-bench measured at 14×. Two claims, one independent and one not, about the same baseline, and no run that settles it.

Related

zk-bench · binius · flock · concrete-efficiency · succinct-argument · binary-fields · irreducible · synthesis