1/ Beware the hype: while SNARKs and zkVMs show immense promise, they’re not ready for complex, high-stakes deployments. Bugs are everywhere, formal verification is nascent, and proofs can be hundreds of thousands of times slower than native execution.

2/ I’ve just published a post outlining a structured roadmap for zkVM development. It separates “security stages” from “speed stages,” giving us a transparent way to track progress. Read it here:

3/ On security, I identify three stages for formal verification: • Verified protocols • Verified verifiers • Verified provers Until we reach Stage 2, we can’t really call a zkVM “secure”—and getting there is still likely several years off.

4/ On performance, overheads versus native execution still exceed 100,000×—a non-starter for most use cases. My post proposes five “performance stages” to slash that overhead by orders of magnitude and eventually enable on-device proofs.

5/ Crucially, we must isolate a proof system’s fundamental efficiency. Right now, many benchmarks bundle everything—proof system, engineering, hardware boosts, and hand-tuned precompiles—into a single top-line number, obscuring where we really stand.

6/ So yes, zkVMs and SNARKs hold enormous potential, but we flirt with disaster if we pretend they’re ready for prime time. I’ll be using these stages to track zkVM progress in the coming years—and hope others will too. Check out my post here: