Verification: CRPC, Committees, and the Trust Spectrum

Chapter 12 Verification: CRPC, Committees, and the Trust Spectrum This chapter addresses the question: how does the network know that work was done honestly? The answer is not a single mechanism but a spectrum, matched to the nature of the computation. Non-deterministic generative work requires fundamentally different verification than deterministic inference. 12.1 The verification spectrum Class Character Mechanism A Non-deterministic, multi-node CRPC-style aggregation + staking B Non-deterministic, single provider Reputation only (ERC-8004 signals) C Deterministic, provable ZKP, TEE attestation, or optimistic reexecution (EigenAI [25, 26]) Class A is the design frontier. It covers training (e.g., LoRA fine-tuning), generative inference (images, text, video), and prediction tasks where the “right answer” is unknown in advance. Class B is the default for most API-mediated inference today. Class C is narrower but offers the strongest guarantees. Class C Deterministic work TEE / zk / optimistic re-exec (EigenAI-style) Class B Single-provider inference ERC-8004 reputation signals Class A Non-deterministic multi-node CRPC + committees + stake Shared substrate: HTTP 402 proofs (x402, MPP) | ERC-8004 identity / validation URIs Figure 12.1: Verification spectrum (Chapter 12). Payment and identity layers underpin all three classes; mechanisms differ by determinism and trust model. 12.2 CRPC: Commit–Reveal Pairwise Comparison Protocol The full CRPC specification (Tim Cotten; in-repo reference document) defines a two-round commit-reveal scheme over a graph of worker nodes: 63

1. Round 1 — Work commitments. Each node Ni independently executes function f on work W , producing result Φi. It publishes a commitment H(Φi∥S1,i) to medium M (e.g., a blockchain). After all commits, nodes reveal Φi and salt S1,i. This prevents lazy output-stealing.
2. Round 2 — Pairwise comparison commitments. Each node computes the distance δij = |Φi − Φj | (or a domain-specific metric: cosine similarity, SSIM, L2 norm) with its graph neighbors. It commits H(δij ∥S2,i), publishes, then reveals. Matching reciprocal attestations (δij ≈ δji) prove honesty; divergence identifies dishonesty.
3. Originator verification. The originator O checks each reference comparison rij against an acceptable error threshold ε. Where rij < ε, outputs are consistent. Where rij ≥ ε, a dispute is flagged. 12.2.1 Proven properties The CRPC document works through adversarial cases for a K2 graph, showing that reciprocal attestations catch dishonest pairwise claims. For complexity reduction, ring topologies reduce edge count from O(n2) to O(n). The drift problem (accumulated error along a sparse ring) is solved via a Lipschitz bound: εlocal = εglobal ⌊n/2⌋ If all local edges satisfy εlocal, then all unmeasured transitive edges satisfy εglobal. The recommended minimum committee size is three nodes. 12.2.2 Explicit limitations The CRPC authors acknowledge three boundaries:
4. Consistent failure: If all nodes err identically, no alarm fires.
5. Silent false consensus: Shared bias within ε causes the originator to accept bad results.
6. Out of scope: Dispute resolution, decision logic, incentives, and collusion resistance are delegated to a broader mechanism. CRPC is the verification primitive. The network must layer staking/slashing (economic accountability), committee selection (who participates), and dispute resolution (what happens when rij ≥ ε) on top. 12.3 The LoRA training scenario The committed first use case for CRPC is LoRA fine-tuning verification. The critical design decision: CRPC verifies the results of training, not the weights themselves. Comparing raw LoRA weight deltas across nodes is fragile. Floating-point non-determinism across GPU architectures means identical hyperparameters and data can produce non-trivially different weight tensors even when every node trains honestly. Constraining to a single GPU SKU per committee or requiring deterministic training kernels narrows the network’s hardware base and defeats the purpose of decentralized compute. The solution is to move CRPC verification to the output layer: what matters is not whether the weights look the same, but whether the trained models behave the same. 64

12.3.1 Milestone-driven training with output verification

