a16z: How to Achieve a Secure and Efficient zkVM in Phases?
TechFlow Selected TechFlow Selected
a16z: How to Achieve a Secure and Efficient zkVM in Phases?
Must read for developers.
Navigating Web3 tides with focused insightsAuthor: a16z crypto
Translation: Odaily Planet Daily Golem
zkVMs (zero-knowledge virtual machines) promise to "democratize SNARKs," enabling anyone—even those without specialized SNARK expertise—to prove they've correctly executed any program on given inputs (or witnesses). Their core advantage lies in developer experience, but currently they face significant challenges in both security and performance. For the vision of zkVMs to fulfill its promise, designers must overcome these hurdles. In this article, I outline potential stages of zkVM development—achieving them will take several years.
Challenges
From a security standpoint, zkVMs are highly complex software projects still riddled with vulnerabilities. In terms of performance, proving correct program execution can be hundreds of thousands of times slower than native execution, rendering most applications impractical for real-world deployment today.
Despite these real-world challenges, much of the blockchain industry portrays zkVMs as immediately deployable. Indeed, some projects have already paid substantial computational costs to generate proofs of on-chain activity. But because zkVMs remain imperfect, this is merely an expensive way to pretend the system is secured by SNARKs—when in reality it's either protected via permissioning or, worse, vulnerable to attacks.
We are still years away from achieving secure and high-performance zkVMs. This article proposes a phased set of concrete goals to track progress in zkVM development—objectives that could cut through the hype and help the community focus on genuine advancement.
Security Phases
SNARK-based zkVMs typically consist of two main components:
-
Polynomial Interactive Oracle Proofs (PIOP): An interactive proof framework for proving statements about polynomials (or derived constraints).
-
Polynomial Commitment Schemes (PCS): Ensures provers cannot lie undetected about polynomial evaluations.
At their core, zkVMs encode valid execution traces into constraint systems—broadly meaning they enforce that the virtual machine correctly uses registers and memory—and then apply SNARKs to prove these constraints are satisfied.
The only way to ensure such a complex system as a zkVM is free of bugs is formal verification. Below is a breakdown of the security phases. Phase 1 focuses on correct protocol design, while Phases 2 and 3 focus on correct implementation.
Security Phase 1: Correct Protocol
-
Formal verification proof of PIOP soundness;
-
Formal verification proof that PCS is binding under certain cryptographic assumptions or in ideal models;
-
If Fiat-Shamir is used, a formally verified proof that the resulting succinct argument obtained by combining PIOP and PCS is secure in the random oracle model (augmented with additional cryptographic assumptions as needed);
-
Formal verification proof that the constraint system applied by the PIOP is equivalent to the semantics of the VM;
-
A comprehensive, end-to-end "gluing" of all the above components into a single, formally verified secure SNARK proof for running any program specified by VM bytecode. If the protocol aims to achieve zero-knowledge, this property must also be formally verified to ensure no sensitive information about the witness is leaked.
Recursive warning: If the zkVM uses recursion, every PIOP, commitment scheme, and constraint system involved anywhere in the recursion must be verified before this phase can be considered complete.
Security Phase 2: Correct Verifier Implementation
Formally verify that the actual implementation of the zkVM verifier (in Rust, Solidity, etc.) matches the protocol validated in Phase 1. Achieving this ensures the implemented protocol is sound—not just a paper design or an inefficient specification written in Lean.
There are two reasons why Phase 2 focuses only on the verifier implementation (not the prover). First, correct use of the verifier alone is sufficient to guarantee soundness (i.e., ensuring the verifier cannot be convinced that any false statement is true). Second, zkVM verifier implementations are over an order of magnitude simpler than prover implementations.
Security Phase 3: Correct Prover Implementation
The actual implementation of the zkVM prover must correctly generate proofs for the proof system verified in Phases 1 and 2—that is, it must itself be formally verified. This ensures completeness, meaning no system using the zkVM will get "stuck" due to being unable to prove a valid statement. If the prover is intended to achieve zero-knowledge, this property must also be formally verified.
Timeline Expectations
Progress in Phase 1: We can expect incremental achievements next year (e.g., ZKLib). However, no zkVM will fully meet Phase 1 requirements within at least two years.
Phases 2 and 3: These can advance concurrently with parts of Phase 1. For example, some teams have already proven that Plonk verifier implementations match the protocols described in papers (though the protocols themselves may not yet be fully verified). Nonetheless, I expect no zkVM will reach Phase 3 in under four years—and likely longer.
Key Considerations: Fiat-Shamir Security and Verified Bytecode
A major complication is that unresolved research questions surround the security of the Fiat-Shamir transformation. All three phases treat Fiat-Shamir and the random oracle as part of their ironclad security—but in practice, the entire paradigm may have vulnerabilities. This stems from the gap between the overly idealized random oracle and real-world hash functions. In the worst case, systems reaching Phase 2 could later be found completely insecure due to Fiat-Shamir issues. This raises serious concerns and ongoing research. We may need to modify the transformation itself to better guard against such flaws.
Systems without recursion are theoretically more robust, as certain known attacks involve circuits similar to those used in recursive proofs.
Another point worth noting: if the bytecode itself is flawed, then proving that a computer program has been correctly executed (as specified by the bytecode) offers limited value. Thus, the practicality of zkVMs heavily depends on methods for generating formally verified bytecode—a massive challenge beyond the scope of this article.
Post-Quantum Security
For at least the next five years (and likely longer), quantum computers do not pose a serious threat, whereas vulnerabilities represent an existential risk. Therefore, the current priority should be meeting the security and performance phases discussed here. If we can satisfy these security requirements faster using non-quantum-safe SNARKs, we should do so—until post-quantum SNARKs catch up, or until cryptographically relevant quantum computers become a realistic concern.
Current State of zkVM Performance
Currently, the overhead factor introduced by zkVM provers approaches one million times the cost of native execution. If a program requires X cycles to run, the cost of proving correct execution is roughly X multiplied by one million CPU cycles. This was true a year ago—and remains true today.
Popular narratives often describe this overhead in ways that sound acceptable. For example:
-
"Proving everything on Ethereum mainnet would cost less than a million dollars per year."
-
"We can nearly generate real-time proofs of Ethereum blocks using a cluster of dozens of GPUs."
-
"Our latest zkVM is 1000x faster than its predecessor."
While technically accurate, these claims can be misleading without proper context. For instance:
-
Being 1000x faster than an older zkVM doesn't mean absolute speed is good—it says more about how bad things were than how good they now are.
-
Proposals exist to increase Ethereum mainnet’s computational load tenfold, which would make current zkVM performance even less viable.
-
What people call "near real-time proof of Ethereum blocks" is still far too slow for many blockchain applications (e.g., Optimism has a 2-second block time, much faster than Ethereum’s 12 seconds).
-
"Dozens of GPUs running flawlessly forever" does not provide acceptable liveness guarantees.
-
Spending less than a million dollars annually to prove all Ethereum mainnet activity reflects the fact that full Ethereum nodes currently spend only about $25 per year on computation.
For applications outside blockchain, such overhead is clearly too high. No amount of parallelization or engineering can compensate for such massive inefficiency. We should adopt a baseline where zkVM slowdown relative to native execution is no more than 100,000x—even this would only be a first step. Real mainstream adoption may require overhead closer to 10,000x or lower.
How to Measure Performance
SNARK performance has three main components:
-
Intrinsic efficiency of the underlying proof system.
-
Application-specific optimizations (e.g., precompiles).
-
Engineering and hardware acceleration (e.g., GPU, FPGA, or multi-core CPU).
While the latter two are crucial for practical deployment, they generally apply across any proof system and thus don’t necessarily reflect fundamental overhead. For example, adding GPU acceleration and precompiles to a zkEVM can easily yield 50x speedups compared to pure CPU-based, non-precompile approaches—enough to make inherently inefficient systems appear superior to unoptimized ones.
Therefore, the focus below is on SNARK performance without dedicated hardware or precompiles. This differs from current benchmarking practices, which often collapse all three factors into a single "headline number." That’s akin to judging a diamond by its polishing time rather than its inherent clarity. Our goal is to isolate the intrinsic overhead of general-purpose proof systems—helping the community eliminate confounding factors and focus on real progress in proof system design.
Performance Phases
Below are five performance milestones. First, we must reduce prover overhead on CPUs by multiple orders of magnitude. Only then should the focus shift to further reductions via hardware. Memory usage must also improve significantly.
In all stages below, developers must not need to write custom code tailored to the zkVM setup to achieve required performance. Developer experience is the primary advantage of zkVMs. Sacrificing DevEx to meet performance benchmarks defeats the very purpose of zkVMs.
These metrics emphasize prover cost. However, any prover metric could be trivially met if verifier costs were unbounded (i.e., no limits on proof size or verification time). Therefore, for a system to qualify for any stage, maximum values must be specified for proof size and verification time.
Performance Requirements
Phase 1 requirement: “Reasonable and non-trivial verification cost”:
-
Proof size: Must be smaller than the witness size.
-
Verification time: Must not be slower than native program execution (i.e., performing the computation without correctness proofs).
These are minimal succinctness requirements. They ensure proof size and verification time aren’t worse than simply sending the witness to the verifier and letting them check correctness directly.
Requirements for Phase 2 and beyond:
-
Maximum proof size: 256 KB.
-
Maximum verification time: 16 milliseconds.
These thresholds are intentionally generous to accommodate novel fast proving techniques that may incur higher verification costs. At the same time, they exclude prohibitively expensive proofs that few projects would ever include in a blockchain.
Speed Phase 1
Single-threaded proving must be no more than 100,000 times slower than native execution, measured across a range of applications (not just proving Ethereum blocks), without relying on precompiles.
Specifically, imagine a RISC-V processor running on a modern laptop at approximately 3 billion cycles per second. Achieving Phase 1 means you can prove around 30,000 RISC-V cycles per second (single-threaded) on the same laptop. However, verification costs must remain “reasonable and non-trivial” as defined earlier.
Speed Phase 2
Single-threaded proving must be no more than 10,000 times slower than native execution.
Alternatively, since some promising SNARK approaches (especially those based on binary fields) are hindered by current CPUs and GPUs, qualification for Phase 2 can be demonstrated via FPGA (or even ASIC) comparisons:
-
The number of RISC-V cores an FPGA can simulate at native speed;
-
The number of FPGAs required to simulate and prove (nearly) real-time RISC-V execution.
If the latter is at most 10,000 times greater than the former, you qualify for Phase 2. On standard CPUs, proof size must be at most 256 KB and verification time at most 16 ms.
Speed Phase 3
In addition to meeting Speed Phase 2, proof overhead below 1,000x must be achievable using automatically synthesized and formally verified precompiles (applicable to a wide range of applications). Essentially, instruction sets can be dynamically customized per program to accelerate proving, but done in a user-friendly and formally verifiable manner.
Memory Phase 1
Speed Phase 1 must be achieved while the prover uses less than 2 GB of memory (while maintaining zero-knowledge).
This is critical for many mobile devices or browsers, opening countless client-side zkVM use cases. Client-side proofs matter because our phones are our constant link to the physical world—they track location, credentials, and more. If generating proofs requires more than 1–2 GB of RAM, it’s too much for most current mobile devices. Two clarifications:
-
The 2 GB memory limit applies to large statements (those requiring trillions of CPU cycles to execute natively). Proof systems that only meet this bound for small statements lack broad applicability.
-
It’s easy to keep prover memory under 2 GB if the prover is extremely slow. Therefore, to prevent Memory Phase 1 from being trivial, I require it to be satisfied alongside Speed Phase 1.
Memory Phase 2
Speed Phase 1 must be achieved with less than 200 MB of memory usage (10x better than Memory Phase 1).
Why push below 2 GB? Consider a non-blockchain example: Every time you access a website over HTTPS, you download a certificate for authentication and encryption. Instead, the site could send a zk proof of possessing that certificate. Large websites might issue millions of such proofs per second. If each proof requires 2 GB of memory to generate, total RAM needs reach petabyte scale. Further reducing memory usage is essential for non-blockchain deployments.
Precompiles: The Last Mile or a Crutch?
In zkVM design, precompiles refer to specialized SNARKs (or constraint systems) tailored for specific functions, such as Keccak/SHA hashing or elliptic curve group operations for digital signatures. In Ethereum (where much of the heavy lifting involves Merkle hashing and signature checks), some hand-crafted precompiles can reduce prover overhead. But relying on them as crutches won’t get SNARKs where they need to go. Here’s why:
-
Still too slow for most applications (on and off chain): Even with hash and signature precompiles, current zkVMs remain too slow—both inside and outside blockchain environments—because the core proof system is inefficient.
-
Security failures: Handwritten precompiles lacking formal verification are almost certainly riddled with bugs, risking catastrophic security breaches.
-
Poor developer experience: In most current zkVMs, adding new precompiles means manually writing constraint systems for each function—essentially reverting to 1960s-style workflows. Even when using existing precompiles, developers must restructure code to invoke each one. We should optimize for security and developer experience, not sacrifice both for marginal performance gains. Doing so only proves performance hasn’t reached the necessary level.
-
I/O overhead and no RAM: While precompiles improve performance for heavy cryptographic tasks, they may offer little acceleration for more diverse workloads, due to high input/output overhead and inability to use RAM. Even within blockchain contexts, once you move beyond monolithic L1s like Ethereum (e.g., building a series of cross-chain bridges), you encounter different hash functions and signature schemes. Repeatedly hardcoding precompiles for each case doesn’t scale and introduces massive security risks.
For all these reasons, our top priority should be improving the efficiency of the underlying zkVM. The technologies that produce the best zkVMs will also produce the best precompiles. I do believe precompiles will remain crucial long-term—but only if they are automatically synthesized and formally verified. This way, the developer experience advantages of zkVMs can be preserved while avoiding catastrophic security risks. This view is reflected in Speed Phase 3.
Timeline Expectations
I expect a few zkVMs to achieve Speed Phase 1 and Memory Phase 1 later this year. I believe we may also reach Speed Phase 2 within the next two years, though it's unclear whether this is possible without new ideas yet to emerge. I anticipate the remaining phases (Speed Phase 3 and Memory Phase 2) will take several more years to achieve.
Conclusion
While I’ve identified security and performance phases separately in this article, these aspects of zkVMs are not entirely independent. As more vulnerabilities are discovered in zkVMs, some may only be fixable at the cost of significant performance degradation. Until a zkVM reaches Security Phase 2, performance improvements should be secondary.
zkVMs hold great promise for making zero-knowledge proofs truly accessible, but they are still in their infancy—plagued by security challenges and enormous performance overhead. Hype and marketing make it difficult to assess real progress. By outlining clear security and performance milestones, I hope to provide a roadmap that cuts through the noise. We will get there—but it will take time and sustained effort.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
a16z
