Three companies—AWS, GCP, Azure—control 65% of the global cloud computing market. They decide who gets access to infrastructure, at what prices, and under what terms. For most applications, that's acceptable. For AI inference, rendering, scientific computing, and any workload where price, censorship resistance, or geographic distribution matters—it's not. A decentralized compute network builds a market between those with spare GPU/CPU and those who need them. We build such networks end-to-end—from economic model to mainnet launch. Get a consultation on choosing a verification mechanism today.
The challenge is that building a decentralized compute network is technically harder than it seems. Three fundamental problems must be solved: verifying that a computation was executed correctly; protecting against dishonest providers and clients; and delivering performance comparable to centralized alternatives. Contact us—we'll assess your project for free.
How to Verify Computations Without Re-execution?
A provider claims to have run your task and obtained result X. How can the contract check this without recalculating itself? If the contract recalculates, you pay double cost. That's the core verification problem.
Three Approaches and Their Trade-offs
Optimistic execution with challenge period. The result is accepted as correct unless disputed within a window (usually 7 days). On dispute, a verification game: both parties alternately narrow the disagreement to a single computation step, which is verified on-chain. This is the approach of Truebit; an adapted version is used in Arbitrum for EVM disputes.
Key parameters: provider's stake (must exceed expected profit from cheating), challenge window length (trade-off between security and speed), number of verifiers in the game. Weakness: if client and provider collude, or if the challenge window is improperly chosen for a specific task class.
Trusted Execution Environment (TEE). Computation occurs in an isolated enclave—Intel SGX, AMD SEV, ARM TrustZone. Hardware attestation proves that specific code executed in a specific environment without operator interference. The contract verifies the attestation quote on-chain.
interface ITEEVerifier {
// mrenclave — unique hash of the code in enclave
// report — signed Intel IAS report
function verifyAttestation(
bytes32 mrenclave,
bytes calldata report,
bytes calldata signature
) external view returns (bool);
}
How does TEE attestation work?
The enclave generates a signed quote, which is verified on-chain using Intel's public key. If attestation passes, the contract is confident the code was executed in a protected environment.Used in iExec (TEE tasks), Phala Network (Phat Contracts), Marlin Protocol. Weaknesses: Intel SGX had several serious vulnerabilities (Spectre/Meltdown variants, SGAxe), dependence on hardware vendor, supply chain complexity for verifying hardware. TEE is 10-50x faster than ZK in verification time, but offers weaker guarantees.
Cryptographic verification via ZK-proofs. The provider generates a ZK-proof that they performed the correct computation on the input data. An on-chain verifier checks the proof in O(1) regardless of computation complexity. This is the strongest approach in terms of guarantees, but the most expensive in terms of proof generation overhead.
For simple deterministic tasks (hashing, basic arithmetic)—Groth16 or PLONK via circom. For complex computations—zkVM (RISC Zero, SP1): client writes a Rust program, zkVM generates a proof of execution for any Rust program. Cost of proof generation on RISC Zero: $0.01 to $1 depending on task complexity, time 10–300 seconds.
In practice, most recent protocols use a hybrid: TEE for primary verification (fast, cheap) + optimistic challenge for cases where TEE attestation is unavailable or compromised. This approach reduces cost by 30-50% compared to a pure ZK scheme without losing security.
| Method | Speed | Security | Overhead Cost |
|---|---|---|---|
| Optimistic | Medium | Medium | Low |
| TEE | High | Medium | Low |
| ZK | Low | High | High |
Determinism of Computations
For any verification method, the computation must be deterministic: identical code and inputs must produce exactly the same result on any hardware. This is non-trivial.
Problems: floating-point operations yield different results on different CPU architectures and compilers; GPU computations are non-deterministic by default due to parallelism; multi-threading with race conditions; dependence on system time or randomness.
Solutions: compute in WebAssembly (deterministic by specification); use integer arithmetic instead of float; deterministic ML frameworks (fixed seeds, disabled non-deterministic parallelism); container isolation with fixed environment (Docker image pinning by SHA256).
When Is Replication Needed?
For high-stakes tasks, run the same computation on N providers and verify results via consensus. With 3 providers and majority rule, attack probability drops sharply (requires collusion of 2 out of 3).
Commitment-Reveal Scheme
Providers first publish a hash of the result (commitment), then after all have deposited, reveal the result. This prevents copying each other's answers.
// Phase 1: Commit
function submitResultHash(bytes32 taskId, bytes32 resultHash) external {
require(isTaskProvider(taskId, msg.sender), "Not assigned provider");
require(task.status == TaskStatus.Active, "Wrong status");
resultCommitments[taskId][msg.sender] = resultHash;
emit ResultCommitted(taskId, msg.sender);
}
// Phase 2: Reveal
function revealResult(bytes32 taskId, bytes calldata result) external {
bytes32 commitment = resultCommitments[taskId][msg.sender];
require(keccak256(result) == commitment, "Hash mismatch");
revealedResults[taskId][msg.sender] = result;
_tryFinalize(taskId);
}
Economic Layer
Our token model for a decentralized compute network typically includes:
| Parameter | Typical Range | Purpose |
|---|---|---|
| Provider stake | 5–100 RLC / USDC | Collateral against fraud |
| Slash on violation | 10–50% of stake | Deterrence |
| Protocol fee | 1–5% | Treasury |
| Scheduler fee | 1–3% | Matching layer |
Important nuance: the token should be used to pay for computation (utility), not just governance. Pure governance tokens in compute markets do not create sufficient demand-side pressure.
End-to-End Task Workflow
- Client uploads Docker image of the application to IPFS, obtains content hash.
- Client creates a task on-chain: app hash, dataset hash, parameters, deposit.
- Matching layer or scheduler assigns provider(s).
- Provider downloads image + data, executes in TEE or standard container, generates result + attestation/proof.
- Provider publishes commitment on-chain.
- After reveal and consensus, result is finalized, provider receives payment.
- Client downloads result from IPFS.
Network Components Off-Chain
Worker node — the main component for the provider. A daemon that monitors the blockchain for new tasks, downloads and executes workloads, and publishes results. Stack: Go or Rust, Docker SDK for container isolation, SGX SDK for TEE tasks.
Scheduler / Core — for protocols with off-chain matching. Handles task categorization, provider selection based on stake and reputation, timeout monitoring. Can be decentralized via BFT consensus (set of scheduler nodes).
Result storage — IPFS with pinning. IPFS reference stored on-chain. Alternative for confidential results: encrypted result in IPFS, decryption key passed via TLS in TEE.
What's Included in Turnkey Development
We offer a full cycle: from whiteboard to audit. Key deliverables include architecture documentation, smart contracts with source code, worker node with Docker and TEE integration, testbed with real providers, client team training, and post-launch support. If needed, we write formal specifications and perform formal verification of critical modules.
Development and Launch Timeline
Design phase (2–3 weeks). Selection of verification mechanism (TEE / optimistic / ZK), definition of task categories, token economics. These decisions cannot be undone after deployment.
Smart contracts (6–10 weeks). TaskRegistry, WorkerRegistry, Escrow, Consensus module, Voucher system (for sponsoring tasks). Foundry for testing, including fork tests with real TEE attestation data.
Worker node (4–8 weeks). Go/Rust daemon with Docker integration. If TEE, integration with Intel DCAP attestation API. Critical: node must correctly handle timeouts, stuck tasks, and network partitions.
Testing with real hardware (4–6 weeks). Testnet with real worker nodes, load testing of matching layer, slashing verification on dishonest workers.
Audit (4–8 weeks). Focus on correctness of consensus mechanism under Byzantine providers, possibility of challenge game manipulation, flash loan attacks on stake mechanism.
Full cycle from design to mainnet launch for an MVP protocol (TEE-based, without ZK) — 6–10 months with a team of 3–5 engineers. Timelines depend on complexity and need for ZK or hybrid verification. Get a consultation—we'll assess your project and propose a roadmap.