1. Training specification. The network distributes a training spec (base model checkpoint, dataset slice, hyperparameters, target milestone) to n ≥ 3 committee members. The milestone defines a measurable output target—e.g., directional prediction accuracy on a held-out evaluation set, perplexity below a threshold, or BLEU score above a floor.
2. Independent training. Each node trains its LoRA adapter independently. The network does not prescribe how nodes reach the milestone; it prescribes what the milestone is. Nodes may use different GPU hardware, different batch ordering, different learning-rate schedules—the results speak for themselves.
3. CRPC Round 1 — Output commitments. Each node runs its trained model against a standardized evaluation set (frozen inputs, published in advance). The node produces N outputs (e.g., 1,000 prediction simulations) and commits H(Φi∥S1,i) where Φi is the structured output vector. Reveal follows.
4. CRPC Round 2 — Pairwise output comparison. Nodes compute pairwise distances on the output distributions, not the weights. For prediction tasks, this is the statistical distance between each pair’s 1,000-simulation output vectors (e.g., Jensen–Shannon divergence, Earth mover’s distance, or simple distributional overlap). Commit, reveal.
5. Originator check. If all rij < εglobal, the training run is accepted. The ε threshold is empirically calibratable: honest nodes that trained on the same data with reasonable hyperparameters will produce outputs within a predictable statistical range. Malicious nodes (who submitted garbage weights) or lazy nodes (who skipped training entirely) will produce output distributions that diverge measurably.
6. Staking/slashing. Nodes that fail CRPC—output distributions outside ε or dishonest pairwise attestations—lose stake. Honest completers earn training rewards; when their LoRAs are deployed for inference, they earn usage-proportional rewards. 12.3.2 Why output verification works The statistical argument is straightforward. If three nodes independently train a LoRA adapter on the same dataset to the same milestone, and each then runs 1,000 inference simulations on a standardized evaluation set, the distributions of their outputs will converge within an empirically predictable range. This convergence is robust to: • Hardware variance: Different GPU architectures produce different weight tensors but functionally equivalent models. Output comparison is architecture-agnostic. • Training stochasticity: Random initialization, batch ordering, and dropout produce weightlevel variance. But models trained to the same milestone on the same data converge in output space even when they diverge in weight space. • Hyperparameter variation: Within reasonable bounds, different learning rates or schedules produce models that differ internally but agree on outputs for well-specified tasks. Conversely, a malicious or lazy node cannot fake convergence. A node that skips training and submits random weights will produce an output distribution that diverges from honest nodes’ outputs by orders of magnitude more than the honest-node ε range. A node that trains on corrupted data will fail the milestone. The outputs are the proof; the weights are an implementation detail. 65

This approach also eliminates the need for a centralized oracle to judge training quality. The committee is the oracle: independent nodes, each with economic stake, each producing verifiable outputs. Convergence across independent actors is the verification signal. Sidelines (Chapter 10, §10.2) provides the first production exercise of this pattern. 12.4 Ephemeral committees Static, long-lived validator sets suffer from targeted attacks (adversary knows who to bribe), stale reputation (quality degrades without renewal), and centralization (stake accumulates to the same nodes). Ephemeral committees — short-lived, per-task or per-epoch groups — mitigate all three by making membership unpredictable before selection and disposable after completion. 12.4.1 Prior art Algorand pioneered VRF-based self-selection [18]: each node evaluates a Verifiable Random Function seeded with its private key; only those whose output falls below a threshold become committee members. Membership is verifiable by anyone but unpredictable before evaluation. Pando (ePrint 2024/664) [19] demonstrates committee-sampled BFT scaling to 1,000 replicas at 62.57 ktx/s, selecting O(log n) members per round. Related asynchronous committee sampling literature [27] motivates ephemeral membership. VRF + VDF combinations enhance leader unpredictability and grinding-attack resistance. 12.4.2 Open design dimensions Dimension Options Selection VRF self-selection (Algorand) vs coordinator-assigned vs stake-weighted lottery Size 3-of-n for initial LoRA; general formula f (stake, task value, fault tolerance) Lifecycle Per-task vs per-epoch vs hybrid Composition Internal only (Layer A) vs mixed internal + external (A + B) Dispute resolution Majority vote, escalation to meta-committee, onchain arbitration (EIP-8183 evaluator) Collusion resistance Ephemeral + random is first defense; stake decorrelation; anonymous membership until reveal Incentive alignment Verifier compensation vs worker compensation; same nodes or disjoint? CRPC topology Ring (O(n)) vs denser graph; adaptive εlocal per task type Determinism boundary Which steps can become Class C (EigenAI) as tooling matures? 12.4.3 Ephemeral Rollups as committee substrate MagicBlock’s Ephemeral Rollups (ERs) [28]—dedicated SVM runtimes that spin up on demand with 10–50 ms block times, gasless transactions, and automatic teardown—are the proposed execution substrate for ephemeral committees on Solana. The mapping is direct: each CRPC committee gets its own ER. Committee members’ attestation accounts are delegated to the ER; commit-reveal rounds execute at 20 ms block times (sub-second for all n commits); gasless execution eliminates per-attestation fees; and the final 66

