Gonka (GNK) Proof of Compute deep dive: sprint mechanism, statistical inference verification, and why 'rent GPUs 10 min/day + answer garbage' fails post-PoC-v2

gonka-poc-analysis.md

Gonka (GNK) Proof of Compute: Design, Choices, and Why "Rent GPUs for 10 Minutes a Day + Answer Garbage" Doesn't Work

Companion to the Pearl cuPOW analysis. Sources: whitepaper, github.com/gonka-ai/gonka (docs/gonka_poc.md, docs/specs/inference-validation-flow.md, chain params), current as of July 2026. Mainnet since Sept 2025; ~14K H100-equivalents as of Feb 2026.

TL;DR: Gonka is the economics-first counterpoint to Pearl's cryptography-first design. Chain voting power = compute demonstrated in a periodic seeded benchmark ("Proof of Compute sprint"), inference honesty = statistical logprob spot-checking priced by reputation, and security = escrow + collateral slashing + a majority-of-compute honesty assumption. The naive attack — rent hardware only for the sprint, then serve garbage — is killed not by cryptography but by three interlocking mechanisms: an unannounced mid-epoch Confirmation PoC that makes weight contingent on continuous residency, 100%-validation of new hosts that makes garbage detection immediate, and escrowed rewards + burned collateral that make getting caught cost more than a year of honest margin. Sybil (one weight copy, N identities, one GPU) earns nothing extra because reward tracks conserved, synchronously-measured throughput, not identity count — Gonka makes Sybil pointless rather than detecting it (§5). And the sprint itself exists only because Gonka is a sovereign token-emitting L1: PoC is the demand-independent consensus/Sybil/subsidy layer, structurally separate from — and not replaceable by — the inference verification that checks real served work (§6). What the design does not stop is subtler: emission remains demand-decoupled, quality can be degraded inside the statistical tolerance, and a >50%-compute cartel can validate its own lies.

---

1. Architecture in one paragraph

Cosmos SDK L1 (~5s blocks) with the staking module replaced: the CometBFT validator set's voting power each ~24h epoch (17,280 blocks) equals PoC weight — compute demonstrated in the previous sprint — not bonded stake (SetComputeValidators, docs/cosmos_changes.md). Every participant is a "Host" running a chain node + API node (Go orchestration, OpenAI-compatible API) + one or more ML nodes (vLLM/CUDA, ≥320 GB GPU VRAM per MLNode). Roles (executor / validator / transfer agent) are dynamic functions of hosts, weighted by PoC. Two income streams: Reward Coins (fixed per-epoch emission, 285K GNK initially with exponential decay, split pro-rata by PoC weight — the Bitcoin-like subsidy) and Work Coins (per-token user fees, EIP-1559-style). 1B GNK hard cap; 25% cap on any single participant's power.

2. Proof of Compute sprints

The sprint is a ~10-minute synchronized benchmark, once per epoch:

