---
title: Zero-Approximation-Error Offloading
url: https://www.emergentmind.com/topics/zero-approximation-error-offloading
type: topic
---

# Zero-Approximation-Error Offloading

Searching arXiv for the cited paper and closely related offloading verification work.
Zero-Approximation-Error Offloading denotes an offloading regime in which a service consumer outsources computation to an offchain worker, while a blockchain broker accepts and pays for the result only if a zero-knowledge proof attests that the submitted output satisfies the exact correctness constraints of the specified computation. In the formulation implemented in "Blockchain-based Result Verification for Computation Offloading" [2110.11090], correctness is defined with respect to a program specification compiled into a ZK circuit, and proof verification replaces redundancy and partial reprocessing as the mechanism for establishing trust. The resulting model aims to deliver provable correctness, privacy for hidden witness data, and platform-level enforcement of acceptance and payment without requiring a pre-existing trust relationship between consumer and provider.

## 1. Concept and Threat Model

The offloading scenario consists of a service consumer that outsources a computation to a service provider, or offchain worker, and receives the result back through a blockchain broker smart contract. The central problem is how to trust correctness of the offloaded result without recomputing it. The threat model includes malicious providers that may return incorrect results, try to decouple results from proofs, replay previously accepted results, or front-run to extract payment without computing. The blockchain and smart contracts are assumed to be correct and non-censoring, verification smart contracts are public and deterministic, and the cryptographic assumptions of the chosen zk-SNARK scheme are assumed to hold. No pre-existing trust relationship between consumer and provider is assumed; instead, a deposit or “stake” from the consumer ensures payment upon verified completion [2110.11090].

Within this model, “correctness” means that for a given program specification, the output $y$ matches the computation $f(x)$ over public input $x$ and any hidden witness $w$ according to constraints encoded in the ZK circuit. This is the sense in which the approach is characterized as “zero approximation”: proof verification attests that the output satisfies all correctness rules exactly, rather than only probabilistically or through sampling. A plausible implication is that the method is primarily targeted at settings where approximation risk is unacceptable, because the claimed advantage over redundancy and partial reprocessing is the elimination of redundant execution and client-side rechecking.

## 2. Formal Basis of Provable Correctness

The formalization is expressed through an NP relation $R(x, w)$ defined by the computation’s correctness constraints and compiled into an arithmetic circuit or R1CS. The provider computes $y = f(x)$ and generates a non-interactive proof $\pi$ attesting that a private witness $w$ exists such that the circuit constraints are satisfied. A public verifier $V$ checks $\pi$ over public inputs $x, y$. The properties stated for the verifier are completeness, soundness, and zero-knowledge:

- Completeness: $\Pr[V(x, y, \pi)=1 \mid (x, w) \in R \land y=f(x)] \ge 1-\epsilon_c$.
- Soundness: $\Pr[V(x, y, \pi)=1 \mid y\neq f(x)] \le \epsilon_s$.
- Zero-knowledge: the proof leaks no information about $w$ beyond the validity of the statement.

The concrete ZK system is zk-SNARKs via ZoKrates using Groth16 over Ethereum’s altbn128 curve. The cited assumptions are the knowledge of exponent and discrete-log assumptions in the bilinear groups underlying Groth16. Proof size is constant because Groth16 uses three group elements, and on Ethereum this appears as arrays `a`, `b`, `c` in `verifyTx`, occupying a few hundred bytes on-chain. Verification cost is separated from proof size: proof verification itself is constant-size pairing checks, while on-chain cost grows linearly with the number of public inputs because of input processing and multi-exponentiation [2110.11090].

A central technical requirement is output and input binding inside the circuit. In the reported design, hash commitments using SHA-256 are included in the circuit so that `hash(concat(path))` equals the submitted `hashOfPath`, and `hash(concat(cities))` equals `hashOfCities`. This prevents proof/result decoupling and replay across tasks or maps. The broader significance is that the proof does not merely certify that *some* valid witness exists; it certifies correctness of the specific submitted data to which the proof is cryptographically bound.

## 3. System Architecture and Workflow

The architecture has four principal components: the client or service consumer, the offchain worker or service provider, the ZoKrates-based ZK prover, and blockchain smart contracts. The smart-contract layer is split into a broker contract and a verification contract. The broker manages the task lifecycle and incentives, while the verification contract exposes a Groth16 verifier with `verifyTx(a, b, c, input)` and uses Ethereum altbn128 pairing precompiles.

