Gonka explained
A source-grounded visual tutorial

Gonka’s decentralized AI thesis, made explicit.

The paper proposes a blockchain-coordinated market for AI compute. Here, the blockchain is the shared record and rule system; the heavy AI math still runs on GPUs outside that record. The network briefly measures each provider’s capacity, turns the result into voting and work weight, then spends most of the cycle on inference and training.

1
The key move A Sprint is the paper’s name for a short, synchronized Transformer benchmark, illustrated as about ten minutes. It estimates how much AI-relevant compute each hardware provider controls. The validated score becomes Proof of Compute (PoC) weight, which governs the network until the next Sprint.
Start with the blockchain primer
≈10 min Illustrative benchmark (“Sprint”) duration paper p. 6
1 / 900 Target hit rate per trial number (“nonce”) paper p. 18
1–10% Claimed task repetition after spot checks paper p. 8
20% Inference revenue reserved for training paper p. 11
SPRINT short AI-shaped benchmark Random seed shared starting value PoC compute-derived weight Work inference + training Audit random verification Settle pay or penalize A B C MEASURE → ASSIGN → WORK → VERIFY → SETTLE
00 / Read this first

Blockchain, consensus and the paper’s labels, without assumed expertise.

The paper uses blockchain as a coordination layer for independent GPU providers. Before the AI details, four concepts matter: a shared ledger, blocks of new records, consensus about which records count, and a rule for assigning voting weight. The explanations in this section are background context; paper-specific uses are marked with page references.

The simplest mental model

Gonka is a GPU marketplace with a blockchain control plane.

The GPUs perform large model inference and training. The blockchain keeps the shared, tamper-evident record of who has weight, which work was assigned, which checks were required, what was signed, what was paid and which protocol votes passed.

The chain coordinates the work; it does not perform most of the AI work. This distinction explains why the paper stores compact hashes and commitments on-chain while keeping large training artifacts off-chain. paper pp. 24–25

01

Ledger

An ordered record of events and balances. In a blockchain, many computers hold copies instead of trusting one database owner.

02

Block

A batch of new ledger entries. A block can contain transfers, task records, signatures, commitments or votes. Accepted blocks extend the shared history.

03

Consensus

The protocol rules computers use to agree on the accepted next block and therefore the accepted history. This is operational agreement, not general social consensus.

04

Voting weight

The amount of influence a participant’s signature carries. “Majority” means more than half of total weight, not necessarily more than half of the people or machines.

×∞
Why not give every computer one vote?

One actor can create thousands of identities or nodes. That is a Sybil attack /ˈsɪbəl/: fake multiplicity makes one actor look like a crowd. Consensus mechanisms therefore tie weight to a scarce resource that is harder to fake, usually computation or locked capital.

The relevant proof mechanisms

Proof of Work and Proof of Stake answer the same question differently.

The question is: what scarce resource determines whose view counts? The resource does not make participants honest by magic. It makes majority control expensive and gives the protocol a measurable basis for weighted decisions.

Background concept01

Proof of Work (PoW)

Voting influence comes from demonstrated computation. In Bitcoin, miners repeatedly try numbers until a block hash meets a difficulty target.

Scarce resourcehardware, electricity and time
  • Creating valid evidence requires many attempts.
  • Checking a claimed winner is cheap.
  • Traditional PoW keeps running because the current race selects and secures blocks.
Plain meaning: “My vote counts because I can show that I spent compute under the agreed rules.”
Background concept02

Proof of Stake (PoS)

Voting influence comes from cryptocurrency locked as stake or collateral. Protocol rules select or weight validators partly according to that committed capital.

Scarce resourcelocked coins and economic exposure
  • It avoids continuous compute races.
  • Misbehavior can lead to lost rewards or locked assets.
  • Influence tends to follow capital ownership rather than useful compute contribution.
Plain meaning: “My vote counts because I have capital locked and can be penalized.”
Paper’s proposed mechanism03

Gonka’s Transformer-based PoW

Hosts run a short, synchronized computation test shaped like a small Transformer workload. The test is periodic rather than continuous.

Scarce resourcerecently demonstrated AI-style compute, with optional GNK collateral
  • The timed test is called a Sprint.
  • Valid hits become Proof of Compute (PoC) weight.
  • That weight is reused for block consensus, job share, audit duty, rewards and governance.
Plain meaning: “My vote and job share count because I recently demonstrated this much Transformer-class throughput.” paper pp. 5–6, 17–18
What method?

Transformer-based Proof of Work

The kind of costly, verifiable computation the protocol asks Hosts to perform.

When does it run?

Sprint

The synchronized, time-bounded event in which every Host performs that computation test.

What comes out?

PoC weight

The numerical share of total verified compute credited to a Host and used during the following cycle.

Terminology correction: “Proof of Action” is not defined or used by this white paper.

The relevant comparison is Proof of Work versus Proof of Stake. Gonka proposes a Transformer-based form of Proof of Work; the timed event is the Sprint; the score produced by it is Proof of Compute weight. Other projects may use “Proof of Action” in unrelated ways, but it is not needed to understand this paper.

People, machines and temporary roles

A Host, a node, an executor and a validator are not four separate kinds of company.

The paper shifts between provider names and work roles. Keeping them separate prevents a common reading error: the same Host can execute one task and validate another.

Owner + software

Host and node

