Skip to content

Decentralized Compute and AI Verification

Problem

Decentralized compute today is costly, brittle, and easy to game. Most systems rely on ad-hoc coordinators, TEEs, or multisig committees that don’t provide chain-agnostic, slashing-enforced guarantees. Notable shortcomings include:

  • High cost: bespoke committees/light clients per network, many sig verifications on-chain, custom relayers, repeated audits, and over-provisioned capacity drive unit economics up.
  • Attack surface: forged results, equivocation (conflicting outputs), replay of old results, censorship/withholding, collusion among runners, coordinator DoS, key compromise, MEV/front-running on result publication, and TEE quote spoofing without on-chain anchoring.
  • Weak incentives: runners often have little or no bonded stake; slashing paths are unclear or social, so bad behavior is cheap.
  • Operational opacity & lock-in: logs and receipts are off-chain/opaque, integrations are bespoke per chain or vendor, and portability is poor.

Solution

Relay turns each off chain computation, including container jobs, into a stake backed, verifiable receipt. These receipts can be checked on chain and, once approved, automatically trigger payments, unlocks, or workflow steps. There are no custom committees or heavy coordination, only clear proof that a job was done, with built in penalties for cheating or missed deadlines, lower costs at scale, and portability across any cloud or chain.

Some of the Relay advantages can be found below:

  • Usage-based, provable billing: verifiable receipts include runtime/metrics so you can meter, invoice, and settle on-chain per job or per epoch.
  • SLA enforcement: late, missing, or conflicting results are objectively slashable; clients get deterministic inclusion and dispute windows.
  • Lower verification cost: aggregate many job receipts once per epoch → one on-chain verify for hundreds/thousands of tasks.
  • Input/Output integrity: bind container image digest, parameters, data CIDs, and output/artifact hashes into the receipt to prevent tampering or replay.
  • TEE or ZK, your choice: attach a TEE quote hash or a zk proof of execution when available; Relay’s stake guarantees still secure the base path.
  • Multi-cloud portability: same receipt format and Verifier across L1s/rollups; run workers on any infra (K8s, bare-metal, cloud) without vendor lock-in.
  • Fair marketplace for runners: bonded operators with reputations and slashing create credible supply; optional per-capability whitelists (GPU, RAM, CUDA).
  • Composable callbacks: post-verify adapters can release escrow, mint compute credits, advance workflows, or trigger subsequent jobs.

How it Works

  1. Register and bond: Operators enroll for the compute task, publish keys and capabilities, and lock stake that can be slashed.
  2. Submit job: The client posts a job with an input commitment that binds image or runtime, parameters, and data.
  3. Execute off chain: A worker runs the job. A small Sidecar measures runtime and resources, and derives an output commitment for results and artifacts.
  4. Attest: Operators sign a job receipt that includes task id, job id, input hash, output hash, metrics, epoch, and nonce. Receipts can also include a TEE quote hash or a zk proof.
  5. Aggregate: Receipts are BLS-aggregated and optionally batched per epoch to amortize costs.
  6. Verify on chain: The Verifier contract checks quorum, stake weight, freshness, and anti-replay.
  7. Trigger action: After verification, an Adapter releases escrow or payment, mints compute credits, advances a workflow, or calls back the app.
  8. Challenge and slash: Within the challenge window anyone can submit evidence of fraud, equivocation, replay, or missed SLA. Proven faults slash operator stake and can revert or remediate actions per policy.

Flow

Get in touch with Symbiotic Team

Application Examples

  1. AI inference marketplace

Each inference container runs a Relay Sidecar that signs an attestation with: model ID/version, input hash, output hash, latency, and compute meter. Buyers verify the attestation on-chain before releasing payment; misbehavior can be slashed against the operator’s staked collateral.

  1. Model training and fine-tuning

Trainers emit Relay attestations at checkpoints (per epoch or per N steps) containing dataset/version hashes and metrics (loss/accuracy). Milestone payouts stream only when the on-chain verifier accepts the attested checkpoint; failed or missing checkpoints pause funding and can trigger slashing.

  1. ZK prover network

Prover nodes attach Relay to the proving container. When a proof is generated, the Sidecar signs an attestation with the proof commitment and job ID. The consumer contract verifies both: (1) the proof itself and (2) the Relay signature tied to a bonded operator, then releases payment atomically.

  1. Indexing and ETL pipelines

Indexers process ranges (e.g., blocks 10M–10.1M) and emit Relay attestations with range coverage, schema version, and result checksum. Consumers (subgraphs, data apps) pay per attested range and can reconstruct a full index by verifying a sequence of signed ranges from a quorum.

  1. Edge Compute

Edge devices process shards of a job and sign shard-level Relay attestations (shard ID, input/output hashes, timing). An aggregator contract verifies a threshold of shard attestations, reconstructs the job result, and then settles payments pro-rata; faulty shards are isolated and penalized.

References