The optimistic construction is the oldest idea in verifiable computation and still the cheapest: do not generate a proof. Publish the claimed output, open a challenge window, and if anyone disputes it, fall back to an interactive protocol that adjudicates who is right, a fraud proof, typically a bisection game that narrows the disagreement to a single instruction, which a referee can then execute directly.

opML is the reference point, and it is the strongest argument against zkML as a default. Because it never generates a proof unless challenged, the honest path costs approximately what running the model costs. It runs a 7B-parameter LLaMA on a standard PC with no GPU. Its own argument is that zkML carries ">1000x" overhead against plain computation, but that is opML's claim about zkML, not a measurement in this SoK: papers.yml records no plain-execution baseline for any system, so the ratio cannot be computed from our data.

What the security assumption actually is

opML calls it AnyTrust: any single honest validator can force correct behaviour. That phrasing is accurate and it is also doing a lot of compression. Unpacked, an optimistic system is safe only if all of the following hold:

1. An honest challenger exists. Not a majority. One. This part really is a weak assumption, and it is the whole appeal.
2. The challenger is watching. They must observe the claim inside the window. A validator who is offline during the challenge period is, for that claim, not a validator.
3. The challenger can re-execute. To know the output is wrong you must compute the right one, which means you need the weights. Optimistic verification is therefore incompatible with model privacy, someone must be able to run the model to police it. This is not a performance limitation that will be engineered away; it is structural.
4. Challenging is worth it. The bond, the gas, the compute, and the opportunity cost of the dispute must be less than the reward for winning it. A rational validator who spots a fraud whose bounty is smaller than the cost of proving it will do nothing.
5. The dispute game itself terminates correctly against an adversary who can grief it spam challenges, delay responses, or censor the challenger's transaction inside the window.

Assumption 1 is the one the papers advertise. Assumptions 2 through 5 are where the failures live, and they are not cryptographic failures. They are liveness, economics, and censorship failures, which is to say: they are the failures that actually happen.

What it costs you, stated plainly

Latency to finality. The output is not trustworthy until the window closes. For an on-chain settlement that is a delay measured in whatever the window is; for an interactive user-facing product it is fatal. Optimistic TEE-Rollups (OTR) exists largely to paper over exactly this, offering what it calls "sub-second" provisional finality backed by hardware, and deferring the real guarantee to the fraud-proof path.

Verifiability only for the watchers. A ZK proof convinces a party who shows up two years later with no context. An unchallenged optimistic claim convinces you only if you believe someone competent was watching at the time. Those are different epistemic objects, and the second one does not compose across time or across trust boundaries.

Privacy. See assumption 3. You cannot have a challenger who can re-execute and a model that is secret.

The inversion

The most useful thing opML says is not about cost, it is about ordering. A challenge window is a constant. A zkML proving time is a function of model size that grows faster than the model does. Past some crossover point, the ZK proof takes longer to produce than the optimistic system takes to finalise, at which point the optimistic system is both cheaper and faster, and the only thing ZK is still selling is the strength of the assumption.

Nobody in this SoK has located that crossover point empirically. It is a genuinely answerable question: it needs one proving-time curve and one challenge-window constant.

The hybrids

Two systems here refuse the binary, and both are more interesting than either pure design.

opp/ai splits by privacy need: prove the privacy-sensitive submodel in ZK, run the rest optimistically. This is a direct response to assumption 3 above, it carves out the part of the model that cannot be exposed to a challenger and pays ZK's price only there. Whether the split leaks anything about the boundary between the two halves is the question to ask of it, and we do not hold the paper, so we cannot say whether it answers it.

zk-OPML splits by operator: decompose inference to the ONNX operator level, verify optimistically, and generate ZK proofs only for isolated operators where they are needed. This is the same instinct as the operator atlas, that not all operators are equally hard or equally dangerous, applied to trust rather than to cost.

Optimistic TEE-Rollups (OTR) splits by role: hardware for throughput, fraud proofs for finality, and stochastic ZK spot-checks to bound the probability that the hardware was compromised. It is the most sophisticated construction on this page and the one with the most assumptions to compose. See TEEs.

One historical note worth keeping. SafetyNets, the 2017 ancestor of the entire sum-check zkML lineage, is itself interactive: the verifier sends live challenges and the prover responds. In a sense the whole field started somewhere between these two worlds, and both branches are attempts to remove the interaction: ZK by compiling the verifier away with Fiat–Shamir (which is what the Fiat–Shamir/GKR attack attacks), and optimistic systems by making the interaction rare rather than removing it. The optimistic branch never took on that attack surface, because it never took that step.