A Host is the hardware provider or operator. A node is the computer and protocol software that the Host runs to participate in the network.

One Host may operate one or several nodes, subject to the protocol’s identity and weight rules.
Temporary work roles

Executor and validator

An executor performs an assigned AI task. A validator checks another Host’s result. These are roles in a task, not necessarily permanent organizations.

The paper also uses weighted majority re-verification when a spot check raises a dispute.
Customers

Developer and user

A Developer builds an application and sends model requests through an API. A User is the end person using that application.

Developers pay for compute; Users create the underlying demand and may challenge suspicious results.
On-chain

Small records replicated by the blockchain.

“On-chain” means written into the shared blockchain state so nodes can agree on and audit it.

  • Compute weights, signatures, votes and payments
  • Task duties, reward state and compact commitments
  • Hashes that fingerprint larger training artifacts
Off-chain

Large data and computation kept outside the ledger.

“Off-chain” means handled by Hosts without copying the full payload into every blockchain node.

  • Transformer forward passes and model training
  • Large model states, optimizer states and datasets
  • Artifacts revealed only when a validator requests them
Consensus vs governance

Agreeing on history is not the same as changing the rules.

Consensus decides which block and ledger history the network accepts now. Governance decides whether to change protocol parameters or rules. Gonka proposes using compute-derived weight for both.

Epoch / cycle

The interval from one Sprint to the next.

The paper uses both “cycle” and “epoch” in nearby contexts. This tutorial uses epoch for the operational window in which the latest PoC weight remains active and rewards accumulate.

Hash commitment

Publish the fingerprint now; reveal the data later.

A hash is a fixed-size digital fingerprint. Publishing a hash of data commits a Host to that exact data without putting the large data on-chain. A later reveal can be checked against the fingerprint.

From here on, technical terms with a dotted underline open a plain-language definition. The complete searchable terminology guide is near the end of the page.
01 / Thesis

The paper is solving two different wastes.

The argument begins with centralized AI clouds, then turns to decentralized networks. The paper treats both as misaligned, but for different reasons. Centralized systems concentrate pricing and control. Existing crypto systems spend too much on consensus, capital subsidies or duplicate verification instead of delivering AI work. pp. 1–4

Paper’s diagnosis

Centralized cloud

  • Large providers can charge smaller buyers more than strategic enterprise customers.
  • Developers remain subject to platform policies, monitoring and withdrawal of service.
  • Buying hardware can lower unit cost, but it sacrifices elasticity when demand varies.
Efficient operation, concentrated market power
Paper’s diagnosis

Traditional decentralization

  • Proof-of-Work (PoW) assigns weight from demonstrated computation; traditional designs run the compute race continuously.
  • Proof-of-Stake (PoS) assigns weight from cryptocurrency locked as stake or collateral.
  • Decentralized AI often repeats expensive tasks to make results trustworthy.
Distributed control, high security and verification overhead
Proposed design

Periodic AI-shaped Proof-of-Work

  • Run a short, synchronized benchmark called the Sprint.
  • Count validated hits to produce Proof of Compute (PoC) weight.
  • Keep that weight active for consensus, job assignment, audits and rewards until the next Sprint.
The intended result: security overhead becomes a small duty cycle
The decisive assumption: a short benchmark can produce a trustworthy snapshot of each Host’s continuing, AI-relevant capacity. If the snapshot can be rented, gamed or decoupled from later service, the system’s security and workload allocation both weaken.
02 / System map

One measurement drives four powers.

A block is a batch of new ledger records, and governance is voting on changes to protocol rules. The Sprint score is not used only to approve blocks: the proposal reuses the same Proof of Compute weight for governance influence, task share, validation duty and compensation. Any benchmark bias therefore propagates through the whole network. pp. 5–7

Developer API prompts, models, max compute price Chain + scheduler assigns work by compute weight records duties and escrow Host A execute + validate Host B execute + validate Host C execute + validate Sprint shared random model nonce search proof count → weight Audit pool pseudo-random checks majority recheck Settlement release rewards or forfeit cycle escrow THE SAME PROOF-OF-COMPUTE WEIGHT SECURES, ROUTES, CHECKS AND PAYS
Consensus Weight says whose signature counts.

Hosts representing more than half of active compute weight can confirm blocks and disputed results, under the paper’s honest-majority assumption.

Allocation Weight says how much work a Host should receive.

The scheduler attempts to keep utilization and reward share proportional to demonstrated capacity.

Obligation Weight also creates a duty.

A Host must execute its proportional workload and perform its proportional validation share. Missing either can reduce or erase rewards.

Consequence Benchmark quality becomes constitutional.

If Sprint performance does not track production performance, the wrong Hosts gain control, jobs and revenue at the same time.

03 / Sprint

A transformer forward pass becomes a lottery ticket.

During the Sprint, every Host (hardware provider) rebuilds the same compact Transformer from a shared random seed, a starting value that deterministically creates the same model and target. The Host then varies a nonce, an arbitrary trial number, to generate input after input. A trial counts as a proof only when its final vector lands close enough to the target. Faster hardware can try more nonces before time expires, so valid-hit count estimates throughput. pp. 17–20

