# Research thesis **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. 1. **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. 2. **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. 3. **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. 4. **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. 5. **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.