Unbuilt design sketch — the network below is a client-side simulation and the code samples are illustrative, not integrated into the real repo. See what's actually shipped on GitHub.

Design sketch — not implemented

From Single VM to
Decentralized Network

A sketch of what turning the real zkvm-isa / zkvm-stark prover into a distributed proving network could look like — a node anyone runs, an on-chain task orchestrator, and a P2P mesh. The network below is a simulation; nothing here is live.

0
Simulated Nodes
0
Simulated Tasks
0
Simulated Proofs
0
Simulated $ZKVM (no real token)

The Sketch: Four Layers

None of these four layers exist in the real repo today — this is the design conversation, not a status report.

1. The Node

Self-Hosted Docker Container (unbuilt)

A Docker container running the VM, a P2P stack, and optional GPU acceleration — the plan for plug-and-play deployment. No Dockerfile for this exists in the repo yet.

VM Runtime P2P Stack GPU Accel

2. The Orchestrator

Smart Contract (design sketch below)

Would route tasks to nodes and hold escrowed payment — the real repo's ProofOrchestrator.sol already does task/reward lifecycle for a single attester; this sketch extends that idea to many competing provers.

Task Routing Payments Verification

3. The Network

Libp2p Mesh (unbuilt)

A peer-to-peer mesh for task distribution and proof submission — no central server. Genuinely unbuilt; the section below simulates what it would look like, entirely in your browser.

Libp2p Task Dist Proof Submit

4. The Incentive Layer

$ZKVM Token — no token exists

The sketch pays nodes for valid proofs and slashes for invalid ones. There is no deployed token, no tokenomics, and no treasury — this is a placeholder for "some incentive mechanism," not a financial product.

Rewards Slashing Staking

System Architecture (Sketch)

The intended end-to-end flow, if this were built — not a description of anything running today.

👩‍💻
Developer
SDK → submit_task() (sketch, not built)
zkvm_sdk.py
HTTP POST /submit
⛓️
Multi-prover Orchestrator (sketch)
Extends the real ProofOrchestrator.sol pattern
Solidity
claimTask() → P2P Broadcast
🌐
Libp2p Mesh Network (unbuilt)
Peer-to-Peer Task Distribution
TCP + QUIC
Node A (GPU)
Node B (GPU)
Node C (CPU)
submitProof() → STARK Proof
✅
On-Chain Verification
Would need a real cryptographic verifier — see docs/ONCHAIN_VERIFIER.md
verifyProof()

Live Network Simulation

A client-side animation of how tasks might flow through such a network — no server, no real nodes, entirely generated in your browser right now.

Simulated Topology
Idle Proving GPU

Simulation Stats

Simulated Nodes3
Pending Tasks0
Completed0
Avg Simulated Prove Time0ms
Simulated $ZKVM Paid0.00

Node Status

Node-A
GPUidle
Node-B
GPUidle
Node-C
CPUidle

Simulated Task Log

Waiting for simulated tasks...

Design Sketch Code

Illustrative sketches for each layer — none of this is wired into the real repo. The verifier stub below reverts rather than accepting anything, matching this project's actual UnimplementedStarkVerifier.sol pattern.

Dockerfile (sketch)
# Build Stage — sketch, not present in the repo
FROM rust:1.80-slim as builder
RUN apt-get update && apt-get install -y \
    nvidia-cuda-toolkit build-essential git cmake \
    && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY crates/zkvm-isa ./crates/zkvm-isa
COPY crates/zkvm-stark ./crates/zkvm-stark
# crates/zkvm-node does not exist yet -- this is what it would build
COPY crates/zkvm-node ./crates/zkvm-node
COPY Cargo.toml Cargo.lock ./
RUN cargo build --release --bin zkvm-node

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y libssl3 ca-certificates && rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/target/release/zkvm-node /usr/local/bin/zkvm-node
ENTRYPOINT ["zkvm-node"]
CMD ["--start"]

Why This Might Be Worth Building

The rationale for the sketch — an argument for building it, not evidence it's built.

Pain Point Sketch's Proposed Answer
💸High Cost
Nodes use idle GPU/CPU power — a hypothesis about lower fees, not a measured one.
🏢Centralization
Today's real server is a single process on one machine — the sketch's answer is "anyone can run a node."
🧠Complexity
A Python/JS SDK could hide ZK details — sketch only, no SDK exists.
🤝Trust
Self-hosted nodes would remove the need to trust one server operator — the real repo's own THREAT_MODEL.md is more honest about today's single-attester trust gap than this sketch's optimism.
📈Scalability
Parallel proving across many nodes — plausible in principle, untested in practice, no benchmark exists.