Zero-Approximation-Error Offloading

• Zero-Approximation-Error Offloading is an offloading regime that uses zk-SNARKs to strictly verify that outsourced computations meet exact correctness constraints.
• The approach leverages a blockchain broker, smart contracts, and formal NP relations to bind outputs to cryptographic proofs, ensuring payment only on verified results.
• A detailed TSP case study illustrates trade-offs between prover costs and on-chain verification, highlighting system performance and security benefits.

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" (Körbel et al., 2021), 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 (Körbel et al., 2021).

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 $f(x)$0. The properties stated for the verifier are completeness, soundness, and zero-knowledge:

• Completeness: $f(x)$1.
• Soundness: $f(x)$2.
• Zero-knowledge: the proof leaks no information about $f(x)$3 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 (Körbel et al., 2021).

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 $f(x)$4 offchain, and runs the ZoKrates program to compute witness and proof $$\pi<code>. Third, the provider submits</code>submitSolution(y, π, publicInputs)<code>, and the broker calls</code>verifyTx()<code>on the verification contract. Fourth, if</code>verifyTx<code>returns true, the broker persists the solution on-chain and payment can be released upon</code>endTask()<code>; otherwise, the submission is discarded. Fifth, the client calls</code>retrieveSolution()` to fetch the result, and optional encryption or <a href="https://www.emergentmind.com/topics/interplanetary-file-system-ipfs" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">IPFS</a> can be used to avoid public plaintext disclosure (<a href="/papers/2110.11090" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Körbel et al., 2021</a>).</p> <p>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 <code>endTask()</code> 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.</p> <h2 class='paper-heading' id='tsp-case-study-and-empirical-performance'>4. TSP Case Study and Empirical Performance</h2> <p>The evaluation uses the Traveling Salesman Problem as a concrete example. The <a href="https://www.emergentmind.com/topics/tensor-and-sequence-parallelism-tsp" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">TSP</a> is formalized as follows: given a complete graph with distances$$f(x)$5, find a permutation $f(x)$6 minimizing tour length,

$f(x)$7

with $f(x)$8. 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 (Körbel et al., 2021).

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 $f(x)$9 for a map with 70 cities, and up to $x$0 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 $x$1. 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 $x$2, 683,095 for $x$3, 1,008,588 for $x$4, 1,343,625 for $x$5, 1,694,698 for $x$6, 2,061,946 for $x$7, and 2,442,993 for $x$8n=3$x$9n=60. An alternative “on-chain verification” that checks Hamiltonicity and sum inside a Solidity contract grows from approximately208,557gas at $w$0 to3,454,393gas at $w$1n \ge 35$. Valid proofs were accepted, invalid proofs were rejected and not stored, and the broker persisted results only whenverifyTx` 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 $w$2 for an incorrect $w$3 with more than negligible probability. Data integrity is obtained through in-circuit hashes of path and cities, which tie $w$4 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 (Körbel et al., 2021).

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 $w$5 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 $w$6 may still be published on-chain unless it is encrypted or stored off-chain, for example via IPFS (Körbel et al., 2021).

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 $w$7 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 $w$8, 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 $w$9 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)$0, 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.