Mechanism
Generate a shared Sprint seed.The seed must be unknown before the starting gun and identical for every Host. It initializes the model and target.
Bind each Host to its public key.A public key is the Host’s verifiable network identity. A Host-specific Node Seed ties winning nonces to that identity so another Host cannot copy and claim them.
Turn each nonce into an input sequence.Nonce + Node Seed + Sprint Seed deterministically create the Transformer input.
Run the Transformer.The paper specifies 64 layers, 128 heads, embedding width 512, feed-forward width 8192, vocabulary 8192 and sequence length 4.
Scramble and measure the last vector.A nonce-dependent coordinate permutation is applied, then Euclidean /juːˈklɪdiən/ distance to the target is computed.
Reveal only winning nonces.The threshold is tuned so one attempt wins about once in 900 tries. A validator, meaning another Host assigned to check the claim, reruns those winners and counts valid proofs.
d(x,t) = √ Σi=1512 (xi − ti)²
valid proof when d(x,t) < τ, with P(hit) ≈ 1/900
Why it measures speed

Each ticket costs a real forward pass. Faster transformer hardware prints more tickets before time expires.

Why validation is cheaper

The Host does every attempt. A validator only reruns the small set of claimed winners, roughly one pass per 900 attempts.

What it does not prove

It does not prove the Host will keep the hardware online, serve long contexts well or behave honestly after Sprint.

04 / What the math implies

Shorter Sprints save energy, but make voting weights noisier.

A binomial count is simply the number of wins in repeated yes/no trials with the same win chance. If a Host completes n attempts and each wins with probability p, the long-run average is np. The standard deviation, roughly √np(1−p), is the typical random distance from that average. Dividing that deviation by the average gives relative measurement noise, which falls only as 1/√hits. The design must collect enough hits to rank Hosts reliably without making validation expensive. The paper states the threshold but does not calibrate this tradeoff.

At 90,000 attempts
100

Expected hits

One-standard-deviation relative noise is about 10%. A 95% band is roughly ±19.6%. Two similarly sized Hosts can swap rank by chance.

At 900,000 attempts
1k

Expected hits

One-standard-deviation relative noise falls to 3.2%. The approximate 95% band is ±6.2%. Better, but still material for close competitors.

At 9,000,000 attempts
10k

Expected hits

One-standard-deviation relative noise is about 1%. Stable measurement now requires validators to replay around 10,000 winning passes per Host.

Design tradeoff: decreasing the hit probability makes proofs cheaper to validate but increases sampling noise. Increasing Sprint duration improves measurement precision but spends more GPU time on a synthetic security benchmark rather than user work.
05 / The duty cycle

Measure briefly. Work for the rest of the epoch.

An epoch here means the operating interval from one Sprint to the next. A duty cycle is the fraction of that interval consumed by the benchmark. The paper suggests a roughly ten-minute Sprint and says a tuned cycle might correspond to about 24 hours; if those illustrative values were used, the Sprint itself would occupy about 0.7% of the epoch before validation and blockchain overhead. The latest Proof of Compute weight remains active during the rest. pp. 5–8

Starting gun

1. Random seed

Hosts jointly establish an unpredictable Sprint seed. No one should be able to prepare model outputs in advance.

≈10 minutes

2. Sprint

Every Host runs the same AI-shaped nonce search. Winning nonces establish the next compute-weight distribution.

Most of epoch

3. Useful work

Hosts serve inference, validate peers and potentially participate in training. Work share follows the Proof of Compute score from the last Sprint.

Continuous

4. Escrow + audit

Rewards remain pending. Random checks and user challenges can trigger majority re-verification.

Cycle end

5. Settle + reset

Honest Hosts receive rewards. Fraud can erase the cycle’s earnings and reset reputation. A new Sprint replaces the old weight.

Why the snapshot exists

Continuous PoW would defeat the purpose.

The whole proposal depends on reusing a short compute measurement across a much longer useful-work window. The security cost is approximately Sprint duration divided by cycle duration, plus validation and chain overhead.

Snapshot risk

Capacity can disappear after the photograph.

A Host could rent GPUs for Sprint, earn weight, then release them. The paper’s workload-proof penalties and GNK collateral are intended to make this unattractive, but the exact anti-rental economics and availability tests are not specified.

06 / Verification

Spot checks turn honesty into an economic bet.

The network does not replay every inference. It uses a pseudo-random rule: the selection looks unpredictable to the Host but can later be reconstructed and audited from signatures and task IDs. The Host’s cycle rewards remain in escrow, meaning earned but temporarily locked, and can be forfeited if fraud is established. A validator here is another Host assigned to check a result. pp. 7–10

Probability of detection

One audit is weak. Repeated chances compound.

If each cheated task has independent audit probability q, and a Host cheats on m tasks, the probability of at least one detection is:

P(caught) = 1 − (1 − q)m
63.4%chance of at least one detection

This is the basic deterrence math, not a complete security model. Audits can be correlated, validators can collude and some attacks may be hard to classify.

Economic condition

The expected penalty must dominate the savings from cheating.

A rational Host compares the extra cost it avoids by using a smaller model, skipping work or returning manipulated output against the risk of losing escrowed rewards and reputation.

Expected cheating value
= (1 − Pcaught) × extra savings
− Pcaught × forfeited escrow
− future reputation loss
Detection probability as cheating repeats

Blockchain systems often call a forced economic loss slashing. This paper clearly describes forfeiture of the cycle’s pending rewards and a reputation reset; it defers exact collateral and slashing rules to a separate Tokenomics document. It does not provide a quantitative parameter set proving that every profitable attack becomes unprofitable.

