Decentralized compute nodes

Turn GPU capacity into a governed, measurable worker node.

Match jobs to real capabilities, isolate untrusted code, protect data, record provenance, meter resources, and verify results at the level the workload permits.

A GPU node is more than an accelerator attached to a wallet address. It is an execution boundary that receives code, model artifacts, data, and deadlines from outside its operator. The worker must advertise what it can really provide, enforce local policy, isolate each job, and return evidence that links the result to a specific environment and manifest.

Scheduling should consider memory, driver and runtime versions, model locality, network, region, trust tier, verification cost, and failure history—not only price or a GPU product name. Advertise allocatable capacity, not raw physical inventory. Use leases, acknowledgements, and timeouts so abandoned assignments return safely to the pool.

Assume submitted workloads are hostile. Pin images by digest, restrict devices and network egress, remove unnecessary privileges, use scoped artifact credentials, and separate the worker from the scheduler’s administrative authority. Confidential data requires a stronger threat model than public inference; disk encryption alone does not hide live data from a privileged host.

Verification must fit the job. Some deterministic tasks can be recomputed exactly. Model inference may use seeds, tolerances, redundant execution, or sample evaluation. Training may require checkpoint, loss, and configuration evidence. Attestation can prove aspects of the environment, but it does not prove that a business result is correct.

Worker evidence packet

Every result should be traceable to a job manifest, image and model digests, runtime profile, resource record, timestamps, exit state, and the chosen verification method.

01Versioned capability advertisement
02Digest-pinned images and models
03Per-job storage and network policy
04Short-lived artifact credentials
05Measured accelerator utilization
06Retry and duplicate-execution controls
Operating questions

Make the hidden assumptions visible.

Each answer should map to a test, metric, policy, or runbook—not merely to a design claim.