Mechanism · Proofs of useful work for capacity accounting
Evidence & limits
On this page
R1Proposed for bounding the spare capacity of declared hardware that could run training
The scheme is proposed, and the only implementation proves work for blockchain consensus, not that hardware has no spare capacity.
Assessed use: bounding the spare capacity of declared hardware that could run training
Rubric assessment
- R1 met: Attestable describes such a scheme, with its claim and a key assumption, namely a credible estimate of the actor's compute 6. Scher and Thiergart list proof of work, for compute declared to be doing crypto mining, among the ways to verify that known compute is not used for a large training run 8. The underlying proof-of-useful-work construction is publicly specified with its hardness assumptions 1.
- R2 not met for this use. The most mature implementation, Pearl, is assessed R3 only for the narrower claim that GPUs performed matrix-multiplication work. It is built for blockchain consensus, and no public implementation or result uses proofs of useful work to bound the spare capacity of declared hardware 2 4.
- A public implementation or reproducible end-to-end result that uses proofs of work to bound the spare capacity of declared hardware against a stated adversary.
- A method for the verifier to obtain a credible estimate of the prover's available compute.
Assessed 2026-09-25 against rubric v1.1.
Evidence
- Theory. Komargodski and Weinstein prove a multiplicative overhead of 1 + o(1) over naive matrix multiplication 1.
- Pearl. Pearl publishes the code of a network built on this construction 4, and reports that the chain went live when the node code became public 3. It also reports a benchmark on four H200 GPUs. Its "two-for-one" variant of Llama 3.3 70B, which re-implements a layer with a new quantisation mechanism, reached up to 18,291.66 tokens per second. The original model's best configuration reached 15,269.81 tokens per second; with the four-way data parallelism that gave the variant its best figure, the original bf16 model ran out of memory 3.
- Independent measurement of Pearl. Basu studied Pearl's mainnet in May 2026. String analysis suggests that the dominant mining software, from a third party, contains no inference code and generates matrices from random seeds. Random matrices passed verification in the study's tests 5.
- Capacity bounding. As of September 2026 no public result applies proofs of useful work to bounding the capacity of declared AI hardware. Attestable describes its proposal as near-term work 6.
Limitations
Verification cost. Komargodski and Weinstein note that plain verification is "relatively expensive on the verifier's side". They suggest that the prover compute a SNARK to lighten it, or a zkSNARK if the matrices must stay private 1. They also note that storing the transcript takes significant memory 1.
Known shortcuts. Pearl lists known mining speedups: crafted inputs, precision shortcuts, seed grinding and work reuse. It adds checks to limit them 2. It describes faster kernels or hardware as "not an attack on the protocol" 2.
Assumptions and scope. Open problems include PoUW from more standard assumptions, and PoUW for tasks beyond matrix multiplication 1.
Known flaws
Blockers
Bounding spare capacity needs a credible estimate of the compute available to the actor, including third-party access 6.
Proofs of work cannot find facilities that were never declared 6.
As of September 2026 no implementation, demonstration or independent evaluation of proofs of work for capacity bounding has been published.