Research thesis

The programme's framing and its open questions.

Status: living document. Last revised 2026-09-01.

1. The question

Can we build a verification layer for distributed AI compute where the cost of obtaining trustworthy evidence is significantly lower than re-executing the computation, while reducing the amount of trust placed in the compute provider?

Two quantities appear in that sentence and the whole programme is about their ratio:

                cost of obtaining trustworthy evidence
    R  =  ----------------------------------------------
                  cost of the native computation

R is the headline metric of every experiment in this repository. It is not the only metric — evidence also has a strength, and strength without a cost figure is marketing — but no architecture is interesting to Nodus unless we can state both its R and exactly what it buys.

The re-execution baseline

There is always a trivially available verification mechanism: run the job again yourself. Its properties are:

property	value
`R`	~1.0 (2.0 for the full replicated system)
trust assumption	verifier must own hardware capable of the job
what it establishes	Claim A (correctness), for deterministic workloads only
what it does not establish	who ran it, when, on what, or how much it cost them

Any proposed mechanism that costs more than re-execution and does not offer something re-execution cannot (privacy, verifier weakness, non-determinism tolerance, succinctness for third parties) is economically dominated and should be recorded as such. This is a real and frequently ignored bar: as of the first literature pass, the strongest published high-precision ZKML system has a verification cost roughly five orders of magnitude above re-execution for an 11M-parameter model (see literature.md, ZIP).

So the honest framing of the research is not "ZK vs TEE". It is:

For which regions of the (workload, threat, verifier-capability) space does anything beat re-execution, and by how much?

2. What we refuse to assume

These are commitments, not opinions. They exist because each is a well-trodden way to waste a research year.

ZK is not assumed to be the answer. Current measured proving costs for neural inference are 10^6–10^8× native. That gap may close; it may not.
TEEs are not assumed to be the answer. A TEE moves trust from the provider to a hardware vendor plus its firmware supply chain plus its attestation service. That is less trust, not no trust, and the reduction has to be argued rather than asserted.
Hardware is not assumed to be the answer. "Build a proof-friendly accelerator" is a decade-scale bet. It may be correct. It cannot be the premise of a research programme whose first job is to find out what is already cheap.
Determinism is not assumed. Floating-point non-determinism across heterogeneous accelerators breaks naive replication and naive output-hash-equality. Nodus is explicitly a heterogeneous network, so this is a first-order problem, not an edge case.
Correctness is not assumed to be what we are buying. See §4.

3. Authentication is not proof of computation

Nodus v1 (../nodus/) signs an execution receipt with HMAC-SHA256 keyed by the node token. That construction is sound for what it does and the v1 code says so plainly in its own docstrings. It establishes:

the result for job X was produced by the holder of node X's token, was not modified in transit, and was not replayed.

It does not establish that any computation occurred. A provider holding a valid token can fabricate an output, sign the receipt over it, and be paid. We call this Claim O (origin) and treat it as a prerequisite for the other claims rather than as one of them. Every mechanism this repository evaluates is measured against what it adds on top of Claim O.

4. The claim/payment mismatch (the load-bearing insight)

Nodus does not pay for correct answers. It pays for compute units. Those are different objects, and almost all of the verifiable-computation literature addresses the first one.

A zkSNARK for inference proves: this function, applied to these committed inputs, yields this output. It says nothing about how much work the prover did to find that output.
A prover who discovers a cheaper way to produce the same output — a cached result, a distilled model that happens to agree, a better kernel, a lookup table — can still emit a perfectly valid proof while consuming a small fraction of the claimed resources.

Under a resource-priced economy this is not an attack on correctness. It is an attack on billing, and a correctness proof does not defend against it.

This yields a design position we will test rather than assume:

CU should be a function of the job specification, not of the provider's self-reported execution.

If CU is derived entirely from quantities the coordinator can recompute from the (committed) input and the (committed) output, then metering fraud is closed by construction and the remaining problem is purely Claim A/B/E. If CU depends on provider-reported measurements (wall-clock, utilisation, token counts), then we need Claim D — physical resource evidence — which is the hardest claim in the taxonomy and the one cryptography is worst at.

Nodus v1 is currently on the wrong side of this line in one specific, cheaply fixable place; see mvp-analysis.md §4.

5. Working hypotheses

Each is falsifiable and mapped to an experiment.