Model substitution

Use a cheaper or smaller model, return a plausible answer and collect the full fee. Exact detection requires a concrete output-equivalence test.

Selective cheating

Cheat only on requests that seem hard to audit or low-value. Independent uniform spot checks may not match the real risk distribution.

Verifier collusion

An executor and assigned validators can cooperate. The paper relies on weighted majority re-verification and assumes most compute weight is honest.

Manipulated content

A Host can insert advertising, misinformation or policy-biased text. Determining “correct” generative output is often subjective rather than mathematical.

Challenge spam

User-paid reports create accountability, but fee and bounty calibration must prevent harassment, denial of service and bounty farming.

Numerical variance

Different hardware and kernels can produce small output differences. The paper explicitly treats verification as statistical, with thresholds and majority rechecks still to be defined.

07 / Reputation

Trust is earned by lowering your audit tax.

An executor is a Host while it performs an AI task. New executors begin with zero reputation and may have every task checked. In the high-volume regime, the paper proposes a linear reduction from 100% validation to 1% over N days or epochs (network cycles), with a default example of 30. Fraud resets reputation to zero. pp. 9, 22–23

Published high-volume curve
v(d) = 1 − 0.99 × MIN(d, N) / N    with N = 30
Validation probability over reputation age

The paper separately says low volume, at 100 or fewer requests per day or epoch, validates every task. It describes a linear medium-volume adjustment but does not give a complete formula.

Executor economics

Validation is paid from the executor’s reward.

When a task is checked, the reward is split between the executor and validator or validators. Lower validation frequency therefore means higher expected take-home reward.

New Host
50%
Day 15
74.8%
Day 30+
99.5%

These are expected executor shares if each audited task is split 50/50 and the high-volume validation curve applies.

Implication: reputation reduces network overhead, but it also gives incumbents a large margin advantage over new Hosts. A robust identity and reputation-transfer policy becomes economically important.
08 / The hard trust problem

AI output is not a block hash.

A block hash is a deterministic digital fingerprint: replaying the same calculation should produce the same value. Generative inference, meaning running a trained model to produce an answer, is harder to compare. Sampling, floating-point order, quantization (lower-precision number formats) and hardware kernels can yield different tokens or logits (the model’s raw next-token scores). The paper therefore proposes statistical judgments plus weighted-majority re-verification, but the acceptance test remains underspecified. pp. 8–9

01

Flag

A random validator or user challenge marks a result as suspicious. One mismatch is not enough to declare fraud.

02

Re-run

Additional Hosts representing a majority of compute weight reproduce or statistically compare the result.

03

Threshold

The system tolerates a limited error rate so hardware variance does not punish honest Hosts for one deviation.

04

Settle

Consistent outliers can lose the cycle’s rewards and reputation. Honest differences must remain below a model-specific boundary.

What can be made deterministic

Fixed model, fixed prompt, fixed seed, fixed decoding.

Constrained inference can be close to reproducible when the protocol pins weights, quantization, tokenizer, sampling parameters and numerical implementation. The more freedom a Host has, the harder exact verification becomes.

What still needs a specification

Equivalence, tolerances and adversarial edge cases.

The white paper does not define whether validators compare exact tokens, logits, embeddings, task-specific scores or human judgments. Each option changes cost, false-positive risk and the attacks that remain possible.

09 / Inference product

The user experience is meant to look ordinary.

Inference is the act of running a trained model on a new prompt to produce an output. Developers submit those requests through an API similar to centralized model APIs. The network chooses a Host running an approved open model, returns the output and accounts for cost. Underneath that familiar surface sit compute-weighted routing, locked pending rewards, validation and dispute handling. pp. 10–11

Hosts

Provide GPUs, execute inference, verify peers and receive both protocol emissions and user-paid work rewards.

Developers

Choose supported open models, submit requests and set maximum compute cost through an API.

Users

Generate demand and can trigger paid challenges when output appears incorrect or malicious.

Product advantage

Open model access without one cloud gatekeeper.

The network could make capacity and pricing more contestable while allowing developers to avoid a single provider’s model policy, account controls and margin structure.

Product gaps

Privacy, latency and service levels are not solved by decentralization alone.

The routing scheme hides a user’s IP from the executor through an intermediary Host, but the paper does not provide prompt confidentiality, trusted execution, end-to-end encryption for model inputs, latency guarantees or availability guarantees.

10 / Decentralized training

Train locally for a long time, synchronize occasionally.

The training plan combines DiLoCo /daɪˈloʊkoʊ/, a low-communication training method, with blockchain coordination, proof-of-learning style audits and model sharding, which splits a large model across participants. DiLoCo lets Hosts take many local optimizer steps before synchronizing. “On-chain” coordination records the schedule and commitments in the shared ledger; bulk model data remains “off-chain” on the Hosts. pp. 11, 24–26

DiLoCo pattern
Host A

Many local AdamW steps on assigned data or model path.

Host B

Works independently instead of exchanging gradients every step.

Host C

Commits selected state hashes for later verification.

Host D

May train only a model shard or Mixture-of-Experts path.

Periodic outer synchronization
On-chain records coordinate which Hosts participate, what role each has and when aggregation occurs. Bulk model state remains off-chain.
Proof of learning

Commit the before and after state.