1. Sprint Seed — generated from latest chain state via threshold cryptography + commit–reveal among weighted hosts (whitepaper App. C). Nobody can precompute it.
2. Model — in PoC v1, the seed initialized a random-weight compact transformer (~2.3B params; 64 layers, 128 heads, vocab 8192). Since PoC v2 (mainnet v0.2.9, governance-approved), the sprint runs on the actual production serving model (currently MiniMax-M2.7 by proposal #78; previously Qwen3-235B-A22B-FP8).
3. Nonce grind — each host derives a Node Seed from its pubkey; nonce + seeds → input sequence → forward pass → last output vector → seeded random permutation (breaks neural-net continuity, so you can't gradient-descend toward targets) → Euclidean distance to a seed-derived Target Vector. Distance under threshold = "Appropriate Vector" (~1 in 900 nonces). Weight ∝ count of valid nonces.
4. Verification — replay: anyone can rebuild the model/target from the seed and re-run claimed nonces. The chain samples 200 nonces per batch and applies a binomial test (p-value 0.05); accept/reject by majority of weight. Artifacts live off-chain under Merkle Mountain Range commitments; only root + count on-chain.
5. Confirmation PoC — the crucial v2 addition: a second, randomly-timed PoC during the epoch is the authoritative weight source, and activation must complete in <5 s (i.e., the model must already be hot).

Design reading: this is Pearl's lottery with the binding strength dialed down and the flexibility dialed up. Pearl proves every winning matmul in ZK and needs int7 arithmetic + one canonical kernel schedule (hard fork per hardware generation). Gonka's replay-based verification tolerates any hardware and any model the network votes in — the price is that verification is sampled and social (majority weight), not per-block cryptographic. Note also that the sprint is sybil-neutral by construction: weight ∝ nonce throughput, and a GPU grinding for two identities splits its throughput between them — splitting buys nothing (the 25% power cap then bounds concentration from the other side).

3. Inference verification

Serving happens the rest of the epoch. Honesty is enforced by sampled re-execution:

• Secret-seed audit assignment. Each API node keeps a private per-epoch random seed. For every finished inference, ShouldValidate(seed, inferenceID, validator_weight) deterministically — but privately — decides whether this validator must re-check it. At claim time the seed is revealed in MsgClaimRewards; the chain recomputes the assignment and voids the entire reward claim (ErrValidationsMissed) if any required validation was skipped. Executors can't know which requests are being watched; validators can't skip work.
• Reputation-priced sampling rate. New hosts: 100% of inferences validated. The rate decays linearly over EpochsToMax = 30 epochs to MinValidationAverage = 0.01 (1%), with traffic gates (<100 req/epoch → validate all; ≥10,000 → 1% floor). A validated task's reward is split 50/50 with the checker, so an established host keeps ~99.5% in expectation.
• Logprob comparison under enforced decoding. The validator re-runs the inference forcing the executor's claimed output tokens and compares per-position top-logprobs: token mismatch → hard fail; otherwise a normalized distance is summed and similarity must exceed 0.99 (PassValue). Statistical machinery throughout (FalsePositiveRate 0.05, one-sided binomial tests, tanh-capped concurrent invalidations) so honest fp/hardware variance doesn't punish — only consistent deviation does.
• Escalation & punishment. Flagged results are re-verified by >50% of voting weight before invalidation. Caught → all escrowed epoch rewards forfeited, reputation reset to zero (back to 100% scrutiny), and since tokenomics-v2, collateral slashing: 20% for invalid inference, 10% for downtime, slashed GNK burned. Only 20% of a host's weight is usable without collateral. MissRequestsPenalty 1.0 + a binomial miss-rate test (1% cutoff) punish hosts that fail to serve assigned traffic; utilization bonuses (×1.5 factor, ×1.2 full-model-coverage) tilt income toward hosts that actually serve.

4. The attack: rent GPUs 10 min/day, answer everything with garbage

Decompose it into its two legs.

Leg 1: show up only for the sprint

Under PoC v1 this worked — the team admits it: the sprint ran on a synthetic model, so you could "spin up hardware just for the check and shut it down afterward," earning a full epoch's emission share for ~10 minutes of rented H100 time (~0.7% of the residency cost). This is the purest documented instance of the usefulness gap — same failure class as Pearl's junk-GEMM grinding, arrived at from the opposite design direction.

PoC v2 closes it with three moves:

1. Confirmation PoC is randomly timed and authoritative. Your initial sprint result is provisional; the weight that pays you comes from a re-check at an unpredictable moment in the ~24h epoch. If you're only resident 10 min/day, the probability the confirmation lands inside your window is ≈ 10/1440 ≈ 0.7%. Expected emission ≈ 0.7% of the honest share — strictly worse than not attacking, since you still paid for the sprint rental. To reliably pass confirmation you must be resident essentially the whole epoch — at which point you've paid the honest miner's cost.
2. The sprint runs on the production model with <5 s activation. You can't pass with a benchmark-only deployment: 320 GB of VRAM must hold the actual serving model, hot. There is no cheaper "sprint rig" to rent — the sprint rig is the serving rig.
3. Absence is independently penalized. While resident-in-name, you're assigned real inference traffic; missing >1% of assigned requests trips the binomial miss-rate test (MissRequestsPenalty 1.0), and downtime triggers a 10% collateral slash. So "resident but not serving" bleeds you even if confirmation is passed.

Cost arithmetic: the attack's entire premise is paying 0.7% of residency cost for 100% of emission share. Post-v2, retaining weight requires ~100% residency, missing traffic costs up to 10% of collateral per offense, and the rented window earns 0.7% of the share in expectation. The arbitrage inverts: the cheapest way to hold Gonka weight is to run an honest serving node. That's the design working as intended — the same inversion Pearl achieves with header-keyed noise, achieved here purely with randomized re-measurement and penalties.

Leg 2: respond with random stuff

Suppose you keep the hardware resident (leg 1 conceded) but return garbage to inference requests, hoping to skim Work Coins and emission without doing real forward passes:

• As a new host, you are validated at 100%. Your first garbage response gets re-executed by a validator with your claimed tokens enforced. A real model's logprobs on random tokens are catastrophically low — similarity lands nowhere near the 0.99 threshold. Hard fail, escalated to >50%-weight re-verification, invalidated.
• Rewards are escrowed until validation duties complete, so there is nothing to run away with: the epoch's earnings are forfeited, reputation resets to zero, and 20% of collateral is burned. With only 20% of weight usable collateral-free, a real attacker has real GNK at stake.
• As an established host (30 epochs of honest serving to reach the 1% floor): each garbage response is caught with ≥1% probability, and one catch forfeits the entire epoch's escrowed rewards + 20% collateral + the reputation asset (30 epochs of 50%-and-declining validation tax to rebuild). Expected penalty per garbage response ≈ 0.01 × (epoch rewards + 0.2·collateral + reputation value); the saving per skipped inference is one forward pass. For any plausible parameterization the expected loss exceeds the saving by orders of magnitude — and pushing volume to "get value before getting caught" doesn't work because detection probability compounds per response within the same epoch's escrow (surviving N garbage responses at the floor happens w.p. 0.99^N — under 37% by N=100).

So the headline attack is dead on both legs. Verdict: post-v2 Gonka cannot be profitably broken by sprint-only rental + garbage serving. The interesting question is what remains.

5. The Sybil variant: one weight copy, 1000 identities, one GPU

A natural follow-up: forget renting — I hold one GPU with the model loaded, register 1000 host identities, and answer whatever queries get routed to any of them. Don't I collect 1000× the rewards? No — and the reason is worth stating precisely, because it's the cleanest property in Gonka's design.

The root misconception is that each identity draws some baseline reward for existing. It doesn't. There is no per-node payment in Gonka. You are paid for exactly two throughput quantities, neither of which has an identity-count term:

• Reward Coins ∝ your PoC weight = valid nonces your hardware produced in the sprint.
• Work Coins ∝ tokens you actually served.

Trace the Sybil against each:

• Sprint (weight). The sprint has a synchronized start — every host mines in the same ~10-minute wall-clock window. Your one GPU can run only capacity × 600 s of forward passes in that window, producing a fixed nonce count N. Weight is additive, so splitting N across 1000 identities still totals N. You cannot "run the sprint 1000 times, once per identity," because all 1000 sprints happen in the same 10 minutes — a GPU can't be in two places at once. Emission share = N / (network total), identical to a single identity.
• Serving (tokens). Your GPU can answer any individual query (you hold the weights) — that intuition is correct. But the total tokens across all 1000 identities is still ≤ capacity × time. One GPU is one GPU's worth of tokens/sec no matter how many labels you attach. Work-Coin income is capped at one GPU's worth.

So 1000 identities buy you exactly one GPU's worth of both streams. And the moment you try to earn more than that — by advertising 1000 nodes' capacity — the router assigns you ~1000 GPUs' worth of traffic, you serve ~0.1% of it, and you miss the rest: the binomial miss-rate test (MissRequestsPenalty 1.0) fires and downtime slashing (10%) bites. Over-claiming is strictly negative-EV.

The elegant part: Gonka does not detect that your 1000 identities are one machine — no TEE, no hardware attestation, no device fingerprint. It doesn't need to. Because reward tracks conserved, synchronously-measured throughput, identity multiplication is made pointless rather than detected. Identities are just labels on a finite, continuously-proven pipe. (The one place this leaks: the 25% governance power cap is per-identity, so splitting lets concentrated compute hide from the cap — a consensus-control concern, not a free-reward one.)

6. Why does PoC even exist, if inference is already verified?

The sharpest question about Gonka: if the logprob check already verifies served work honestly, why is the sprint needed at all — isn't PoC just an elaborate way to hand out passive mining rewards?

They answer different questions, and PoC's are ones verification structurally cannot. Inference validation asks "was this specific served query honest?" — a per-request check on work that already exists. PoC answers three questions that have nothing to do with any query:

1. Who is a validator, and how much voting power do they have? Gonka is its own BFT chain (676 computors, quorum 451) and replaced stake-weighting with PoC-weighting. Something has to select and weight validators.
2. How is the emission subsidy split? Reward Coins are a fixed Bitcoin-style issuance; PoC weight is the allocation key.
3. Is the chain secure right now, even with zero user traffic?

Verification cannot do any of these, because:

• It only measures work that exists. In an idle hour the logprob check has nothing to sample, but the chain still must produce blocks and resist takeover. PoC is demand-independent — the sprint runs on schedule regardless of traffic. A consensus basis that goes blind when demand dips is not a consensus basis.
• Served-volume is a gameable weight source. Weight-by-tokens-served means whoever controls routing controls voting power. The sprint is a synchronized snapshot measured for everyone at the same instant — a fair basis; demand-driven serving isn't.
• It proves honesty, not commitment. Sybil resistance needs something scarce staked. PoC makes committed GPU-compute that scarce thing (replacing capital-stake). Honestly serving two queries shouldn't buy a validator seat.

So is PoC "just passive mining rewards"? Largely, in economic terms — yes, and that's the tell. The genuinely useful work (serving) is metered and verified separately. PoC is a parallel compute burn whose only outputs are a Sybil-resistant weight number and a justification for the subsidy — precisely the "reward benchmarkable capacity" pattern flagged across this series as farming-prone. PoC v2 minimized the waste (sprint runs on the production model, on the same rig that serves) but the cycles still serve no user; ~10 min out of 24 h, gating the large reward component (emission dominates fee revenue on a young network).

The deep point: PoC is the price Gonka pays for sovereignty. Being its own token-emitting L1 forces a demand-independent Sybil mechanism and a subsidy-distribution key; PoC is the least-wasteful version they could engineer. A network that instead inherits consensus from an existing chain pays none of this — it can weight and pay providers directly by verified, demand-driven work, and keeps only the honest half (verification of work someone actually demanded). That is exactly the architectural fork between Gonka and a settle-on-an-existing-chain design: the sprint exists to secure a chain and mint a token; delete those two choices and the sprint has no job left to do.

7. What the design does NOT stop

1. Emission is still demand-decoupled. Weight measures benchmark nonce-throughput, not user tokens. A host serving zero organic traffic (in an oversupplied network) still collects emission for residency. This is a softened usefulness gap — you must hold serving-capable, serving-resident hardware — but token issuance, not demand, pays for most of the fleet. Whether that's a bug or Bitcoin-style bootstrapping is an economics bet, not an engineering property.
2. Quality degradation inside the tolerance band. The 0.99 similarity threshold plus statistical forgiveness (α=0.05, tanh caps) is attack headroom: serve int4/fp8 quantized where fp8/fp16 is claimed, prune KV cache, use a cheaper draft-model pipeline — anything whose logprob drift stays under threshold pockets the compute savings. The repo's own fuzz tests and int4/fp8 test fixtures (compare_logits_fuzz_test.go) show the team actively fighting exactly this; it is an arms race, not a solved problem. (Same class as TOPLOC's speculative-decoding blind spot.)
3. Majority-compute collusion. Validators are the compute hosts; invalidation requires >50% of weight. A cartel above that line can approve its own garbage and reject honest work. Pearl needs no such assumption (any node re-verifies the ZK proof); Gonka inherits it structurally, capped only by the 25%-per-participant limit and the cost of weight.
4. Sprint-model specialization. With one exclusive PoC model (MiniMax-M2.7 by proposal #78), kernel/hardware specialization for that model's exact shapes optimizes sprint throughput without improving general serving — a mild benchmark-overfitting channel that governance re-model votes only partially reset.
5. Self-documented operational attack surface. The repo's candid devshard/docs/attacks.md lists real fixed and open vectors: timestamp manipulation for refunds (fixed via signed confirmed_at), seed grinding via signature malleability, gossip poisoning, and an open mempool-DoS TODO. Worth reading as a model of honest threat documentation.

8. Gonka vs Pearl, side by side

	Pearl (cuPOW)	Gonka (PoC)
Work binding	Per-block ZK proof of noised int7 GEMM	Sampled replay of seeded forward passes + majority vote
Verifier trust	None (anyone verifies the SNARK)	Majority of compute weight is honest
Guarantee granularity	Every block, cryptographic	Statistical, expected-value deterrence
Usefulness coupling	None enforced (junk matrices validate)	Soft: sprint on production model + residency + serving penalties; emission still benchmark-driven
fp nondeterminism	Avoided (exact integer arithmetic)	Tolerance bands (0.99 similarity, binomial tests)
Hardware	H100/H200 only (sm90 kernels frozen into consensus)	Any GPU that fits the model (~40 SKUs observed)
Model flexibility	Any int7 checkpoint (but kernel-locked)	Governance-voted production models, swappable
Upgrade cost of new hardware/model	Hard fork (new mma_type + ZK circuit)	Governance proposal
Attack that worked in production	Junk-GEMM grinding (usefulness gap — by design unpunished)	Sprint-only rental (PoC v1 — patched in v2)
Residual soft spot	Nothing ties work to demand at all	Tolerance-band degradation; >50% collusion

The two projects are limit points of the same trade-off: Pearl buys per-block trustlessness by freezing numerics and hardware into consensus; Gonka buys hardware/model flexibility by accepting statistical guarantees and a compute-majority assumption. Both independently rediscovered the same two ingredients — an unpredictable challenge derived from chain state, and work commitments checked by (full or sampled) re-execution — which by mid-2026 looks like the convergent design for verifiable AI compute everywhere outside TEE land.

---

Sources

• Gonka whitepaper · tokenomics · architecture docs · FAQ
• Repo: gonka-ai/gonka — docs/gonka_poc.md, docs/specs/inference-validation-flow.md, docs/binom-stattest.md, inference_validation.go, params.go, devshard/docs/attacks.md, collateral proposal
• PoC v2 upgrade coverage · Bitfury $50M · Feb 2026 scale stats
• Companion: Pearl cuPOW analysis

Analysis produced with Claude Code from public sources and the gonka-ai/gonka repository, July 2026. Parameter values quoted from chain defaults; live values may differ by governance.