The end-to-end workflow is defined in five steps. First, the client deploys the broker and indicates the verification requirement through `createTaskRequest(stake, taskInfo, verify=true)`. Second, the provider calls `getTaskRequest()`, computes $y=f(x)$ offchain, and runs the ZoKrates program to compute witness and proof $\pi`. Third, the provider submits `submitSolution(y, π, publicInputs)`, and the broker calls `verifyTx()` on the verification contract. Fourth, if `verifyTx` returns true, the broker persists the solution on-chain and payment can be released upon `endTask()`; otherwise, the submission is discarded. Fifth, the client calls `retrieveSolution()` to fetch the result, and optional encryption or IPFS can be used to avoid public plaintext disclosure [2110.11090].

Task assignment is simple open assignment, meaning any provider can pick tasks. Payment is guarded by the stake and only executed after successful verification and `endTask()` after a minimum duration. Invalid proofs lead to rejection and no payment. Reputation and auctions are discussed as possible extensions, and slashing for malicious behavior can be added but is not implemented in the reference. This design places correctness enforcement in the verification path rather than in provider reputation, repeated execution, or dispute-heavy market mechanisms.

## 4. TSP Case Study and Empirical Performance

The evaluation uses the Traveling Salesman Problem as a concrete example. The TSP is formalized as follows: given a complete graph with distances $d_{i,j}$, find a permutation $\sigma \in S_n$ minimizing tour length,
$$
\min_{\sigma \in S_n} \sum_{i=1}^{n} d_{\sigma(i),\sigma(i+1)},
$$
with $\sigma(n+1)=\sigma(1)$. Standard ILP constraints are cited, including assignment constraints and subtour elimination constraints, but not all of them are encoded in the implementation. What the circuit proves is narrower and explicit: Hamiltonicity of a candidate tour, path length equality, and input binding for a specific TSP instance. The circuit does **not** prove optimality; it certifies that the submitted tour is valid and has the claimed length, while optimality or quality selection is left to the broker as future work [2110.11090].

The illustrative ZoKrates DSL interface is `main(path[10], mapnumber, sum, cities[10], hashOfCities[2], hashOfPath[2])`, with checks for `basicInputCheck`, `checkCities`, `calculateSum`, and hash equality conditions for both path and cities. The reported implementation was constrained by ZoKrates’ lack of dynamic arrays, so distinct circuits were compiled in steps of 10 and paths were padded to the nearest circuit size. Instance sizes reached up to $n=60$ for a map with 70 cities, and up to $n=30$ for a map with 30 cities.

Prover cost is dominated by `compute-witness` and `generate-proof`, with `generate-proof ≈ 3.2× compute-witness on average`. For map-70, the example times are approximately `26.5s` for compute-witness and `82.9s` for generate-proof at instance size 31, and approximately `49.5s` and `152.4s` respectively at instance size 60. End-to-end latency is therefore dominated by offchain proving, which takes tens to hundreds of seconds depending on $n$. By contrast, on-chain verification is a single transaction execution.

The main on-chain metric is gas for `submitSolution`. With zk verification on map-70, the reported gas values are approximately `632,922` for $n=3$, `683,095` for $n=10$, `1,008,588` for $n=20$, `1,343,625` for $n=30$, `1,694,698` for $n=40$, `2,061,946` for $n=50$, and `2,442,993` for $n=60`. Without verification, the baseline grows from approximately `168,740` gas at $n=3$ to `1,321,061` gas at $n=60`. An alternative “on-chain verification” that checks Hamiltonicity and sum inside a Solidity contract grows from approximately `208,557` gas at $n=3$ to `3,454,393` gas at $n=60`. The paper further states a break-even favoring zk over full on-chain verification from about $n \ge 35$. Valid proofs were accepted, invalid proofs were rejected and not stored, and the broker persisted results only when `verifyTx` returned true.

## 5. Security Properties and Comparative Position

The stated security guarantees are soundness, data integrity, and privacy. Under Groth16 assumptions, a malicious provider cannot produce a valid proof $\pi$ for an incorrect $y$ with more than negligible probability. Data integrity is obtained through in-circuit hashes of path and cities, which tie $\pi$ to the exact submitted data and invalidate verification if inputs are swapped or decoupled. Privacy is limited but explicit: private inputs and witness are not revealed, and only public inputs such as hashes and sum appear on-chain [2110.11090].

