Miners should optimise. Better kernels, tighter scheduling and better use of every watt are exactly what competition is supposed to produce. But consensus still has to distinguish faster honest work from a cheaper computation passed off as something it was not.
That line was tested on mainnet. A miner ran the committed model at fp8 on a
smaller GPU, then submitted two proofs declaring the reference precision,
bfloat16. Both blocks reached the network. Neither earned any work.
A precision lie, dressed up to pass
The forgery took real work. The attacker modified the miner’s source code to report a precision it wasn’t running, and had to make sure the fp8 values snapped onto the bf16 grid so the numbers would pass as genuine bf16. But that only settles the storage format — not the precision of the computation that produced them.
The proof was internally consistent too. At each of its 256 generation steps, the
verifier re-derived the mandated random draw u from the committed inputs and
replayed it against the miner’s submitted support. It reproduced the claimed token
256 out of 256 times for the honest control and both fp8 proofs.
That proves the token follows the submitted support. It does not prove that the support came from a bf16 forward pass.
The catch: independently recompute the model
Full verification does the decisive thing: it runs the committed model again at bf16 and compares the fresh logits with the submitted evidence.
The calibrated Mahalanobis test produces a p-value at each step. Under its honest null those p-values should be roughly uniform. For the two fp8 proofs they instead piled up at zero:
| Proof | Steps with p < 0.05 | Steps with p < 0.001 |
|---|---|---|
| Block 1 | 173 / 256 | 155 / 256 |
| Block 2 | 105 / 256 | 87 / 256 |
The recomputation also exposed large changes in the submitted top-50 support order.
This rank_error is the aggregate displacement of those 50 submitted tokens in the
bf16 ranking — not the chosen token’s vocabulary rank. The two proofs had median
displacements of 602 and 557, with worst-step values of 110,888 and 15,726.
Those figures are corroborating forensics; the calibrated p-value collapse is the
production detection result.
Both blocks were marked RED and assigned zero work. They appear as orphans, but this was not a propagation race: the chain never extended them.
The smarter attack: search in fp8, then refine in bf16
The attack that happened was direct precision substitution. A smarter version would try to neutralise the statistical comparison:
- Search cheaply in fp8 and find a desirable candidate trajectory.
- Recompute genuine bf16 support and logits only for that candidate.
- Submit the genuine bf16 values, which now pass recompute-and-compare.
This is where the sampling path matters. Each u is derived from the running context.
The fp8 search consumed those draws while following the fp8 support. Replace that
support with genuine bf16 evidence and the same draw can select a different token.
In a counterfactual replay, after replacing the fp8 support and logits with recomputed bf16 evidence, the recorded draws selected a different token at 62 and 69 of 256 steps. These are changed-token counts from the counterfactual, not production verdicts or an honest-versus-fp8 failure rate.
Only one change is needed. A different token changes the next context; that changes
the next context-derived u; the rest of the trajectory changes with it. The
candidate found by the cheap fp8 search is gone.
Refinement repairs the submitted values but invalidates the trajectory the attacker searched for. To recover a valid candidate, the miner has to sample and search again under bf16, eliminating the shortcut.
Trust in action
The first attack failed because the independently recomputed values disagreed. Its obvious refinement fails because the values and the sampled trajectory must describe the same computation.
That is what trust in action means here: not trust us, but a proof anyone can recompute. Optimise everything around the work. The work itself still has to be real.
Run your own verifier. Don’t trust the proof. Check it.
Authored pseudonymously by Imosuke Takakuni.