“Proof of Learning” is evidence that a claimed training update followed from a real training step. At pseudo-random checkpoints, a Host preserves previous weights, current weights and optimizer state, then writes their hashes, or digital fingerprints, on-chain. Validators can demand the large off-chain artifacts and check them against those commitments.

Validator oversight

Check the checkers.

Validator judgments remain on-chain. Honeypot submissions and re-validation are intended to reveal lazy or colluding validators.

Sharding

Do not require every Host to hold the whole training model.

Sharding divides model parameters among Hosts. The proposal points to Mixture-of-Experts (MoE), where only selected expert subnetworks run for a token, and path-composition research so each Host can train a subset while the combined model is much larger.

What this buys

Lower communication and no permanent central coordinator.

Periodic synchronization makes geographic distribution more plausible. On-chain coordination can survive individual coordinator failure and creates an auditable schedule.

What remains research

Validation cost, data integrity and integrated scaling.

Checking optimizer transitions can itself be expensive. A valid-looking step can still use poisoned data or optimize the wrong objective. The paper provides an architecture direction, not end-to-end empirical results for untrusted large-scale training.

11 / Economics

Users pay for work. Emissions subsidize the network.

The paper describes two reward streams denominated in GNK. Token emission means the protocol creates new coins: these “Reward Coins” are allocated by the Proof of Compute weight produced in the last Sprint. Separate “Work Coins” are developer payments for actual inference. Emission declines on a Bitcoin-style schedule, and 20% of inference revenue is reserved for future training. pp. 11–12

Revenue sources

GNK inflow

Protocol emissionReward Coins
Developer paymentsWork Coins
Distribution

Where value goes

Execution + validationHosts
Inference revenue reserve20% training
The subsidy effect

Cheap service is partly paid by token issuance.

Early emissions can let customers pay less than the full hardware cost while Hosts still earn enough. The cost does not disappear. It is transferred to token dilution, meaning each existing coin represents a smaller share of a larger supply, and to whoever values or buys GNK.

Demand dependency

Scarcity is not demand.

A declining emission schedule does not mechanically raise token value. Host economics improve only if real usage, fee revenue or external token demand grows fast enough as issuance falls.

Gas-like execution

Running out of compute can consume the payment.

“Gas” is blockchain terminology for metered execution cost. EIP-1559 is Ethereum’s fee-market design; the paper borrows its idea of a protocol-adjusted price and a user-specified maximum. If compute is exhausted before completion, the task is canceled and spent coins are not refunded.

Cold-start tension: low request volume causes more validation and more dummy work, which raises cost. Lower prices may depend on token subsidy, while token value depends on future demand. A launch plan must break that loop with committed workloads, subsidized liquidity or both.
12 / Governance

Compute earns influence. Capital unlocks most of it.

Governance means voting to change protocol parameters or rules; it is distinct from consensus about the current ledger. The paper makes governance compute-weighted rather than purely coin-holder weighted. Only 20% of a Host’s Proof of Compute weight is active automatically. Activating the remaining 80% requires GNK collateral, coins locked as economic exposure. paper p. 13

20%active by default
80% needs GNK collateral
Compute earnedCapital activated
33.4%
Quorum

Quorum is the minimum participation required for a vote to count. At least this fraction of active compute-derived voting weight must participate or the proposal is invalid.

>50%
Majority threshold

More than half of weighted votes that choose Yes or No must approve; abstentions are excluded from this calculation.

33.4%
Veto threshold

NoWithVeto is a special rejection vote. If it reaches this share of non-abstaining weight, the proposal fails even when ordinary Yes votes would otherwise win.

Motivation and consequence

Collateral limits hit-and-run governance, but reintroduces wealth.

Requiring GNK makes it costly to rent compute briefly and govern without exposure. It also favors large, well-capitalized Hosts. The design is not pure “one compute unit, one vote”; it is compute-weighted influence gated by capital.

13 / Claim audit

The mechanisms are clearer than the evidence.

The white paper is an architectural proposal. It gives enough detail to understand the intended system, but not enough empirical or economic evidence to establish its strongest cost, utilization, security and scaling claims. The table below separates each claim from the mechanism offered and the missing proof.

Claim
Mechanism in the paper
Evidence still needed
Almost 100% meaningful compute

The paper contrasts Gonka with continuous PoW and high staking rewards.

Short Sprint + 1–10% spot checks

Most of the cycle is reserved for inference or training.

Measured end-to-end overhead

Sprint, dummy tasks, proof replay, disputes, chain coordination, idle capacity and failed jobs all consume resources.

Lower cost than centralized clouds

The paper suggests subsidies and competition can reduce prices materially.

Open provider market + token emission

Hosts compete and protocol rewards offset hardware cost.

A complete cost model

Hardware, power, bandwidth, token volatility, audit cost, developer acquisition, latency and margin need benchmarked numbers.

Fair compute-weighted representation

Sprint proof count approximates transformer throughput.

Random model + hit-count PoW

Unpredictable parameters block precomputation.

Correlation with production work

The benchmark must predict real throughput across models, context lengths, quantization, batching and hardware classes.

Trustworthy inference with little repetition

Random audits, majority rechecks, escrow and reputation deter fraud.

Probabilistic verification

Repeated cheating raises the chance of losing the entire cycle reward.

Attack-calibrated parameters

