What Sub-10ms STARK Verification Actually Requires
"Sub-10ms verify" shows up in this project's docs and diagrams. Here's exactly what was measured, how, and — just as importantly — the trace size where that number stops holding.
A benchmark claim is only as useful as its methodology. Here's the actual one, so it's reproducible rather than taken on faith.
The measurement
Ten back-to-back runs of the real zkvm CLI binary, each a fresh process, verifying a real proof of examples/fibonacci_like.zkasm (a four-instruction program: INIT 5, ADD 3, MUL 2, SUB 4):
per-run ms: [6.01, 5.34, 5.58, 5.22, 5.19, 5.85, 5.71, 5.36, 5.71, 5.2]
min: 5.19ms avg: 5.51msThat's the full CLI invocation — process startup, argument parsing, reading the proof file, re-executing the program to build expected public inputs, and the actual STARK verification — not an isolated micro-benchmark of just the cryptographic check. "Sub-10ms" is accurate for this measurement with real margin; the more precise number is "about 5.5ms on this hardware, for this program."
What's actually cheap here
STARK verification's whole value proposition is that it's supposed to be dramatically cheaper than re-running the computation. For a four-instruction program, "re-running the computation" is also basically free, so this particular measurement doesn't demonstrate that asymmetry — it demonstrates that the fixed overhead (process startup, FRI verification setup, Merkle root checks) is small in absolute terms at this trace size.
Where the number stops applying
The proving-time benchmarks already show proving cost growing worse than linearly with trace size (2,000 instructions: ~6s; 4,000: ~32s). Verification scales differently than proving — but re-execution, which this system's verifier always does first, scales linearly with instruction count regardless of the STARK's own asymptotics. At the 2,000-instruction ceiling this project's HTTP service now enforces, verification includes re-executing 2,000 instructions before the cryptographic check even starts — a meaningfully different number than 5.5ms, and one that hasn't been measured and published here yet.
The gap this leaves: no benchmark suite exists yet correlating instruction count with proving time, verify time, proof size, and memory, across the range this system actually supports. That's explicitly listed as unfinished work — see docs/ROADMAP.md — rather than a number quietly assumed to hold everywhere it's cited.