Where the Bottlenecks Actually Are When You Try to Prove an AI Model Didn't Cheat

First systematic cost decomposition of zero-knowledge proofs for transformer-scale AI. Six provers, seven kernels, real GPU measurements — not just crypto-primitive speedups.

Imagine you hire a locksmith to rekey your house. You want proof they actually changed all the pins — not just a photo of the finished lock. You could watch the entire job, but that takes your whole day. A zero-knowledge proof is the locksmith showing you a specific test sequence that only works if every pin was changed, without you watching every step. Now scale that to a 13-billion-parameter neural network, and the locksmith's proof takes longer than the actual job. This paper maps exactly where that time goes. The core claim: hardware acceleration papers for verifiable AI keep optimizing individual cryptographic operations (NTT, MSM, hash functions), but those optimizations don't translate predictably to end-to-end proof cost for real transformer workloads because the dominant bottleneck shifts depending on proof system and input length. The authors build a four-layer framework — workload, proof system, cryptographic kernel, hardware — and instrument it with original measurements across six provers and seven kernels. This is a measurement-first paper, not a new algorithm. The most interesting finding is about LoRA fine-tuning proofs. When you prove that low-rank fine-tuning was executed honestly, the cost of opening polynomial commitments to the frozen base-model weights stays roughly constant as input length grows from 64 to 2048 tokens. But the cost associated with intermediate activations scales up. This means the cost profile literally inverts as you move from short to long contexts — a hardware accelerator optimized for one regime may be counterproductive in the other. The 13B-parameter configuration is particularly telling: it overflows a 40 GB GPU but completes on an 80 GB device, which means memory capacity — not compute throughput — is the binding constraint at this scale. Their kernel-level profiling reveals that GPU instruction-issue and synchronization limits dominate in several kernels, not memory bandwidth. This directly contradicts the roofline-model assumptions that most hardware acceleration papers lean on. If you're designing an FPGA or ASIC for ZK proofs and you're modeling performance as bandwidth-bound, you're optimizing the wrong thing for at least some critical kernels. The paper reviews GPUs, FPGAs, custom ASICs, and existing AI accelerators (TPUs, Cerebras) through this lens. The verdict is unsurprising but now empirically grounded: no single hardware platform dominates across all proof systems and workloads. Heterogeneous execution — splitting proof generation across different accelerators based on the kernel mix — is the path forward. The authors also flag proof-friendly numeric formats (avoiding costly field conversions) and reuse of fixed-weight commitments as underexplored optimization surfaces. What makes this useful rather than just taxonomic is the specificity. They don't say 'NTT is expensive' — they show which NTT configurations bottleneck on which GPU resources at which input lengths. They don't say 'MSM needs acceleration' — they show that MSM's cost share changes depending on the proof system (Groth16 vs. Plonk vs. Halo2). The four-layer framework is genuinely clarifying for anyone trying to navigate this space. The limitation is that this is a survey-plus-measurement paper, not a systems result. They don't build a heterogeneous prover or demonstrate a new hardware design. The measurements are on existing GPUs (A100-class), and the 13B parameter experiment is a capacity test, not a full end-to-end proving benchmark. The research agenda they propose — shared benchmarks, proof-friendly formats, heterogeneous scheduling — is sensible but remains entirely prospective.