dot product

Checkpoint: CP-002 Status: QUEUED — not yet run. No results exist for this experiment.

Question

How does zkVM proving cost scale with a large dot product, 10^3 to 10^6 elements — and what is the marginal cost of one proved multiply-accumulate?

Why it matters

Experiment 001 showed the cost is dominated by a fixed charge at small sizes. CP-002 measures the slope — the number that lets us extrapolate proving cost to any model size without running the model. It is also the first head-to-head between a general zkVM and a specialised argument (H3).

Gate

Ready to start. Depends only on E001, which is complete.

---

This is a stub. It exists so the roadmap's structure is visible, not to imply work has been done. Nothing in ../../benchmarks/results/ refers to it yet.

Research question (CP-002)

How does zkVM proving cost scale with the size of a dot product, and what is the marginal cost of one proved multiply-accumulate?

y = Σ xᵢ·wᵢ for n = 10^3, 10^4, 10^5, 10^6.

Why this specific shape

E001 established that SP1's cost at small sizes is a fixed per-proof charge. The number that actually lets us predict anything about neural inference is the marginal cost per proved arithmetic operation, because a forward pass is, to first order, a very large number of multiply-accumulates. Once we have seconds-per-MAC we can extrapolate to any model size without running it, and that extrapolation is the input to every economic decision downstream.

A dot product is the right vehicle: it is one MAC repeated, it is the inner loop of matrix multiplication, and it has no non-linearity to confound the measurement.

Hypotheses

H2a. Above the fixed-cost knee identified in E001, proving time is linear in n with a stable slope over at least three decades.

H2b. The zkVM charges many RISC-V cycles per useful MAC — the ratio of proved cycles to useful arithmetic operations is ≥ 5×, because loads, index arithmetic and loop control are all proved alongside the arithmetic that matters. This "cycle tax" is the core inefficiency of the general-zkVM approach and quantifying it is the main deliverable.

H2c (tests H3). A specialised argument for the same statement — a sumcheck or inner-product argument over the same vectors — beats the zkVM by ≥ 100× in prover time, because it charges for the arithmetic relation rather than for a RISC-V execution trace.

H2d. Verification cost stays roughly flat in n for compressed proofs, so R_verify improves with problem size. If so, the general-zkVM approach is economically hopeless for small jobs and merely very expensive for large ones — which is a different and more actionable conclusion than "ZK is expensive".

Predictions (record before running)

Measurement additions over E001

1. Integer and fixed-point variants. Real inference is not u64. A fixed-point variant with an explicit rescale per MAC measures what quantisation costs inside a zkVM.
2. Compressed mode throughout, since E001 suggests core proofs are the wrong product for a coordinator verifying every job.
3. Prover memory as a first-class result. E001 hit 8.3 GB peak RSS at 5M cycles. If memory scales with cycles, the binding constraint on provable job size is RAM, not time — which changes what hardware a Nodus prover needs and therefore what it costs.
4. A second zkVM (RISC Zero) so that the slope is not an SP1 artefact.

What would falsify the whole general-zkVM branch

If cycles-per-MAC is ≥ 10 and the marginal proving rate stays near E001's measured rate, then proving a single 0.5B-parameter forward pass lands in the range of years of CPU time. If that extrapolation holds, general zkVMs are removed from the Nodus candidate set for inference (they may survive for small control-plane statements), and the programme's ZK effort moves entirely to specialised arguments. Making that call on measured evidence is the point of E002.