Why is prover cost the number that matters?
A proof system is judged on three costs: how long the prover takes, how long the verifier takes, and how large the proof is. Two of those stopped being the constraint a while ago. Reed-Solomon based schemes already give small proofs and fast verification; the expensive part is producing an evaluation proof for a large polynomial, and that cost feeds directly into prover time, which is the number that decides whether a proving system is deployable at all.
The shape of the field's output follows from that. Over three consecutive months on our zero-knowledge desk, three separate results pointed at the same target: a scheme that moved evaluation cost off the large polynomial, a folding construction that dropped the SIMD requirement, and a scheme that attacked the first folding round directly. Prover cost is where the work is because it is the one cost still setting the boundary of what can be built.
Where in the protocol does the cost actually sit?
In the first rounds, on the largest objects. Hash-based polynomial commitments built on FRI achieve short proofs by recursively folding Reed-Solomon codes, and the first few folding rounds operate on the largest codewords. They dominate prover work, which means an optimisation spread evenly across all rounds is mostly spent in the wrong place.
ReedWeave attacks that round by combining interleaving with folding rather than choosing between them. A polynomial of degree d is decomposed into m smaller components, each Reed-Solomon encoded over a common domain, and under the authors' decomposition a random linear combination of those codewords is exactly an m-ary folding. The scheme opens with one wide fold and then continues with ordinary binary folding as in FRI. The expensive opening step becomes interleaved encoding rather than full Reed-Solomon encoding, and prover cost falls from order d log d to order d log(d divided by m) at constant code rate. A second property matters more to implementers than the asymptotics: the construction works for arbitrary m, which relaxes the smoothness requirement on the underlying field by a factor of m and so does not force a field choice on the system built around it.
The same logic shows up in sumcheck. Its first and most expensive round, the univariate skip, grows by a logarithmic factor in systems over binary fields, because under Reed-Solomon the product of two binary messages is no longer binary. A multiplication code built from algebraic geometry that is binary-preserving removes that growth. The explicit code in the paper, over the field of 2 to the 128, carries 64-bit messages to binary product messages of length 222 with product-code relative distance greater than 1 minus 2 to the minus 119, and the part of the product message the prover actually sends is more than three times smaller than with Reed-Solomon as used in practice.
What do these savings cost?
| Result | What it changes | Measured gain | What it costs |
|---|---|---|---|
| ReedWeave | An m-ary first fold instead of a binary one | Prover cost from order d log d to order d log(d/m) at constant rate | None stated; relaxes field smoothness by a factor of m |
| LiftWHIR | Splits evaluation into a proximity test on a shorter codeword and a smaller evaluation | Evaluation phase 169 ms, 6.7x; total prover time 1,474 ms, 1.55x | Verification 0.40 to 0.51 ms and proofs 1.33x larger, at rate one quarter |
| AG skip | A binary-preserving algebraic-geometry code inside sumcheck | Skip round 2.36x and whole zerocheck 1.65x at 2^32 constraints | None stated; requires constructing a genus-95 curve |
| NeutronNova | Folding organised around zero-check | A 2^20-constraint SHA-256 circuit folded in 91 ms, roughly 10x Nova | None stated; recursive verifier needs three scalar multiplications |
| Neo and SuperNeo | Lattice-based folding on Module-SIS with Ajtai commitments | No timings published | Claims are asymptotic and structural only |
| Symphony | Folding without a hash inside the verified circuit | Prover reads its input in O(log log n) passes | No timings and no baseline |
Two rows have no numbers in them, and that is why they are here. Symphony avoids embedding a cryptographic hash function inside the circuits being verified, which is the recurring cost in recursive proof systems: the verifier has to be expressed as a circuit, the verifier hashes, and hashing inside a circuit is expensive. Removing it is a real structural result. But the abstract gives no timings and no baseline against Nova, Plonky3 or anything else a reader might be running, and Neo and SuperNeo are in the same position. For anyone choosing a stack, the useful question is not which paper claims the better asymptotics but which has been measured on the same hardware, and none of them had been.
Does the improvement survive being put inside a real system?
That is the test worth applying and the one least often reported. LiftWHIR is the clearest case we have covered: instantiating Spartan with LiftWHIR rather than WHIR speeds up proving by 1.9 times. An asymptotic improvement in a commitment scheme only matters if it holds when placed inside a proof system, and here it did. The AG skip was measured the same way, inside the Flock proof system rather than in isolation.
NeutronNova offers a different kind of evidence. Since its first version appeared, other work has built on it for space-efficient SNARKs, packed sumcheck protocols and client-side proving. A construction other people build on has been read carefully by people with a reason to find fault in it, which is worth more than a benchmark.
What should you ask before believing a published number?
Ask what hardware it ran on, and whether anyone else has reproduced it. One Ethereum Research thread we covered is a model for how this should go. The author published measurements specific about hardware: on a 12-thread AVX2 laptop one query class took 10.734 seconds for a 971,732-byte proof, while on 24 threads with AVX-512 the same query took 6.905 seconds. A heavier class ran 34.938 and 21.053 seconds against proofs of 1,081,108 bytes.
What happened next is the part to copy. A second participant reproduced every published figure on different hardware, then changed one parameter, the BaseFold query count, from 133 to 132, to see what would happen. The system recalculated its security boundary rather than carrying the published conclusion forward unchanged. Does the claim move when the parameter moves is a test a reader can actually run.
The same author separated 127 bits provable from 127 bits conjectured instead of rounding both to 128, and stated plainly that the claims rested on premises without external audit. That is unusually careful language for a protocol announcement, and its absence elsewhere is informative.
What does cheaper proving actually unlock?
Less than the announcements suggest, and something more useful. Cheaper proofs do not make new things possible so much as make old things affordable, and those are different lists. The applications that come into range share a shape: a verifier who cannot be trusted with the input, a computation that is expensive to repeat, and a result that must be checkable by a third party later.
- Compliance attestation over private ledgers, where the auditor learns the conclusion and nothing else.
- Cross-chain state verification without a trusted committee in the middle.
- Identity claims that reveal a predicate rather than a document.
Where the cost still bites is per-action proving. Verification is cheap and proving is not, so any design that needs a proof per user action rather than per batch remains uneconomic outside narrow cases. Recursion helps, at the price of a considerably harder system to reason about.
What gets worse as proving gets cheaper?
Two things, and neither is a performance number. Most hardware acceleration work now targets one of two architectural approaches. Costs fall accordingly, and so does the number of independent implementations a protocol can fall back on. For a system whose security argument assumes plural provers, that concentration belongs in the threat model rather than being assumed away.
The second is that trust in the prover becomes a correctness question. An OpenZeppelin review of the Miden contract library found, among sixty issues, a foreign procedure invocation reading state from a prover-chosen reference block rather than the current one, and a signed transaction summary that bound neither expiration nor reference block. Those are the class of finding that looks academic in a report and becomes an incident when somebody builds a bridge on top of it.
Questions
- Is prover time or verifier time the bottleneck in modern proof systems?
- Prover time. Verifier time and proof size have been good enough for production for some time, so prover cost is what decides which applications are possible — which is why every result covered here attacks the prover rather than the other two.
- Which round of folding should an optimisation target?
- The first. FRI-style schemes fold recursively and the first few rounds operate on the largest codewords, so they dominate prover work. ReedWeave opens with an m-ary fold for exactly this reason, cutting prover cost from order d log d to order d log(d/m) at constant code rate.
- How much faster can a better code make sumcheck?
- In the one measurement available, a binary-preserving algebraic-geometry code made the univariate skip round 2.36 times faster and the whole zerocheck 1.65 times faster at 2 to the 32 constraints inside the Flock proof system, with more than three times less data sent in that round.
- What does cheaper proving not fix?
- Per-action proving. Verification is cheap and proving is not, so a design that needs a proof for every user action rather than one per batch stays uneconomic outside narrow cases. Recursion helps, at the cost of a system that is much harder to reason about.