#	Hypothesis	Falsified if	Experiment	Status
H1	A general zkVM has a large fixed cost that dominates small jobs, so `R` is a hyperbola, not a constant.	prove-time is ~linear through the origin in cycles	001, 002	CONFIRMED — fixed cost 12.29 s; flat to ~10^6 cycles
H2	For structured linear algebra, probabilistic verification achieves `R << 1` with a computable and adjustable soundness error.	Freivalds-class checks cost ≥ the matmul, or error is not controllable	003, 009	CONFIRMED for exact arithmetic (`R_verify` = 0.023 at 2^-40). FAILS for floating point in a heterogeneous network (E009-pre): honest CPU/GPU divergence is within 3.7× of a real precision cheat, so no threshold separates them. Gross cheating is still caught
H3	Specialised/structure-exploiting verification beats general zkVMs by orders of magnitude on the same statement.	measured gap < 10×	002, 003, 006	CONFIRMED, ~10^9× on `R_verify` for Claim A (E001 vs E003). Not yet tested for a cryptographic specialised argument
H4	Most of the practical security of a compute network is obtainable from cheap mechanisms (commitments + random audit + stake), with cryptographic proof reserved for a small high-value tail.	expected-loss analysis shows audit-based schemes cannot bound fraud at acceptable audit rates	009, 012	partially supported. Cost is not the obstacle — the check is cheap enough (2% of compute) to run on every job. The obstacle was resolution (E009-pre), which E014 removed via exact arithmetic. E016 then supported H4 from an unexpected direction: not because cryptography is slow, but because data movement is — verifying every layer requires transmitting intermediates that cost 3-5 orders of magnitude more than the compute saved, so probabilistic layer auditing plus a stake equal to the job value becomes the affordable design
H7	(added 2026-09-01) The binding constraint on cheap verification is not its cost but the numerical agreement among honest providers — so the decisive design lever is specifying arithmetic, not choosing a proof system.	a cheap mechanism is found that separates honest heterogeneity from cheating without constraining arithmetic	009, 003, 014	CONFIRMED (E014). Constraining arithmetic to exact integers costs no supply — all five honest backends, CPU and GPU, return the bit-exact product — while separating cheats without bound. The heterogeneity problem was dissolved by changing the specification, not by improving a mechanism
H5	No mechanism we can build in 2026 establishes Claim D (physical resource usage) against a determined adversary without trusted hardware.	a counterexample is constructed or found in the literature	010, 011, 013	survives a literature search (E013). Software forces work only under unproven hardness conjectures — there are no unconditional lower bounds — and forcing work is still not evidence about a machine. Proof-of-Learning, the direct ML analogue, was published and broken
H8	(added 2026-09-01) Nodus does not need to solve Claim C or D at all: pricing jobs from the specification rather than from effort removes them from the settlement path.	a measured exploit exists that is profitable under output-based pricing and is not closed by dedup	013	supported by E013 — the only surviving exploit against exact verification was caching, which a hash lookup closes. Not yet quantified against real traffic
H6	The economically correct architecture is a tiered one: different evidence classes for different job values, not one mechanism for all jobs.	a single mechanism dominates across the whole value range	012	untested

H4 and H6 are, at the outset, the ones the research lead considers most likely to survive. That prior is recorded here so that it can be held against us if the experiments say otherwise.

Update, 2026-09-01. After E001/E003/E009-pre the prior has shifted. H4 survives on cost but not on resolution: cheap checks are affordable enough to run on every job, yet cannot tell an honest GPU from a cheating one. The newly added H7 is now the lead's best guess at the real conclusion — that the architecture question is less "which proof system" than "what arithmetic does the network mandate", and that verifiability is a constraint on the workload specification, not a layer bolted on afterwards.

6. What would make this programme a failure

Stated in advance, so we cannot move the goalposts:

Producing a roadmap and a literature review and no measurements.
Reporting proof-system benchmarks without the re-execution baseline beside them.
Describing a probabilistic scheme as a "proof".
Claiming any single mechanism covers Claims A–E.
Building a ZKML implementation because it is interesting rather than because a measurement said it was the cheapest sufficient mechanism.

7. The long-horizon question

Can computation hardware and computational protocols be designed so that useful computation and trustworthy evidence of that computation are produced together?

This is the speculative arm of the programme and is labelled SPECULATIVE throughout. It is not a premise. It becomes worth funding only if the measured data from Stages 1–9 shows a persistent, structural gap that software cannot close — and the shape of that gap is what would tell a hardware designer what to build. Establishing the gap precisely is therefore itself a deliverable, whether or not anyone ever tapes out silicon.