Audit selection, output equivalence, slashing amount, false-positive rate and collusion resistance need adversarial testing.

Large-scale decentralized training

DiLoCo, on-chain coordination, proof of learning and sharding are combined.

Low-frequency sync + state commitments

Hosts train locally and expose selected artifacts on demand.

An integrated prototype

The paper does not report a full untrusted multi-Host training run, validation overhead, convergence or poisoning resistance.

Censorship resistance

Compute is distributed among independent Hosts.

No single cloud operator

Open-source models can run across a global network.

Control-plane analysis

Model admission, software releases, governance capture, sanctions, gateway concentration and data availability can still centralize control.

Internal specification check

The stated architecture does not obviously total 2.3 billion parameters.

Appendix B states 64 layers, model width 512, feed-forward width 8192, vocabulary 8192 and about 2.3B parameters. Under a conventional dense Transformer calculation:

Attention per layer4 × 512² = 1.05M
Two-matrix FFN per layer2 × 512 × 8192 = 8.39M
64 layers + token embeddings≈ 608M
With a three-matrix gated FFN≈ 877M
Paper’s stated total≈ 2.3B
Benchmark fidelity

Sequence length 4 mostly measures dense matrix multiplication.

It barely exercises long-context attention, KV-cache traffic, memory capacity, interconnect or serving scheduler behavior. A Host can be excellent at Sprint and mediocre at the workload developers actually buy.

Randomness protocol

The paper names useful primitives, not a finished shared-randomness protocol.

Threshold cryptography and timed commit-reveal address manipulation, but liveness (can the protocol keep making progress when some Hosts disappear?), strategic withholding, bias, membership changes and recovery still need a concrete protocol and adversarial analysis.

Concentration

One-compute-unit-one-vote can still centralize.

If a few operators own most relevant GPUs, they receive most governance weight, jobs, validation duty and emissions. Sybil resistance does not guarantee a broad provider distribution.

14 / Verdict

A strong architecture thesis, not yet a proven protocol.

The paper’s useful insight is sharper than the slogan “make PoW useful.” Sprint itself is synthetic security work. The real innovation is to make that work short, AI-shaped and reusable as the network’s capacity ledger, then spend most GPU time on customer work.

+

Strongest idea

Separate periodic capacity measurement from continuous service. An AI-aligned benchmark can be a cleaner basis for assigning jobs and influence than either passive stake or a generic hash race.

!

Hardest problem

Verify non-deterministic inference and untrusted training cheaply enough that attacks are unprofitable, while honest numerical differences do not trigger loss of rewards or collateral.

≈

Current status

The document is a system design and research program. It is not yet a cost proof, a security proof, a production benchmark or evidence that the integrated network trains frontier-scale models.

The paper should be read as a proposed operating system for a GPU marketplace: the Sprint measures capacity; the resulting Proof of Compute weight allocates voting power, jobs and audit duties; locked pending rewards and spot checks police execution; reputation reduces audit cost; token emission funds the cold start; and DiLoCo-based training is the long-term research layer. The design is coherent at the architectural level. Its viability rests on four unproven bridges: Sprint-to-real-work correlation, robust output verification, anti-concentration economics and an integrated training demonstration.

1
Benchmark correlation studyCompare Sprint weight against real tokens-per-second, training throughput, long-context latency and energy across H100, A100, consumer GPUs and mixed software stacks.
2
Deterministic inference profilePublish exact model, quantization, kernels, sampling rules, tolerances and cross-hardware false-positive rates.
3
Adversarial economic simulationCalibrate audit rates, escrow, collateral, bounties and reputation against model substitution, selective cheating, collusion and rented-Sprint attacks.
4
Cost and utilization ledgerReport useful GPU-hours, Sprint overhead, audit overhead, idle time, network transfer, failure rates and effective customer price without assuming token appreciation.
5
Training prototypeRun a multi-Host DiLoCo experiment with malicious participants, state commitments, validator honeypots and measured convergence and bandwidth.
6
Control-plane threat modelSpecify model admission, upgrades, gateways, key management, privacy, sanctions, governance capture and recovery from a stalled randomness round.
Terminology guide

Every blockchain and paper-specific term used in this tutorial.

Definitions marked “Background” explain standard blockchain or AI vocabulary. Definitions marked “Paper-specific” describe how this white paper uses a term. The paper sometimes uses adjacent labels loosely; those cases are called out rather than silently normalized.

49 terms
Blockchain foundations
Background

Blockchain

A replicated ledger whose accepted history is extended in blocks under shared consensus rules. Cryptographic links and signatures make unauthorized changes detectable.

In this paper: the coordination and settlement layer for compute weights, assignments, commitments, payments and votes. The GPUs perform most AI work off-chain.

Background

Ledger

The ordered record of balances, events and state changes that network nodes agree to maintain.

In this paper: records compute evidence, duties, rewards and governance outcomes.

Background

Block

A batch of new ledger entries plus metadata linking it to prior accepted history.

In this paper: Sprints and randomness are scheduled relative to block intervals, and weighted signatures decide whether a candidate block is accepted.

Background

Consensus

The protocol process by which independent nodes agree on the accepted ledger history and reject conflicting alternatives.

Do not confuse with governance: consensus accepts current blocks; governance changes rules.

Background + paper-specific

Governance

Voting on protocol parameters, upgrades or rules rather than deciding one current transaction or block.

