Ethereum’s zkVM Scoreboard Measures Compatibility Before It Measures Speed

Ethereum’s zkEVM roadmap is moving toward a world in which validators verify execution proofs instead of re-executing every block. A newly maintained public tracker shows what that transition looks like at the engineering level: before a zkVM can be compared on proving speed, it must demonstrate that its machine behaves like the execution target it claims to implement.

The tracker, synchronized on September 15, records ISA-compliance results for several RISC-V-based zkVMs. Its current table shows LambdaVM and OpenVM at 72 of 72 listed tests, ZisK at 71 of 72, and Jolt at 62 of 72. The figures are useful precisely because they are narrower than a marketing benchmark: they test compatibility with a defined instruction-set surface.

That distinction matters for developers building around proofs. A fast prover that disagrees with the reference machine on an instruction, edge case, or data representation cannot safely serve as a drop-in execution backend. Compatibility testing therefore becomes a prerequisite for interoperability, reproducible benchmarking, and eventually client diversity.

The tracker also makes clear that ISA compliance is only one gate. Its inclusion criteria call for permissively licensed components, a 64-bit RISC-V target, the ability to prove a complete Ethereum block within slot time, and integration with Soundcalc for standardized verification and interoperability testing. In other words, “supports RISC-V” is becoming a starting point, not the definition of an Ethereum-ready zkVM.

This is the important shift for ICP and other developers consuming ZK infrastructure: the relevant artifact is no longer just a proof-generation number. It is a pinned implementation, a reproducible test result, a verifier-compatible proof path, and evidence that the system can meet the timing and interoperability assumptions of its destination chain.

Ethereum’s Protocol priorities reinforce that direction. The Foundation describes the zkEVM work as a progression from optional proofs to expected and then mandatory proofs, while noting that the ordering of mandatory proofs and post-quantum attestations is still under review. That means the tracker should be read as a moving engineering contract, not a final certification regime.

A factual limitation is important: the tracker is not a production-readiness certification, its criteria may change, and the listed test runs were performed on different dates even though the page was synchronized on September 15. Builders should pin the underlying commits and rerun the tests before using the table as a release decision.

The practical lesson is simple. In a proving ecosystem, execution compatibility is the first form of portability. Speed matters only after the machine being proved is the machine everyone agrees to verify.