outcome settles atomically to Solana L1. When the committee’s work is done, the ER expires and account control reverts to the CRPC program. This creates a clean dual-chain architecture: Solana (via ERs) provides committee execution speed; Ethereum (via EigenLayer) provides economic security through staking and slashing. CRPC rounds happen fast on Solana; dishonesty is penalized on Ethereum. The same ER infrastructure scales game sessions (Chibi Clash) and verification committees—one primitive, multiple applications. ERs also handle non-CRPC verification: for Class C (deterministic) work, ER execution can produce ZK proofs verified on Solana L1 in a single transaction, complementing CRPC for tasks where deterministic re-execution is sufficient. The MagicBlock team shared the a16z CSX cohort with Scrypted; the integration is exploratory, with MagicBlock’s DePIN network providing Provisioners initially and Scrypted operating its own Provisioners as the network matures. 12.4.4 Phased rollout Phase 1 (testnet): Coordinator-assigned, 3-node committees with ring topology and manual ε calibration on output distributions for LoRA training. Sidelines prediction markets (§10.2) provide the first live exercise. Ephemeral Rollups on Solana for committee execution speed. Phase 2: VRF self-selection and dynamic committee sizing. Phase 3: Cross-layer (A + B) committees and on-chain dispute arbitration. Each phase is independently testable and produces reportable results. 12.5 EigenLayer integration path EigenLayer has rebranded AVS from “Actively Validated Services” to Autonomous Verifiable Services [14]: permissionless, self-sustaining, with deviations objectively identifiable and penalizable. Slashing on mainnet uses operator sets, custom conditions, and stake allocation per AVS [15]. EigenAI achieves bit-exact deterministic LLM inference on fixed GPU SKUs with low overhead; verification is optimistic (challenge-window re-execution to byte equality) [25, 26]. Verifiable general compute under the EigenCloud umbrella includes EigenCompute-class launches [16]. The layered security model for Scrypted: Class EigenLayer analog C (deterministic) EigenAI: deterministic inference + optimistic verification + slashing. Scrypted consumes as a verifiable backend for deterministic steps. A (non-deterministic, CRPC) AVS slashing conditions: CRPC dispute proof (mismatched rij ≥ ε + committed attestations) triggers slashing via an AVS-shaped contract. A (training) No direct EigenAI parallel (inference-only). CRPC fills the verification gap. Strategic risks and opportunities (vendor overlap, restaking contagion, routing productization) are consolidated in the competitive SWOT for the Eigen family (Chapter 14, §14.3); roadmap milestones are in Chapter 16, §16.3. 67

12.6 Bittensor comparison Bittensor uses subnets with per-subnet incentive mechanisms. Validators score miners and submit weight vectors; Yuma Consensus aggregates weights and distributes emissions. Top-64 nodes by emissions receive validator permits. A commit-reveal mechanism on weights (not work outputs) prevents validators from copying consensus. Scrypted’s design differs on three axes: (1) ephemeral per-task committees vs persistent top-k validator sets; (2) CRPC on work outputs vs commit-reveal on evaluation weights; (3) attentionauction economics vs emission-based rewards. The commit-reveal primitive is shared ancestry; the scope and lifecycle diverge. The whitepaper treats Bittensor as the category leader in decentralized AI network attention [29, 30], with a different trust model — not an inferior one. 68

Source: transcribed from the compiled Scrypted Network Design whitepaper PDF for web reading. Layout, figures, and pagination may differ from the PDF.