In this paper: votes are weighted by recent Proof of Compute, with most weight activated only after GNK collateral is locked.

Background

Voting weight

How much influence a participant’s signature carries. A weighted majority is measured by total weight, not by counting identities.

In this paper: validated Sprint hits determine the baseline weight.

Background

Honest-majority assumption

Security depends on protocol-following participants controlling more relevant voting weight than coordinated attackers.

Implication: more than 50% of compute-derived weight can confirm blocks and resolve disputed task results.

Background

Sybil attack /ˈsɪbəl/

One actor creates many apparent identities to gain influence in a system that naively counts participants.

Defense: weight is attached to demonstrated compute rather than one node or IP address per vote.

Proof mechanisms and the Sprint
Background

Proof

Compact evidence that a protocol-defined claim is true and can be checked more cheaply than recreating all attempted work.

Scope: a valid Sprint nonce proves a specific successful computation, not future availability or honesty.

Background

Proof of Work (PoW)

A consensus family in which influence is based on demonstrated computational work. Creating a winner is expensive; verifying it is cheap.

Comparison: Bitcoin uses hash guessing continuously; Gonka proposes a periodic Transformer-shaped test.

Background

Proof of Stake (PoS)

A consensus family in which participants lock cryptocurrency and receive validation influence according to protocol rules tied to that stake.

Paper’s criticism: rewards capital holders rather than directly funding AI compute.

Correction

Proof of Action

Not a mechanism defined or used in this white paper, and not needed for this tutorial. Other projects may use the phrase with unrelated meanings.

Use instead: Proof of Work, Proof of Stake, Transformer-based Proof of Work, Sprint and Proof of Compute weight.

Paper-specific

Transformer-based Proof of Work

The paper’s AI-shaped computation test. Hosts repeatedly run a compact Transformer and submit trial numbers whose outputs meet a target condition.

Purpose: measure compute capacity in a form intended to correlate with LLM workloads.

Paper-specific

Sprint

The synchronized, time-bounded event in which all Hosts run the Transformer-based Proof-of-Work test. The paper gives about ten minutes as an illustrative duration.

Output: each Host’s valid-hit count determines its weight until the next Sprint.

Paper-specific

Proof of Compute (PoC) weight

The numerical weight derived from validated computational evidence produced during the Sprint.

Used for: consensus, job allocation, validation duty, rewards and governance. It is the score produced by the proposed PoW mechanism, not a separate unrelated mechanism.

Background + paper-specific

Nonce

An arbitrary number varied from attempt to attempt. It gives each computation trial a different input.

In the Sprint: nonce + Host identity seed + Sprint seed deterministically produce a Transformer input. Winning nonces are submitted as proofs.

Background

Seed

A starting value used by a deterministic pseudorandom process. The same seed and algorithm reproduce the same result.

Sprint Seed: shared and unpredictable; Node Seed: tied to a Host’s public key.

Paper-specific

Target, threshold and difficulty

A trial wins when its final output vector is close enough to a common Target Vector. The distance threshold controls how rarely that happens.

Illustrative setting: approximately one winning vector per 900 attempts.

Paper-specific usage

Epoch / cycle

A bounded operating period. This tutorial uses it for the interval from one Sprint to the next, during which the latest compute weight remains active.

Caution: the document uses “cycle” and “epoch” in overlapping contexts rather than giving one strict global definition.

Participants, verification and penalties
Paper-specific

Host

A provider or operator contributing computational hardware to the network.

Roles: a Host may execute AI tasks, validate another Host’s work, sign blocks and vote in governance.

Background + paper-specific

Node

A computer running the network protocol and maintaining or interacting with the shared state.

Distinction: Host names the operator/provider; node names the participating machine/software.

Role

Executor

A Host while it performs an assigned inference or training task.

Economics: executor rewards can be shared with validators and forfeited after fraud.

Role

Validator

A Host assigned to check another participant’s proof or AI result.

Two contexts: checking Sprint proofs and spot-checking useful AI work. These are distinct tasks even when the same Hosts perform them.

Paper-specific

Randomized verification / spot check

Only a subset of tasks is selected for checking, and executors should not know in advance which tasks will be selected.

Goal: make repeated cheating likely to be caught without replaying every expensive AI task.

Background

Pseudorandom

Generated deterministically from a seed but designed to appear unpredictable before the seed or required secret is known.

Auditability: a Host’s signature and task ID can determine whether it was assigned to validate a task, and others can later recompute that selection.

Background

Escrow

Value that is earned or deposited but temporarily held until specified conditions are satisfied.

In this tutorial: cycle rewards remain pending until execution and validation duties clear. The paper describes reward accumulation rather than a formal third-party escrow contract.

Background + caution

Slashing / forfeiture

A protocol-imposed economic loss for rule violations. In many PoS systems it can include locked stake.

What is actually specified here: loss of pending cycle rewards and reputation reset. Exact collateral/slashing mechanics are deferred to a separate Tokenomics document.

Paper-specific

Reputation

A history-based score that lowers validation frequency for Hosts that remain unflagged over time.

Economic effect: trusted incumbents keep more of their rewards because fewer tasks are checked and split with validators.

Background + paper-specific

Honeypot

An intentionally flawed or controlled item inserted to test whether a checker is diligent.

Training validation: honeypot submissions are proposed to catch lazy or colluding validators.

Cryptography and data placement
Background

