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.
From capacity to verified result
Each stage changes what the user and operator can safely claim.
Advertise
Publish accelerator, memory, runtime, storage, network, region, and allocatable capacity.
Open guide →Schedule
Match workload constraints to workers using explicit cost, trust, locality, and deadline policy.
Open guide →Isolate
Run unknown code with bounded devices, filesystems, capabilities, network, and execution time.
Open guide →Protect data
Classify input, scope artifact access, minimize retention, and prevent unapproved egress.
Open guide →Verify
Use reproducibility, tolerance, redundancy, audits, or attestation according to job value.
Open guide →Operate
Track queue, load, throttling, errors, transfer time, completion, and unit cost.
Open guide →Make the hidden assumptions visible.
Each answer should map to a test, metric, policy, or runbook—not merely to a design claim.
Not by default. Capability ads should be measured, refreshed, and optionally supported by diagnostics or attestation. Scheduling should use observed completion and failure data as well as declared inventory.
Containers reduce risk but share the host kernel and GPU driver. Unknown tenants may justify stronger virtualization, hardened runtimes, and separate control-plane credentials.
Use job-specific evidence: exact recomputation for deterministic work, fixed configurations and tolerances, redundant execution, sample evaluation, challenge jobs, or attested environments. No single method fits every model workload.
At minimum, assignment, queue, start, accelerator use, wall time, transfer, completion, failure reason, and any retained storage. The billing rule should name which measurements it uses.