Concrete efficiency
The distance between a cryptographic scheme that exists and one that runs, and the study of how a construction travels that distance. This spoke's organizing question, and the axis the three founding sources agreed on before they agreed on anything else.
Asymptotics decide whether a scheme is possible. They do not decide whether anyone can use it, and the gap is not a rounding error: a polynomial-time construction can still take longer than the age of the universe on any real input diamond-io.
The founding corpus is one question at three magnitudes
| source | the frontier it reports | measured in |
|---|---|---|
| diamond-io | galactic runtime → planetary runtime; still infeasible | assumptions and asymptotics |
| binius | 8,192 Keccak-f in 5.90 s, vs 13.8 s | seconds on a benchmark |
| flock | ≈250× native, 42.1k SHA-256/s on one core | multiples of native execution |
Read together they describe a single trip. diamond-io is at the stage where the argument is whether a scheme can ever be run and the currency is how brave its hardness assumptions are. binius and flock are at the stage where it obviously runs and the argument is a factor of 9 on a laptop. Nothing in the corpus sits in the middle yet, which is a gap rather than a shape (synthesis).
Every gain is a trade
No result here is a free improvement. The recurring move is to spend one resource to buy another:
- Prover time against proof size. binius beats Plonky3 on both prove and verify time and pays with
a 5.574 MiB proof against 4.010 MiB. flock ships explicit
fastandslimvariants — 386 KiB or 200 KiB at 2¹⁴ Keccak permutations, and you choose. - Generality against speed. flock proves batches of one Boolean circuit, and that restriction is the source of its speed: batching removes the permutation and memory-checking arguments general systems must carry. It does not support a general glue circuit, and says so.
- Speed against safety. diamond-io buys its improvement with assumptions its own summarizer calls "novel and risky," one of them non-falsifiable in Naor's sense.
- Proof size against verification, via recursion. Both proof-system papers name recursive composition as the way to buy back what they gave up: prove fast with big proofs, then prove that verification with a slow small-proof system.
Reading a result here therefore starts by asking what it spent, not what it gained. A headline number with no stated cost is an incomplete claim.
A second thing a headline number has to state (added 2026-08-20). zk-bench benchmarks 5 SNARK
tools over 9 arithmetic libraries on 5 named AWS instance types, and finds the substrate dominates the
scheme: an MSM of size 2²⁰ is 9.44× faster in gnark-crypto than in ffjavascript, which carries all
the way up to gnark proving SHA-256 14.02× faster than snarkjs on the same circuit and curve. The
same tool's ranking also flips with the circuit — halo2 is 8.64× slower than gnark on one test vector
and 1.09× faster on another — and hardware alone moves proving by up to 50% one way or 40% the other,
depending on the tool. Set beside binius's 5.90 s against 13.8 s, the spread available from
changing the library underneath is larger than the result being reported. A prover timing without an
arithmetic backend and an instance type attached does not identify a system.
And a third: what makes two runs the same run (added 2026-09-03). contract-validated-zk-bench argues that stating the backend and the instance type is not sufficient, because two systems can express one workload as different circuits. Its answer is a declared semantic contract — the public claim as structured fields, checked by the host before a result counts. Its eight-system run puts Plonky3 and Winterfell lowest on proving time and RAM, Groth16 and ICICLE under a kilobyte of proof, and prices the zkVM trade directly: RISC Zero and SP1 pay larger proofs and more memory for programmability.
What "smallest field" and "batch" have in common
Both proof-system sources get their speed by shrinking the problem rather than working faster on it. binary-fields shrink the element: stop paying to carry a bit inside a 256-bit group. Batching shrinks the protocol: stop paying for permutation arguments that only general circuits need. In both cases the overhead being removed was structural, and it had been there because the framework was designed for something more general than the workload people actually run.
That is also why the application is not incidental. The workload driving all of it — hashing, in bulk, for rollups and post-quantum signatures — is what makes the specialization worth doing.
The measurement problem
Every number in this corpus is self-reported. Authors benchmark their own system against systems they did not write, choose the hardware (flock: one Apple M4 Max), choose the batch size, and choose which competing configuration to run. flock does the honest things available to it — reporting each system at the batch size where that system peaks, and disabling ARM's SHA-256/SHA3 acceleration so the native baseline is a like-for-like comparison — and it is still the authors measuring their own result.
Nothing in the corpus is an independent reproduction. That is the field's norm rather than a failing of these papers, and it is this spoke's first growth edge (synthesis).
Related
flock · binius · diamond-io · succinct-argument · binary-fields · indistinguishability-obfuscation · synthesis