Public key, private key and signature

A private key is secret and creates digital signatures. A public key is shared and lets anyone verify those signatures, serving as a cryptographic identity.

In the Sprint: the Host’s public key helps generate its Node Seed; signatures also make validation assignments auditable.

Background

Hash

A fixed-size digital fingerprint of data. Small input changes produce a different fingerprint, and the original data is not practically reconstructed from the hash alone.

Uses: commitments to training state and the comparison to Bitcoin’s leading-zero work puzzle.

Background

Hash commitment

Publish the hash of data now to bind yourself to that exact data, then reveal the full data later so others can check it against the hash.

Training: large weights and optimizer states stay off-chain; their hashes are recorded on-chain.

Background

On-chain

Stored or executed as part of the blockchain’s replicated state and consensus process.

Examples: management records, commitments, validation outcomes and governance votes.

Background

Off-chain

Handled outside the replicated blockchain state, usually because the payload or computation is too large or expensive to copy to every node.

Examples: model computation and underlying training artifacts disclosed on demand.

Background + paper-specific

Commit–reveal

Participants first publish commitments to secret values, then reveal the values later. The commitment prevents changing an input after seeing others’ reveals.

Purpose: contribute to an unpredictable Sprint seed without letting the last participant freely choose after seeing everyone else.

Background + paper-specific

Threshold cryptography

A cryptographic action or secret is split so that at least a required number of participants must cooperate; no one participant can complete it alone.

Purpose: jointly generate or reconstruct randomness for the next Sprint.

Economics and governance
Background + paper-specific

Stake / collateral

Cryptocurrency locked to gain rights, signal commitment or provide assets that can potentially be penalized.

Governance: 20% of compute-derived weight is active by default; GNK collateral unlocks the remaining 80%.

Background

Quorum

The minimum amount of eligible voting weight that must participate before a proposal’s result is valid.

Default: 33.4% of active PoC-weighted power.

Background + paper-specific

Majority and veto thresholds

A majority threshold is the support required to pass. A veto threshold is enough specially designated opposition to force rejection.

Defaults: more than 50% yes, and 33.4% NoWithVeto for forced rejection.

Background + paper-specific

Token emission / block subsidy

New coins created by the protocol and distributed as rewards, separate from fees paid by customers.

Economic implication: early service can be subsidized through dilution; the hardware cost is shifted, not eliminated.

Background + paper-specific

Gas and EIP-1559

Gas is a unit for metered blockchain execution. EIP-1559 is Ethereum’s fee design with a protocol-adjusted base fee and user-specified maximums.

Borrowed idea: developers state a maximum compute price; an exhausted task can consume spent coins without completing.

AI computation and distributed training
AI background

Inference

Running a trained model on new input to produce an output, such as the next tokens in a response.

Primary paid workload: developer requests are routed to Hosts running supported open models.

AI background

Training and fine-tuning

Training adjusts model parameters from data. Fine-tuning continues training an existing model for a narrower task or domain.

Funding: 20% of inference revenue is proposed for future training.

AI background

Transformer forward pass

One evaluation of a Transformer from input through its layers to output, without updating weights.

In the Sprint: each nonce requires a forward pass; faster hardware completes more attempts in the fixed time.

AI background

Quantization and logits

Quantization uses lower-precision numeric formats to reduce memory and compute. Logits are the model’s raw scores before conversion into token probabilities.

Verification problem: hardware and numeric choices can create small differences even for honest execution.

AI background + paper-specific

Sharding and Mixture-of-Experts (MoE)

Sharding divides model parameters or work across machines. MoE models contain many expert subnetworks but activate only selected experts for each input.

Goal: let a Host train only part of a model that is much larger in aggregate.

Referenced method

DiLoCo /daɪˈloʊkoʊ/

Distributed Low-Communication training. Hosts perform many local optimization steps and synchronize models only periodically instead of exchanging updates every step.

Role: reduce bandwidth and waiting across geographically distributed Hosts.

Referenced method

Proof of Learning

Evidence intended to show that claimed model updates resulted from legitimate training rather than fabricated weights.

Mechanism: preserve selected before/after weights and optimizer state, commit hashes, and reveal artifacts for validation.

AI background

KV cache

Stored attention keys and values from earlier tokens, reused during autoregressive generation to avoid recomputing the full history.

Benchmark implication: the Sprint’s sequence length of four barely measures long-context KV-cache memory traffic.

No terminology entries match that search.
Source map

Where each part comes from.

Page references use the 27-page uploaded white paper. The blockchain primer and standard terminology definitions are explanatory background. Paper-specific mechanisms, interpretations and critical statements are labeled and tied to the relevant pages rather than presented as established facts.

Blockchain primerBackground concepts + paper pp. 3–6, 13, 17–18, 24–25 Problem and thesisPages 1–5 Sprint designPages 5–6 and 17–20 Verification and reputationPages 7–10 and 22–23 Inference and trainingPages 10–12 and 24–26 IncentivesPage 12 GovernancePage 13 Consensus comparisonPage 16 Terminology guideDefinitions used throughout this tutorial

Title: Decentralized AI: Meaningful utilization of computational power for real-world application, David Liberman. The paper also refers to the proposed system as Gonka Network and to its coin as GNK. “Proof of Action” is not a term in the uploaded paper.

Definition

Term

Open in full terminology guide →