Zero-Knowledge Virtual Machines (zkVMs)
- Zero-Knowledge Virtual Machines (zkVMs) are platforms that execute arbitrary programs and generate succinct proofs of correct execution while preserving zero knowledge.
- They abstract complex circuit design by compiling high-level languages into bytecode mapped onto an instruction set, effectively bridging cryptographic theory and practical software development.
- Researchers address performance challenges such as trace generation overhead and cryptographic constraints using specialized compilers, hardware accelerators, and optimized execution pipelines.
to=arxiv_search 天天中彩票谁 json {"query":"zero-knowledge virtual machines zkVM survey trace generation accelerator compiler optimization soundness completeness arXiv", "max_results": 10} Zero-knowledge virtual machines (zkVMs) are virtual machines designed to execute arbitrary programs and generate efficiently verifiable proofs of that execution while preserving zero knowledge over private inputs and, in the survey framing, private program data. They function as a “programmable ZK circuit”: a developer supplies public and private inputs, the zkVM executes the program, and the system outputs a certificate that the execution was valid. Within the broader zero-knowledge stack, zkVMs occupy an infrastructure role distinct from proof systems, domain-specific languages, libraries, frameworks, and protocols: zk-SNARKs and zk-STARKs provide the proving machinery, whereas zkVMs make general-purpose computation provable without requiring application authors to handcraft arithmetic circuits (Lavin et al., 2024).
1. Position in the zero-knowledge software stack
A central motivation for zkVMs is programmability. Before their emergence, developers typically needed substantial cryptographic expertise, had to translate programs into circuits manually, and then had to integrate those circuits with backend proving systems. zkVMs reduce this burden by abstracting circuit construction and backend plumbing, allowing programs to be written in conventional environments such as Rust or C++, then compiled into artifacts whose execution can be proved. The surveyed literature therefore presents zkVMs as a practical bridge between zero-knowledge theory and deployable software (Lavin et al., 2024).
This infrastructure role explains why zkVMs recur across disparate application domains. In blockchain scaling, zkVM-like systems underpin ZK rollups and related off-chain execution pipelines; the survey ties these abstractions to Ethereum scaling systems including zkSync Era, Polygon zkEVM, Scroll, Linea, StarkNet, and StarkEx. In privacy-oriented applications, zkVM-adjacent tooling supports private smart contracts; Mina’s zkApps are cited as a case where the contract runs locally in the browser, generates a proof, and submits the proof and state updates on-chain. In storage and interoperability, the same execution-and-proof model appears in systems such as Herodotus, Filecoin, zkBridge, and Telepathy. The survey also places zkVMs in non-blockchain settings including machine learning verification, identity proofs, voting, timelocks, image authentication, and collaborative computation (Lavin et al., 2024).
The same literature also emphasizes that zkVMs do not eliminate the underlying difficulty of proving computation. They improve developer experience and generality, but they inherit the costs of field arithmetic, memory consistency, and bit-level logic. This is why the modern zkVM literature treats them not as a complete substitute for lower-level proof engineering, but as a general-purpose execution layer whose practicality depends on compilation, runtime design, and systems optimization (Lavin et al., 2024).
2. Execution semantics and proof generation
The standard zkVM workflow is a frontend/backend pipeline. A program written in a high-level language is compiled to bytecode and mapped onto an instruction set architecture (ISA), either a general ISA such as RISC-V or a specialized ISA such as Miden Assembly. The VM executes that bytecode while producing an execution trace. A proving system then constrains the trace so that each step is checked against the ISA semantics, commits to polynomial representations of the trace, and allows a verifier to check consistency through a polynomial commitment scheme without re-executing the entire program (Lavin et al., 2024).
The survey situates this workflow within the familiar SNARK formalism. It writes the core R1CS relation as
where is the witness vector and denotes the Hadamard product. It then describes the QAP transformation
which is the algebraic condition later checked via commitments and openings. In zkVM terms, the witness is the execution transcript: register values, intermediate states, memory events, and other machine-level data that certify correct execution (Lavin et al., 2024).
This execution model requires zkVMs to maintain virtualized machine components—memory management, instruction scheduling, registers, CPU state, and error handling—in a ZK-friendly form. The literature repeatedly stresses that these components cannot be carried over from conventional hardware without adaptation. Range checks, bitwise operations, and hashing are especially expensive because finite-field arithmetic does not align naturally with standard CPU semantics. Consequently, many zkVM designs either adopt ZK-friendly hashes such as Poseidon or Rescue or push hashing into specialized hardware or precompiled circuits (Lavin et al., 2024).
A more recent systems perspective further decomposes the proving pipeline. In SP1, for example, the prover workflow has two major phases: frontend execution and trace generation, followed by backend proof generation over that trace. Modern multi-table zkVMs such as RISC0 and SP1 divide the trace into a Main Trace, recording machine state over time, and a Permutation Trace, supporting cross-table consistency and lookup arguments. This decomposition is important because it makes explicit that “execution” and “proving” are not a single monolithic cost center; trace generation is itself a substantial systems problem (Cui et al., 25 May 2026).
3. Machine models, compatibility boundaries, and neighboring designs
The zkVM literature spans multiple machine models. RISC Zero is described as a general-purpose zkVM that emulates a RISC-V microprocessor and can prove Rust and C++ programs. CairoVM is presented as a STARK-based VM with a dedicated compiler path—Cairo source to bytecode via the Cairo assembler, then to an execution trace via Cairo Runner, and finally to a proof via a STARK prover. Miden is described as a rollup-oriented VM using a MAST program structure, stack-machine execution, and a standard library that serializes calls into fixed-size encodings to reduce prover and verifier overhead. The survey’s timeline places these systems within a longer evolution from TinyRAM and Hawk to RISC Zero, CairoVM, Aleo, Miden, Triton, Jolt, SP1, Nexus, and Valida (Lavin et al., 2024).
A specialized, compatibility-driven subdomain is the zkEVM. The zkEVM survey places zkEVMs in the broader zkVM design space but distinguishes them sharply from general zkVMs: a zkEVM does not merely prove generic computation, but attempts to prove faithful execution of Ethereum’s sequential, stack-based, 256-bit, gas-metered semantics. General zkVMs such as Cairo, Miden, and RISC Zero deliberately redefine the machine model so that execution is easier to arithmetize; zkEVMs instead retain Ethereum compatibility and therefore incur a different constraint-engineering burden. The survey organizes this space through a Type 1–4 spectrum, where Type 1 aims at Ethereum-equivalence and Type 4 preserves only source-level compatibility. Its core trade-off is that higher compatibility implies higher proving cost (Hassanzadeh-Nazarabadi et al., 6 Oct 2025).
The neighboring literature also clarifies what should not be classified as a general-purpose zkVM. Jolt Atlas is explicit on this point: it is a zkML framework built on zkVM ideas, but not itself a general-purpose zkVM. Standard zkVMs emulate CPU instruction execution, including registers, program counter evolution, and general-purpose memory semantics. Jolt Atlas instead verifies ONNX tensor computations directly, eliminating CPU registers and simplifying memory consistency because ONNX graphs expose deterministic tensor dataflow. This distinction matters because it shows that “VM-inspired” proof systems can inherit techniques such as lookup arguments and sumcheck while abandoning ISA-level execution as the fundamental witness structure (Benno et al., 19 Feb 2026).
4. Performance bottlenecks and acceleration
The dominant performance costs of zkVMs are no longer adequately described by backend proving alone. The survey already identifies expensive primitives—range checks, bitwise logic, hashing, and setup overheads—but later work shows that frontend execution and trace generation are becoming system bottlenecks as backend accelerators improve (Lavin et al., 2024). Profiling on SP1 reports that frontend execution and trace generation already consume about – of total proving time in a software-only system. The same work estimates an average backend acceleration of about in existing accelerators; even under a conservative backend speedup, frontend overhead can exceed , and with more aggressive backend acceleration it can dominate total runtime, exceeding in the projected breakdown (Cui et al., 25 May 2026).
The underlying cause is structural. In modern multi-table zkVMs, permutation-trace generation performs modular arithmetic over traces with many rows 0 and relatively few columns 1, a “narrow and long” shape with poor locality. CPU software pipelines often interpret execution, write main-trace rows to DRAM, read them back, compute permutation and accumulator columns, and write the results back again. This write-read-write pattern produces cache thrashing and substantial memory traffic, while operations such as modular inversion and accumulator updates expose long dependency chains with limited instruction-level and data-level parallelism (Cui et al., 25 May 2026).
ZK-Tracer addresses this phase directly with a heterogeneous accelerator specialized for zkVM frontend trace generation. Its Main Trace Unit executes the guest zkVM program and generates the Main Trace, while parallel Permutation Trace Units compute the Permutation Trace. The architecture is tightly coupled to a host CPU, shares unified physical memory, and uses lightweight trace_on and trace_off instructions to restrict tracing to the region of interest. In ASIC implementation, it reports up to 2 speedup in trace generation over a high-performance multi-core CPU, and up to 3 end-to-end improvement when combined with an existing backend proving accelerator (Cui et al., 25 May 2026).
Compiler behavior is another major performance variable. A systematic LLVM study evaluates 64 optimization passes, six standard optimization levels, and an unoptimized baseline across 58 benchmarks on RISC Zero and SP1. Standard optimization levels improve zkVM execution time by 60.5% on RISC Zero and 47.3% on SP1, and proving time by 55.5% and 51.1%, respectively, but the gains are still markedly smaller than on conventional CPUs because the optimizer’s heuristics target hardware features—cache locality, branch prediction, out-of-order execution, superscalar pipelines, and instruction-level parallelism—that zkVMs largely lack. The same study identifies inlining as the strongest single pass and licm as the most harmful across both zkVMs, and shows that modest zkVM-aware modifications to LLVM’s cost model and pass heuristics can improve zkVM execution time by up to 45% (Gassmann et al., 24 Aug 2025).
5. Software stacks, deployment frameworks, and systems infrastructure
Several recent systems papers shift attention from isolated proof generation to full software stacks. The vApps framework presents zkVMs as the computational engine of verifiable applications built from a unified Rust-based DSL and SDK. Its execution model organizes application lifecycle into steps S0–S4—pre-processing, verifiable state read, state transition, verifiable state write, and post-processing—and compiles Rust application code into a runtime binary plus a constraint system. The framework argues that native Rust execution on a zkVM avoids the interpretation overhead of EVM-oriented designs; its abstract reports up to an 197x cycle count improvement compared to EVM-based approaches, while the detailed benchmark shows much larger Revm overheads on Fibonacci workloads. It further reports that precompiled circuits can accelerate proof generation by more than 95%, GPU acceleration can increase throughput by up to 30x, and recursion can compress proof size by up to 230x (Zhang et al., 21 Apr 2025).
Compatibility with modern software requires more than ISA support. ZeroOS argues that many zkVM programs cannot run, and sometimes cannot even compile, without an operating system and libc. Its response is a modular library OS for zkVM guest unikernels that targets the Linux ABI at the syscall layer rather than through language-specific runtime forks. Developers use off-the-shelf toolchains, statically link only the required subset of functionality, and zkVM platforms integrate by implementing a platform-specific __platform_bootstrap. The stated goal is to reduce “version hell,” shrink the trusted computing base, and preserve a pay-for-what-you-use relationship between guest functionality and trace size (Zou et al., 10 Dec 2025).
At workflow scale, zkVMs are increasingly embedded in larger verifiable-computation frameworks rather than used as standalone proving engines. Trusted Compute Units treat zkVMs and TEEs as interchangeable realizations of a Verifiable Computation Component inside a uniform service abstraction. In the zkVM realization, the program is compiled and registered, executed on external and internal inputs, and produces a Receipt containing outputs, an imageID, and a seal; the registry then binds proofs to code identity and on-chain provenance (Castillo et al., 22 Apr 2025). For proof production itself, push0 frames zkVM proving as an orchestration problem. It uses a dispatcher–collector architecture over persistent priority queues, enforces strict block-sequential ordering, supports heterogeneous zkVMs and proof systems, and reports 5 ms median orchestration overhead with 99–100% scaling efficiency at 32 dispatchers for realistic workloads—overhead described as less than 0.1% relative to typical proof times of 7+ seconds (Ahmadvand et al., 18 Feb 2026).
These software-stack papers collectively suggest that mature zkVM deployments depend on more than prover arithmetic. Toolchains, operating-system interfaces, scheduling, proof transport, and application frameworks increasingly determine whether general-purpose verifiable computation is operationally tractable.
6. Correctness, trust assumptions, and active research fronts
Because zkVMs combine compilers, runtimes, execution engines, constraint systems, and verifiers, correctness failures can appear as either soundness bugs or completeness bugs. Arguzz defines a soundness bug as acceptance of an invalid execution and a completeness bug as rejection of a valid execution, then tests six real-world RISC-V-based zkVMs—RISC Zero, Nexus, Jolt, SP1, OpenVM, and Pico—using metamorphic testing plus fault injection. It reports 11 previously unknown bugs in three systems, comprising 3 soundness bugs and 8 completeness bugs. One RISC Zero soundness bug, caused by a missing constraint in instructions with three register operands, yielded a $50,000 bounty despite prior audits (Hochrainer et al., 13 Sep 2025).
This line of work corrects a common misconception that zkVM security reduces to the abstract soundness of the underlying proof system. The literature repeatedly attributes trust to implementation correctness across the compiler, runtime, prover, and verifier stack, not solely to the cryptographic backend (Hochrainer et al., 13 Sep 2025). A related systems study on compiler optimization even reports that optimization-driven stress testing exposed a security-critical SP1 bug in which the system silently aborted mid-execution yet still produced a valid proof, underscoring that zkVM validation must extend into compiler behavior and execution tooling (Gassmann et al., 24 Aug 2025).
The same proof-carrying execution model is now being applied outside conventional rollup settings. A business-process architecture integrates a zkSTARK-based zkVM into workflow engines, allowing each organization to prove process steps without revealing private data; in its chained proving variant, each step verifies the prior proof inside the guest and emits a new proof, so verifying only the last proof suffices to trust the chain, although proof sizes encounter practical transport limits such as a cited 4 MB message cap (Kiesel et al., 24 Sep 2025). In software supply chains, zk-compilation executes a compiler inside a zkVM and outputs both the compiled artifact and a proof that the claimed compiler executed on the claimed source code. The proof-of-concept using RISC Zero and ChibiCC reports successful zk-compilation and verification for 252 programs and states that adversarial tests for compiler substitution, source tampering, output manipulation, and replay attacks were all blocked (Ron et al., 12 Feb 2026).
Across this literature, several open directions recur. Surveys emphasize continued bottlenecks in hashing, memory, and large-computation proving; the zkEVM literature stresses unresolved issues in formal verification of constraint-to-semantics equivalence, benchmarking, privacy, interoperability, decentralized proving, and hybrid zkEVM/zkVM architectures (Lavin et al., 2024, Hassanzadeh-Nazarabadi et al., 6 Oct 2025). A plausible implication is that zkVM research is moving from the question of whether arbitrary computation can be proved toward the more intricate question of how to make such proof systems performant, auditable, interoperable, and operationally reliable at scale.