← All posts
9 min read

We were attesting a constant: making 'provable improvement' actually provable

QBC's pitch is that the model's improvement is provable on-chain. We found a place where it was not: every training epoch's attestation signed a hardcoded loss constant, not the real measured value. The gap, the fix now live, and the parts we deliberately did not fake.

The whole point of training an AI on a blockchain is that "the model is getting better" stops being a marketing line and becomes a claim you can check. Every training epoch on QBC produces a content-addressed weight root, gets attested by a validator quorum, and is finalised on-chain with the same guarantees as a token transfer. The public training-series feed charts the finalised held-out loss so anyone can watch the curve come down.

While building the next thing, we audited that path end to end and found a hole in it. This post is about the hole, the fix that is now live, and the two parts we could have quietly hand-waved and instead wrote down.

The gap: a signed constant

Here is what the attestation quorum was actually doing. When a new training epoch landed, a daemon submitted the epoch's attestation with each of the validator signers. The value it signed for the epoch's held-out loss was this:

CE_E6 = 800_000   # a hardcoded 0.8, attested for every epoch

Every epoch. The same number. The daemon even fetched the payload that carried the epoch's real measured loss, and then ignored it and signed the constant.

Think about what that means for the public curve. The finalised held-out loss is supposed to be the evidence that the model improved. If the attested value is a fixed 0.8 regardless of what the model actually scored, then the attestation is proving that four keys signed the number 0.8, not that the model reached it. The quorum was real, the finality was real, the on-chain record was real, and the number inside it was a placeholder. That is exactly the kind of "trust me" step this project exists to remove, and we would rather find it ourselves and say so than have someone else find it.

To be precise about the blast radius, because honesty about a gap includes its size: the producer's real measured loss was already being recorded on-chain separately, by the payload-submission path. So the truthful value existed on the ledger. It was specifically the per-signer attestation that carried the constant. The fix is to make those two agree.

The fix, now live: attest the real measured value

Each signer now attests the real per-epoch held-out loss that the training loop actually measured and already committed on-chain, instead of the constant. The constant is deleted. If, for some reason, no real measured value is available for an epoch, the daemon now skips that epoch rather than attest a made-up number. Signing a fiction is no longer a code path that exists.

The effect is immediate and visible: the attested value now tracks the true, varying per-epoch loss. We verified it in production the moment it shipped. A live epoch attested at a held-out loss of 1.77, the real value for that root, and there have been zero attestations at the old 0.8 constant since the change went in. The public series is now anchored to measured reality rather than a fixed number.

That is the headline, and it is live as of today.

Going further: independent re-derivation

Attesting the producer's real measured value is a large honesty improvement, but there is a stronger property worth reaching for: an attester should not have to trust even the producer's self-report. It should be able to take the committed checkpoint, re-run the measurement itself, and sign what it independently computed. Re-derive, do not rubber-stamp.

So we built the machinery for that too. There is now a token-gated endpoint that, given a committed weight root, loads the exact checkpoint blob the network is serving for that root, confirms the blob hashes to the claimed root, and re-runs the held-out evaluation from scratch. It returns the re-measured loss and whether the hash matched. A checkpoint that does not hash to its claimed root is rejected outright, so a misreported checkpoint cannot pass.

Making that safe to run took a specific piece of engineering worth calling out, because it is the kind of thing that is easy to get wrong. Re-deriving a root's loss means loading that checkpoint's weights into a model and running a forward pass. Done naively on the machine that serves live chat, that would swap the served model's weights out from under it. So the re-derivation is now non-destructive: it snapshots the live weights, loads the candidate checkpoint, measures, and restores the originals, with the restore guaranteed to run even if the measurement fails. The model that answers your questions is never left holding a checkpoint it was only supposed to inspect. We confirmed live chat kept working, unbroken, throughout.

Building this also surfaced a latent bug that had quietly broken every real re-derivation attempt before now. The checkpoint writer emits a 40-byte header, but the reader assumed 32, an eight-byte disagreement that made every genuine checkpoint fail to load. It had gone unnoticed precisely because nothing had ever re-loaded a real committed checkpoint end to end. It is fixed, and the reader and writer now agree by construction.

What we did not fake

Here is the part that matters most for a project whose entire thesis is honesty. The independent re-derivation endpoint is built and running, but we did not wire it in as the signed value yet, and there are two concrete reasons we wrote down rather than glossed over.

First, a metric mismatch. The endpoint currently re-derives a language-model cross-entropy, while the value the training loop optimises and reports for these epochs is a contrastive retrieval loss (InfoNCE) over the retrieval projection. Those are different numbers measuring different things. Signing the cross-entropy where the series expects the InfoNCE would put the wrong quantity on-chain, which would be a new dishonesty in place of the old one. Reconciling the two so the re-derived number is the same quantity the series reports is follow-up work, and until it is done, the independent re-derivation runs as a shadow probe that logs, never as the signed value.

Second, a hardware reality. Re-deriving an epoch holds the model for the length of a full held-out forward pass, on the order of forty seconds on the current single GPU host. Doing that on the box that also serves chat, for every epoch, would stall the product. Genuine independent re-derivation belongs on a dedicated verifier node so it never competes with serving. That is the same multi-machine gate that everything else on the scale-out roadmap waits behind, and we grade it the same way: built infrastructure, not yet the live path.

Where this leaves the grade

On the public roadmap, this item moved from designed to built, with the evidence attached. The honest one-paragraph version: attesters no longer sign a constant, they sign the real measured loss, and that is live and dated. Independent re-derivation of the committed checkpoint is built and hash-verified, running as a probe, with two named steps (metric reconciliation and a dedicated verifier node) before it becomes the signed value at scale.

The reason to publish this rather than just ship it quietly is the same reason the network exists. An improvement curve you are asked to trust is worth exactly as much as the company showing it to you. An improvement curve whose every point is a real measured value, signed by a bonded quorum and finalised on a post-quantum ledger, is worth checking, and now it is one honest step closer to being fully that. The gap was ours to find, the fix is ours to show, and the remaining scope is ours to name out loud.

ShareXLinkedIn

Written by

A
Ash Brown@blockartica
Founder, SusyLabs / QuantumAI Blockchain

Building the post-quantum AI-native L1 with permissionless on-chain training cycles. Writes about consensus, attestation, and the gap between what ships and what's claimed.

Related posts