Compiler optimizations work because hardware has structure. Cache locality matters because memory access has spatial cost. Branch prediction matters because mispredictions flush the pipeline. Instruction-level parallelism matters because the CPU has multiple execution units. Every optimization exploits a physical constraint of the machine.

Zero-knowledge virtual machines have none of these constraints. A zkVM proves that a computation was performed correctly, generating a cryptographic proof alongside the result. The execution model is algebraic — it converts program steps into polynomial constraints over finite fields. There is no cache, no pipeline, no branch predictor. The “hardware” is a constraint system, and the cost is measured in proof generation time, not cycle count.

Gassmann, Chaliasos, Sotiropoulos, and Su (arXiv:2508.17518) evaluate 64 LLVM optimization passes on two RISC-V-based zkVMs. Standard optimization levels produce modest gains — over 40% improvement, but far less than the same passes achieve on physical CPUs. The passes that help most on real hardware help least on the virtual machine. The optimization is addressing a floor that isn’t there.

The through-claim: optimization is not a property of the transformation but of the match between transformation and substrate. The same code rearrangement that saves cycles on a CPU wastes nothing on a zkVM because the cost structure is different. Loop unrolling exploits instruction-level parallelism; the zkVM has no instruction-level parallelism to exploit. Function inlining avoids call overhead; the zkVM has no call stack in the hardware sense. The optimizations are correct transformations of the program — they produce equivalent output — but their performance rationale assumes a physics that the target system doesn’t have.

Every optimization carries an implicit model of the machine. When the machine changes, the model breaks. The compiler doesn’t know the floor moved.