Mechanism · Cryptographic & computational
Proof-of-learning and training-transcript verification
A trainer logs checkpoints, data order and settings, so a verifier can re-run sampled training segments and check that the claimed training happened.
Also called proof-of-learning; PoL; proof of training transcript; PoTT; proof-of-training-data; PoTD
Summary
Proof-of-learning asks a model trainer to keep a transcript of training: weight checkpoints, the data used at each step and the settings. A verifier re-runs a few segments and checks that they reproduce the logged checkpoints. It was proposed to show that compute was really spent on training, and later to check that training runs obeyed rules on compute and data. The original scheme has public code, and a later defence was tested on language models of up to 1 billion parameters. The biggest known weakness is that published attacks produced invalid proofs that passed verification, and the original authors later argued that no provably robust version exists without a better theory of deep-learning optimisation. Later defences are heuristic. The biggest obstacle for verification use is that the verifier must see the training data and weights and be able to re-run training segments.
R2 through Choi et al.'s peer-reviewed results; the original verification rule is broken, and the later defences are heuristic and have not been attacked independently.
Rubric assessment
- R1 met: Jia et al. define proof-of-learning and its security goal 1, and Shavit sets out training-transcript verification for rules on large training runs 5.
- R2 met through Choi et al., not through the original scheme. The original authors demonstrated spoofs that pass verification across configurations at a fraction of the cost of earlier spoofing strategies 4. An earlier independent attack reported spoofs cheaper than honest training 3, which the original authors dispute 4. These breaks invalidate the original demonstration, including the public code, which implements that rule 2. Choi et al. publish peer-reviewed end-to-end experiments against a stated set of spoofing attacks, training GPT-2 (124M) and testing published Pythia checkpoints up to 1B on GPUs 6. The paper links no code; the rubric does not require code for results described in enough detail to repeat. The open critical flaws concern the original rule, not the evidence the level rests on. No Implementation carries the level.
- R3 not met. As of September 2026 no third party is known to rely on these checks, and no production-grade implementation or independent attack on the post-2023 defences has been published.
- Verification rules with formal robustness arguments, as Fang et al. argue are needed, or an independent red-team of the post-2023 defences.
- Use by a party other than the developer, or a production-grade implementation, at realistic training scale.
How it works
The transcript. Proof-of-learning (PoL) asks a trainer to record a transcript of training 1. It contains:
- weight checkpoints saved every k steps;
- the indices of the data batches used at each step;
- signatures of the training data;
- metadata such as hyperparameters, optimiser and architecture 1.
Checking it. A verifier checks the transcript by re-running training for selected segments. For each epoch, it takes the Q largest weight updates and recomputes the k steps from the earlier checkpoint. It accepts if the result lies within a distance threshold δ of the logged checkpoint 1. The threshold absorbs the numerical noise from hardware and software nondeterminism 1.
Why forging should be costly. The PoL code repository explains that gradient descent "accumulates secret information due to its stochasticity" 2. On this basis, Jia et al. claim a forger must spend "at least as much work than is needed for gradient descent itself" 1.
Use for rule verification. Shavit adapts the idea to verifying rules on large training runs 5:
- Chips log weight snapshots.
- Inspectors sample chips.
- The prover must show a training transcript that explains each logged snapshot.
- The verifier re-runs only the segments concerned 5.
Tests on the training data. Choi et al. add checks aimed at training data 6:
- the random seed, initialisation and data order are derived from a hash of the dataset;
- memorisation tests check that training points are fitted best just after their segment;
- suspicious segments are flagged for retraining 6.
What it establishes
What it can establish.
- If verification holds, the transcript is consistent with training that actually took place. This supports claims about ownership and the compute spent 1.
- With data-focused tests, it also supports claims about "the amount and kind of data and compute used to train the model" 6. This bears on A training run stayed within declared limits.
What it cannot establish.
- A link to derived models. PoL cannot connect a model to a surrogate derived from it by extraction 1.
- Anything without reproducible training. The approach relies on training being approximately reproducible from the hyperparameters, data order and seed 5.
- Online or reinforcement learning. Where the data is not known in advance, these are not covered 6 5.
Threat model
The adversary tries to produce a valid-looking transcript for weights it did not train, or for a run that broke the rules, while spending less than honest training 1 5.
The scheme assumes several things:
- the verifier can re-run training segments on comparable hardware 6;
- honest noise is small compared with genuine updates 1;
- the verifier receives the data and weights, since Jia et al. require that training data "be shared with verifier" 1.
In Shavit's framework, three further assumptions tie transcripts to real chips 5:
- the chips support firmware attestation and logging;
- they have tamper-evident packaging;
- a trusted chip-owner directory exists.
Evidence
- Jia et al. They evaluate PoL with ResNet-20 and ResNet-50 on CIFAR-10 and CIFAR-100 1. Their code for creating and verifying proofs is public 2.
- Choi et al. They train GPT-2 (124M) on about 8.8 billion OpenWebText tokens, and apply their tests to EleutherAI's published Pythia checkpoints of 70M, 410M and 1B parameters, using four A40 GPUs 6. They show detection of attacks from the PoL literature, including gluing, interpolation and data addition or subtraction 6. Sampling 1% of the points in each segment, they estimate that their new memorisation and data-order tests cost "just 1.3% of the original cost of training", in addition to retraining selected segments 6.
- Shavit. His framework is a proposal, with estimates of how many chips inspectors would need to sample 5.
Limitations
Independent attack. Zhang et al. of Zhejiang University showed that adversarial-example-style perturbations let an attacker generate a passing proof "with significantly less cost" than honest training 3. Fang et al. dispute this. They state that the attack assumes the adversary chooses the checkpoint interval, which the verifier should set, and that a small interval prevents it 4.
Attack by the original authors. Fang et al., whose authors include all seven original PoL authors, present cheaper spoofs that work across PoL configurations. They find that "current PoL verification is not robust to adversaries", and show that the assumptions needed for robust verification reduce to open problems in learning theory 4.
Gaps in later defences. Choi et al. defend against several known attacks, but note that small-scale data changes and masked hyperparameters remain open 6.
Cost. Storage is a burden: checkpoints may each take terabytes 5. Shavit identifies cheaper alternatives to retraining-based verification as future work 5.
Alternatives. Zhang et al. suggest proofs built on verifiable computation as a countermeasure 3. Zero-knowledge proofs of training take that route, proving each training step cryptographically 7.
Known flaws
Published flaws, with their severity, kind and status. How flaws are rated.
Adversarial-example spoofs pass verification at lower cost than training
Zhang et al. construct proofs that pass the original verification "with significantly less cost than generating a proof by the prover". Their attack uses adversarial-example-style perturbations, and they demonstrate it on CIFAR-10, CIFAR-100 and an ImageNet subset 3. They suggest dynamic thresholds, or proofs built on verifiable computation, as countermeasures 3.
Response.Fang et al., who include the original PoL authors, state that the attack assumes the adversary sets the checkpoint interval k, which the verifier should set, and that the verifier can prevent it by using a small k 4.
Structurally correct spoofs exploit tolerance thresholds and sampled checks
Fang et al., including the original proposers, present spoofing strategies that work across PoL configurations at "a fraction of the cost of previous spoofing strategies" 4. The strategies exploit the tolerance that verification must allow for hardware noise, and the choice of which updates the verifier re-runs 4.
Rule-compliance transcripts face a stronger adversary
Shavit argues that proving a training transcript "appears to be strictly harder than PoL". The adversary knows the true transcript and may spend extra compute to build a compliant-looking one 5.
Small data changes and masked hyperparameters may go undetected
Choi et al. state that their protocol cannot yet detect modest data additions, such as inserted backdoors. They note that attacks could be hidden with "cleverly chosen hyperparameters", such as a temporarily lower learning rate than reported, and that the protocol does not apply to online or reinforcement learning 6.
Blockers
Transcripts are large: weight checkpoints may each require terabytes 5.
The verifier must reproduce training segments, which may be infeasible if the prover uses specialised or proprietary hardware 6.
The noise tolerance needed for honest reproduction is what structurally correct spoofs exploit 4.
Tying transcripts to real chips needs on-chip weight-snapshot logging, chip inspections and a trusted chip-owner directory 5.
Sources
- AH. Jia et al. (2021). Proof-of-Learning: Definitions and Practice. 42nd IEEE Symposium on Security and Privacy. Source recordSupports: PoL definition, transcript contents, verification, security analysis, limits · Definition 1; Algorithm 2; §IV–VI; Table I
- BCleverHans Lab (2021). Proof-of-Learning: code for Proof-of-Learning: Definitions and Practice. GitHub. Source recordSupports: public PoL implementation (train and verify scripts); rationale for the cost of forging · README
- AR. Zhang et al. (2022). "Adversarial Examples" for Proof-of-Learning. 2022 IEEE Symposium on Security and Privacy (SP). Source recordSupports: independent demonstrated spoofing attack; countermeasures · abstract; §III–V
- AC. Fang et al. (2023). Proof-of-Learning is Currently More Broken Than You Think. 8th IEEE European Symposium on Security and Privacy (EuroS&P 2023). Source recordSupports: structurally correct and stochastic spoofing; robustness conclusion; response to Zhang et al. · abstract; §2.3; attack sections; conclusion
- BY. Shavit (2023). What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring. arXiv. Source recordSupports: training-transcript verification for rules; chip logging; open problems; costs · §4; §5; §5.1; §5.2; §6.1; Table 1
- AD. Choi et al. (2023). Tools for Verifying Neural Models' Training Data. Advances in Neural Information Processing Systems 36 (NeurIPS 2023). Source recordSupports: proof-of-training-data protocol, experiments, defended attacks, costs, limits · §3; §4.1–4.4; §6; §7; App. A
- AS. Waiwitlikhit et al. (2024). Trustless Audits without Revealing Data or Models. 41st International Conference on Machine Learning (ICML 2024). Source recordSupports: cryptographic alternative (ZK proofs of SGD) · abstract