§28. Implementation Sketches for Builders

Jason St George. "§28. Implementation Sketches for Builders" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v2.0. /v/2.0/read/part-vi/28-implementation-sketches/

Implementation Sketches for Builders

Everything above is the blueprint. This section is about what to actually ship first.

Minimum Viable Stack (MVS) Sequencing

Builders will ask: “What is the minimal sequence?” The answer matters because dependencies are real.

Minimum Viable Stack sequencing.

Why this order:

1. Receipts first: Without verifiable receipts, all claims are unpriced. Ship PIDL, reference verifiers, and dataset anchoring before anything else. This is the foundation that makes “no dashboards, no trust” real.

2. One corridor before many: A single refund-safe, non-custodial corridor with public VerifySettle is worth more than ten “coming soon” announcements. Ship BTC$\leftrightarrow$ZEC or BTC$\leftrightarrow$XMR with 100% refund safety before expanding.

3. One proof factory before PoUW: Prove that canonical workloads can be produced, verified, and priced before adding consensus complexity. PROOF_$2^{20}$ and MATMUL_4096 are good starting points.

4. SDKs after primitives: PaL and PRK are developer surfaces, not primitives. Ship them once the underlying corridors and proof factories are stable.

5. Neutral routing after basic markets: Fairness tests and admission metrics matter only once there’s enough activity to measure. Don’t over-engineer routing before you have provers to route.

6. PoUW last: Proof-of-useful-work consensus is the most complex piece. It requires stable proof factories, receipts, and measurement infrastructure. Don’t attempt it until Priorities 1–5 are solid.

Hardware profile clarity:

“Commodity GPUs with well-understood drivers” is an “open-ish hardware profile.” To be explicit: this is Profile Class: Partially Closed, High Familiarity. GPUs are not verifiable machines in the same sense as open RTL—they are “known black boxes” whose behavior is well-characterized but not inspectable. Label profiles clearly so users understand the trust assumptions.

Layer-0 Verifiable Machines

Start with small, fully open “security evaluation” chips: key-storage/signing cores, simple TRNG/PUF arrays. For each tape-out, commit to a fixed sampling plan.

Minimal Layer-0/4 pattern:

• Pick one open-ish hardware profile (e.g., commodity GPUs).

• Define a hardware profile HID with chip family, driver versions, entropy tests, power metering.

• Stand up a proof factory cluster with reference prover binaries.

• Publish basic telemetry and VerifyPrice samples.

Privacy Rails: Making Settlement Safe and Boring

Standardize adaptor-signature swap flows. Take BTC$\leftrightarrow$XMR and BTC$\leftrightarrow$ZEC as canonical corridors. Write down message formats, time-lock conventions, refund procedures.

Ship wallet UX with recovery, not bravado. Clear progress indicators, explicit timeouts, visible “abort and refund” buttons.

Document settlement latencies and success rates. Publish historical p50/p95 time-to-finality, success rates, and failure breakdowns.

Proof Factories: Receipts as a Service

The next implementation target is the Prove stage: turning raw work into portable receipts that any chain, app, or institution can consume.

Unify proof outputs under a receipt schema. Start by defining a compact, chain-agnostic receipt format (PIDL): the claim hash, workload ID, circuit or model hash, proof hash or transcript commitments, SLA tier, start/end timestamps, resource usage, and provider signatures. Whether the underlying artifact is a MatMul transcript, a logits fingerprint, or a SNARK, all of them fit into this envelope.

Expose a single programming surface. For developers, the SDK should offer one set of verbs: declare_claim, request_proof, await_receipt, verify_receipt. Underneath, it can target multiple proof systems and networks. The developer doesn’t wire to “Platform X”; they attach their claim and policy to the SDK and let it find anyone who can satisfy the SLA.

Integrate multiple zkVMs and proof systems from day one. Monoculture is the enemy of both security and economics. The factory should be multi-ZK and multi-backend by construction: support at least one pairing-based SNARK, one STARK or FRI-based system, and one zkVM at launch, with a clear path to adding more.

Make telemetry a first-class product. Every proof request and receipt should emit metrics into the VerifyPrice Observatory: p50/p95 verifier times and costs for each workload, failure modes, queue depths per backend, variance under adversarial mixes.

Compute Consensus Pilots

With privacy rails and proof factories in place, you can begin to anchor consensus itself in useful work. Think in terms of reference pilots, not one chain to rule them all.

MatMul PoUW pilot (Duplex-style):

Launch a devnet where the block-making puzzle is a MatMul instance drawn from a canonical distribution. Use the workload registry/WF-ABI to describe tasks; derive instances from header randomness; implement low-rank noise so that miners can return both a correct product and a succinct proof. Wire block validity to the presence of a valid MatMul receipt whose VerifyPrice parameters are below published thresholds. Instrument everything: $r(W)$ ratios, verifier times on consumer hardware, time-to-first-proof for new miners, and centralization metrics.

Verified-inference pilot (Ambient-style PoL):

In parallel, build a network where the work function is “serve model inferences with proofs of honesty.” Commit to models and datasets; design logits-fingerprint schemes that are simple, deterministic, and uniform; add randomized audits and peer-prediction-based slashing. Here full ZKML may be too expensive, so hybrid verification is acceptable, but only if it is exposed honestly: publish honest-output rates, audit coverage, and failure patterns as SLOs, not marketing.

zk-Proof-of-Work / receipt ledger pilot (Nockchain-style):

Finally, either integrate with or prototype a chain whose primary job is to produce and timestamp zk proofs themselves. This network can serve as a common receipt ledger: proofs from many domains are anchored here with minimal metadata and availability guarantees.

These pilots need not be over-promised as final destinations. Their job in the early years is to act as laboratories: to establish that verification asymmetry holds in practice at scale, that decentralization can be preserved under useful-work mining, and that receipts remain cheap to check.

Developer Kit: Make “Import Proofs” the Default

The last implementation sketch is about developer experience. If every application needs a team of cryptographers to participate, nothing scales.

Claims & proving library:

A library that plugs into common languages and frameworks and exposes a simple API: mark this function as “must be proven,” mark this data stream as “must be provenance-tracked,” specify acceptable backends and SLAs, and let PaL handle task generation and proof requests.

Settlement adapter:

A component that connects to existing wallets and key-management setups, and that exposes “pay-for-proof” and “pay-for-compute” as simple intents: no manual swap logic, no bespoke bridges, just a predictable interface plus receipts, backed underneath by PRK and the atomic-payout kernel.

Verification module:

Modules that can be compiled into smart contracts, browser bundles, and command-line tools, so that end-users and auditors can check receipts without standing up new infrastructure. verify(receipt) should be as embedded in the tooling as log() is today.

The work of the next few years is, in large part, to make these three pieces boring. When “import proofs” feels like “import TLS,” and when “settle privately” feels like “call the payments API,” the cypherpunk monetary stack stops being an argument and starts being the default way serious systems are built.

Tip: hover a heading to reveal its permalink symbol for copying.