Attack handling is specified operationally. If an incorrect proof is submitted, `verifyTx` returns false, the broker discards the submission, and no payment is made. Replay is addressed by binding proofs to `mapnumber` and hashes, so replaying $\pi$ for different tasks or maps fails verification. Collusion among multiple providers is described as ineffective against cryptographic verification because they cannot forge $\pi`. Denial-of-service remains possible through submission spam, and the discussed mitigations are rate limits, deposits, and whitelists; minimum task duration and stake gating reduce griefing. Slashing for invalid or malicious behavior can be added, but the implementation pays providers only after successful verification.

In comparative context, redundancy and reputation systems such as Golem, iExec, and SONM reduce risk but cannot prove correctness and incur cost increases proportional to redundancy. Optimistic verification in the style of Truebit requires verifier participation, can be subjected to constant challenges, and affects throughput. TEEs such as SGX and Ekiden provide confidential execution but have documented side-channel vulnerabilities, require hardware and enclave attestation, and rely on a different trust anchor from fully cryptographic verification. SMPC preserves privacy but has high overhead and is not presented as a fit for single-provider outsourcing. zk-STARKs and Bulletproofs offer transparent setups, but at the time of this work zk-SNARKs are described as offering better on-chain succinctness and toolchain maturity via ZoKrates. The novelty claimed for the approach is the integration of a full offloading pipeline with on-chain proof verification and a concrete TSP implementation that quantifies costs and trade-offs while binding outputs to proofs to prevent decoupling.

## 6. Limitations, Design Guidance, and Conditions for Zero-Approximation Error

Several limitations are intrinsic to the chosen toolchain and proof system. Encoding complex algorithms increases constraint counts and prover time. ZoKrates lacks dynamic arrays, so circuits are compiled for fixed sizes, which contributes to padding and jumps in gas. Groth16 requires a trusted setup per circuit, creating operational overhead and trust assumptions; the paper notes that a multi-party ceremony can mitigate this, referencing Zerocash and Pinocchio MPC. Proof generation can take tens to hundreds of seconds for moderate instance sizes, which is not ideal for latency-sensitive tasks. Privacy is also qualified rather than absolute: although the proof is zero-knowledge, the result $y$ may still be published on-chain unless it is encrypted or stored off-chain, for example via IPFS [2110.11090].

A common misconception is that proving correctness of a computation necessarily proves quality or optimality of the result. The TSP example explicitly shows otherwise: the circuit verifies validity and claimed length, not optimality. The text therefore states that zero-approximation verification of optimality would require encoding the optimality conditions, such as full ILP constraints or certified lower bounds. More generally, zero-approximation error is achieved only when the correctness relation $R(x, w)$ fully captures the exact property that must be certified. This suggests that the practical meaning of the term depends less on the abstract proof system than on the completeness of the circuit specification.

The design guidance is correspondingly circuit-centric. One first defines the correctness relation $R(x, w)$, identifies public inputs and private inputs, and specifies exact output binding. One then writes a ZoKrates DSL program encoding input validation, core correctness conditions, and hash-based output binding, compiles the program to a circuit, runs the trusted setup, and deploys the verification contract. The broker should publish tasks and stakes, accept $(y,\pi,\text{publicInputs})$ and call `verifyTx`, persist results only on successful verification, and release payment conditioned on `verifyTx`, minimum duration, and an optional dispute window. The principal optimization guidance is to minimize public inputs via hashing, precompute constants, avoid loops over large data where possible, and use hashing to reduce input size to verification. The paper also notes that Groth16 is appropriate for succinct verification and Ethereum deployability, whereas transparent systems such as PLONK, Marlin, and STARKs should be considered if trusted setup is infeasible, with proof size and on-chain cost treated as trade-offs.

The conditions stated for achieving zero-approximation-error offloading are explicit. The computation’s correctness must be fully captured in the circuit $R(x, w)$, including output-to-input binding and the exact property to be verified. A secure zk-SNARK system with soundness and completeness must be used, proofs must be verified on-chain, and outputs must be accepted only if the proof validates. Input commitments such as hashes ensure data binding, and trusted setup must be properly conducted or replaced by a transparent scheme. Under those conditions, the blockchain enforces that only provably correct computations are paid and recorded, thereby eliminating reliance on redundant computation, sampling, or reputation while preserving privacy and platform neutrality.

Source: https://www.emergentmind.com/topics/zero-approximation-error-offloading