#14 - An Architectural Overview of RISC Zero
A Conversation with Jeremy Bruestle, CEO and Cofounder of RISC Zero
This article is a long-form breakdown of the interview discussion and ideas with Yavor Litchev and Jay Yu, both from Stanford Blockchain Club during an interview conducted in March 2025. Full Video here. Originally published on the Stanford Blockchain Review
Introduction
Zero Knowledge Proofs (ZKPs) are an area of cryptography which have seen a recent explosion of growth and adoption within the blockchain space. One of the most interesting applications of ZKPs is in building ZK Virtual Machines (ZKVMs), or computers that can prove that they correctly executed code on some secret input without revealing the inputs themselves.
RISC Zero is one of the leading companies within the ZKVM space, building provable computers based on the open-source RISC-V architecture. Within this article, we will first provide a primer on ZKVMs and RISC Zero’s overarching goal, before diving into the architectural design of RISC Zero’s 0STARK prover and the various architectural choices that they have made, and finally discussing some of the real-world use cases that RISC Zero unlocks, both in the blockchain space and beyond.
Thanks for reading Stanford Blockchain Review! Subscribe for free to receive new posts and support our work.
1 - An Introduction to ZKVMs and RISC Zero’s Prover
Imagine a computer that could print out a receipt, proving that you spent money at a coffee shop, without revealing what items you actually bought. This is the operating principle of a ZKVM, or a Zero Knowledge Virtual Machine.
ZKVMs are a virtual machine that runs trusted code and generates proofs. Developers can write arbitrary code in a language like Rust, have the code compile down to binary, and send it to the ZKVM to both execute the code and verify its execution [1]. The verification of the executable relies on Zero Knowledge Proofs, which allow for the cryptographic proof of a statement without revealing what the statement actually is. Let’s suppose I’m at a bar, and want to issue a proof to the bartender that I am over 21 without revealing what my actual age is. I can first “commit” my age (a secret number) by putting it inside of a cryptographically sealed envelope. The bartender will then challenge me to prove that the number is greater than 21, without actually opening the envelope itself. I provide some cryptographic proof using a “Prover” algorithm, and send this proof along to the bartender. The bartender will then run a “Verifier” algorithm, and either accept or reject the proof.
This is a classic example of a zero knowledge proof between a “Prover” and a “Verifier.” ZKVMs such as RISC Zero do something similar to this, but for arbitrary computation. Instead of creating zero knowledge proofs of simple statements, such as whether my age is greater than 21, ZKVMs use zero knowledge proofs to prove the correct execution of some “guest code” that the user provides it. To do this, they essentially compile down programs to polynomials (which are a mathematical object that can contain an unbounded amount of information) and then run proofs over all of these polynomials. Compiling arbitrary programs down to polynomials is a challenging and computationally expensive operation, as even the most trivial program needs to be represented as an “arithmetic circuits” [2], a nested tree-structure where each intermediary node is either an addition or a multiplication operation, and each leaf node is an input to the program (and the constant 1).
Many early projects in the space have sought to optimize for performance and stay close to the mathematical circuit layer. Circom, for example, is an early domain specific language used to define arithmetic circuits [3]. This, however, requires a high-level of expertise on the part of the developer, as developing in Circom can feel like developing in a low-level assembly language, optimized for performance but without any abstraction features or pre-built elements. Other projects, such as Aztec’s Noir language and Starkware’s Cairo language, seek to use a higher-level Domain Specific Language (DSL) to aid developers to easily create arithmetic circuits with a better developer experience. However, introducing a completely new programming language optimized for proving may hinder developer adoption, especially in an era of AI-assisted coding, as there is far less tooling, documentation, and existing repositories available to reference.
RISC Zero, however, takes a different approach. As its name suggests, one of the company’s defining choices was to based their ZKVM on the open-source RISC-V instruction set architecture (ISA), rather than create their own DSL [1]. RISC-V is a simple, minimal, and modern ISA that is much easier to arithmetic compared to other standard instruction sets such as x86 or MIPS. At the same time, it is a standard target for the LLVM compiler, so many mainstream languages, such as Rust and Go, can run directly in RISC Zero’s ZKVM and developers do not need to learn a new language from scratch. Furthermore, because RISC-V is an open ISA, it comes with a complete set of conformance tests and a formal model of the ISA [4]. RISC Zero could leverage these to ensure their ZKVM implementation exactly matches the RISC-V spec – crucial for security (no hidden undefined behaviors) and determinism. In fact, RISC Zero is working with formal verification tools (like Veridise’s Picus) to mathematically prove their ZKVM’s correctness against the RISC-V spec [4].
Thus, RISC-V represents the perfect balance between the compiler maturity, ZK performance, and semantic security. Developers can thus write code in familiar languages such as Rust, and enjoy existing infrastructure, tooling, and language support, while also leveraging the RISC Zero ZKVM to create secure, provable programs.
From a developer perspective, at a high level, RISC Zero’s ZKVM works as follows [1]:
A developer writes a “guest program” in Rust, that gets compiled down to a standard ELF binary
The executor executes the binary, and produces an execution trace of the “session”, or a complete record of the computation
The prover will take in session, and use that to generate a ZK proof as a receipt.
Under the hood, RISC Zero’s prover splits the process into several steps [5]:
Execution. The program is executed, generating a number of “segments.”
RISC-V Proving. Each segment is proven separately using FRI-based 0STARK Prover
Aggregation Proving. All the segment proofs are aggregated into a single proof, using a FRI-based 0STARK Prover
STARK-to-SNARK Proving. In order to output a proof that’s small enough to verify on-chain, the last step in the proving system relies on an elliptic-curve based Groth16 prover for a smaller on-chain footprint
As we can see, the majority of the proving, including the individual proving of the segments and the aggregation of these segment proofs relies on RISC Zero’s own proof system, the FRI-based 0STARK Prover. In Section 2, we will dive deeper into how this 0STARK Prover works, and the different architectural choices that the 0STARK system makes, and in Section 3, we’ll talk about what developers may be able to build using this system.
2 - A Technical Deep Dive into 0STARK Prover Architecture
The 0STARK Prover’s goal is to couple a RISC-V execution engine and session trace with a transparent, post-quantum secure STARK-based proof system. In this section, we will first dive into the reasoning for RISC Zero’s choice of STARKs, before discussing the three key parts to the 0STARK prover system: (1) randomized AIR arithmetization, (2) DEEP-ALI + FRI STARK instantiation for RISC-V proving, and (3) Merkle-based trace commitment scheme [6].
The 0STARK prover system relies on a zk-STARK foundation, eschewing SNARK-based architectures like Plonk or Marlin for several reasons. Firstly, STARKs allow working over small base fields without requiring trusted setups, and their polynomial IOPs naturally express repeated state‐transition constraints in hardware-inspired traces [6]. Secondly, STARKs scale nearly linearly with execution size and avoid pairing‐based cryptography, making them well-suited for VMs with millions of clock‐cycles. Moreover, unlike SNARKs, STARKs require no trusted setup, which simplifies tooling for developers and reduces operational risk. Verification remains efficient, on the order of milliseconds, even for large traces.
Nonetheless, the final step of the RISC Zero process relies on a “STARK to SNARK” process, where RISC Zero wraps the STARK transcript in a Groth 16-style succinct SNARK, yielding short on-chain proofs. This hybrid approach balances the efficient, transparent prover properties of STARKs with the minimal proof sizes enabled by Groth16 SNARKs.
Thus, this architecture is designed for recursive proofs, where one ZKVM proof can be verified inside another. While the current system uses a sequential (non-recursive) composition, RISC Zero engineers are exploring witness folding and proof‐system modularity to eventually enable on-chain recursive rollups without compromising the core AIR structure.
Now that we have discussed why RISC Zero chose to use STARKs over SNARKs as the foundation for its 0STARK system, we can now describe the interlocking components to the 0STARK system: a randomized AIR arithmetization, a DEEP-ALI + FRI STARK instantiation for RISC-V proving, and a Merkle-based trace commitment scheme. At a high level, the 0STARK protocol runs as follows [6]:
Setup: Public parameters –trace size, tapset definitions, AIR constraints – are derived from the RISC-V binary
Randomized Preprocessing: The prover executes the program, records control and data columns, encodes them via Reed-Solomon, and commits to Merkle caps. A verifier-randomness seeds the generation of memory and byte accumulators, which are also committed
Main Phase (DEEP-ALI + FRI): All constraints are linked into a combined constraint polynomial. The prover computes the validity witness, commits its low-degree segments, and responds to a DEEP query point. A batched FRI then checks proximity of the mixed R ap witness to the RS code, with query rounds verifying the integrity of the split and mix operations across multiple cosets
Verification: The verifier recomputes the combined constraint at the DEEP point, checks DEEPAnswerSequence consistency, and validates the FRI queries – all in polylogarithmic time relative to trace size
Throughout this model, 0STARK makes several cryptographic design decisions including [6]:
AIR over R1CS or CCS – In the setup process, Arithmetic Intermediate Representation (AIR) was chosen over R1CS or CCS because AIR naturally captures the time‐sequential, repeating structure of a CPU trace. Each AIR constraint enforces a low-degree polynomial relation between taps (field evaluations of registers or memory at nearby cycles). This leads to fewer and simpler constraints than an R1CS encoding, which would require auxiliary variables and more complex gate wiring for each instruction. While R1CS is more general, AIR yields better prover performance for deterministic, cycle-based computations, and directly leverages fast FFT and FRI operations. RISC Zero is also experimenting with the M³ arithmetization from the Irreducible team for further efficiency gains.
Handling large programs – Long execution traces from large programs can, in theory, lower the soundness margin if all cycles were checked naively. RISC Zero mitigates this by segmenting programs into smaller chunks, generating partial witnesses for each segment, and then composing them in a final DEEP-ALI step. This segmentation bounds the length of individual AIR checks, preventing an attacker from easily sampling invalid witnesses in a huge trace. The segments are merged using the same mixing and quotienting techniques present in the main STARK loop, ensuring end-to-end integrity.
Randomized Preprocessing and Constraint Batching Innovations – RISC Zero’s soundness analysis diverges from ethSTARK primarily in its use of randomized preprocessing to instantiate PLONK-style permutation and PLOOKUP-based range arguments for memory consistency. In this phase, accumulators for memory and byte-lookup are computed and committed alongside the trace, enabling a single AIR to enforce both permutation and lookup in one shot.
During DEEP-ALI, all AIR constraints are batched parametrically into a single combined polynomial using powers of a single random field element, rather than multiple independent randomness values. This parametric batching reduces round-trip complexity and improved prover efficiency compared to affine batching in ethSTARK. Similarly, the batched FRI protocol compresses multiple FRI instances into one using a single random challenge, further streamlining proof generation.
Optimizing Validity Polynomials – Standard STARK constructions yield separate FRI checks for the trace and for the validity polynomial. 0STARK moves beyond this by splitting the high-degree validity quotient into four low-degree “segment” polynomials, each of which is folded into the main FRI invocation. This degree reduction both lowers FRI complexity and unifies the FRI checks into a single proximity argument, tightening the overall soundness bound.
Through its combination of STARK transparency, parametric batching, AIR efficiency, and FRI folding, RISC Zero delivers a high-throughput, developer-friendly ZKVM capable of proving arbitrary Rust programs compiled to RISC-V. This architecture balances practical prover performance with small, fast proofs, and lays the groundwork for recursive proof composition and integration with broader cryptographic protocols.
RISC Zero’s ZKVM is inherently generic: any computation expressible in RISC-V can be proven. This opens the door to running operations on data encrypted via Fully Homomorphic Encryption (FHE), yielding proofs of correct decryption or transformation without revealing secrets. Similarly, ZKVMs can host multi-party computations by encoding MPC protocols as RISC-V code. Many in the community are exploring MPC + ZKVM hybrids, where parties jointly compute on secret data and produce a single succinct proof of correctness. RISC Zero’s flexible proof architecture is well positioned to serve as the trustless foundation for these advanced cryptographic stacks.
3 - Performance and Applications of RISC Zero in Practice
RISC Zero’s ZKVM is not just an academic exercise. In this section, we survey the RISC Zero ZKVM’s performance and its potential applications and developer tooling ecosystem.
There are many methods of benchmarking the performance of a system, however one important metric is quite simply the execution speed of the system. While traditional VMs are measured in billions of instructions per second, zkVMs report throughput in megahertz of proof‐checked execution. RISC Zero currently sustains around 60 MHz of effective execution throughput on a single GPU-enabled prover, meaning it can validate 60 million RISC-V clock cycles per second in zero knowledge, around the computation speed of a 1990s computer [7].
While this may be much less performant than modern CPUs in isolation, the computational cost of ZK proving is already orders of magnitude cheaper than execution on the Ethereum L1. The proof-generation process can be highly parallelizable: by distributing AIR constraint evaluations and FRI folds across multiple GPUs, provers can proportionally increase throughput.
Moreover, just as Moore’s Law once captured the rapid scaling of transistor density, we’re witnessing a ZK Moore’s Law in cryptographic proof systems, where the growth is rapidly accelerating thanks to several simultaneous scaling laws [8]. These include optimizations in arithmetization logic, such as AIR batching, FFT implementations, as well as GPU-friendly FRI algorithms that are delivering year-over-year prover speed improvements that outpace hardware transistor scaling. There have also been proposals for the development of SNARK proving ASICs [9] and other hardware level acceleration tactics for ZK. Similar to the early days of deep learning, where algorithmic advances and parallel hardware yielded exponential gains, ZKVM performance is hyperscaling, with practical prover throughput doubling (or better) each cycle. Over the next few years, ZKVM prover speed is expected to converge towards native RISC-V speeds, closing the gap between proof-checked and regular code execution.
Having ZKVMs available to provide this verifiable computation unlocks many different use cases both within the blockchain world and beyond. In the blockchain world, ZKVMs enhance scaling and privacy by shifting heavy computation off-chain and verifying results with succinct proofs – an idea known as ZK Coprocessors. ZKVMs can also work with components of the existing blockchain scaling stack. For example, RISC Zero has worked with Optimism to add ZK fraud proofs to their optimistic rollup using the Kailua ecosystem, improving finality delays in the optimistic rollup process and reducing rollup collateral costs [10]. Furthermore, RISC Zero also allows for the proving of an entire Ethereum block, including verifying transaction signatures, account and state storage, applying transactions, and updating the state root by taking existing Rust implementations of the Ethereum such as revm and running RISC Zero’s prover [11].
On the application layer, RISC Zero’s ZKVM has also enabled many innovative use-cases. For example, an early demo application was Bonsai-Pay, which allowed users to send Ethereum to others’ Gmail addresses and was based on the RISC Zero Bonsai prover system [12]. The Hashflow Exchange is also launching an off-chain exchange engine called xOS that uses RISC Zero to prove the matching and risk calculations of a high-performance trading engine, with proofs posted to a Celestia-based chain [13]. By separating the fast “service layer” (running off-chain with normal performance) from the verifiable “settlement layer,” Hashflow can give users the best of both worlds: CEX-like speed with DEX-like trustlessness.
RISC Zero’s ZKVM also has further applications in the social and identity realm outside of web3, such as the example mentioned at the start of proving someone’s age without revealing the age itself. In fact, RISC Zero has shown how it can be used to prove that a JSON file contains a specific field and value without revealing the full file [14]. This could be especially useful in selectively proving sensitive information like photo metadata – we may want to prove that a photo was taken by a certain device (such as a Canon 5D Mark IV) without revealing other sensitive information such as the location of the photo.
Crucially, developers can write all of these applications using the familiar language of Rust, rather than have to learn a low-level ZK circuit language like Circom or a DSL such as Noir or Cairo. If you know Rust, or any other language that can compile to RISC-V, you can simply write your logic, compile with cargo risc0 to a RISC-V binary, and the toolchain emits a provable artifact in minutes. And in the process, you can leverage the power of all existing Rust sources, from language documentation to debuggers like GDB to AI-assisted coding tools like Copilot or Cursor. For example, our example at the beginning of proving a person’s age is over 21, we can simply write as our guest function:
// ----
// check_age.rs:
#![no_main]
risc0_zkvm::guest::entry!(main);
pub fn main() {
let age: u32 = 25;
let is_over_21 = age >= 21;
risc0_zkvm::guest::env::commit(&is_over_21);
}
// -----
// main.rs:
use methods::CHECK_AGE_ELF;
use risc0_zkvm::default_prover;
fn main() {
let prover = default_prover();
let receipt = prover.prove(CHECK_AGE_ELF).unwrap();
let is_over_21: bool = receipt.journal.decode().unwrap();
println!("Proof generated. Over 21: {}", is_over_21);
}Conclusion
In conclusion, RISC Zero represents a major leap in the evolution of zero-knowledge computing, offering a practical, performant, and developer-friendly ZKVM built on top of the open RISC-V architecture. By combining a transparent STARK-based proof system with a familiar Rust-based development experience, RISC Zero bridges the gap between cryptographic rigor and real-world usability. Its architectural innovations – such as the 0STARK prover, recursive-proof readiness, and hybrid STARK-to-SNARK compression – position it at the forefront of verifiable computation, unlocking a new generation of applications from scalable blockchain rollups to high-performant trading engines to privacy-preserving identity and social proofs.
Looking ahead, RISC Zero is building toward a future where zero-knowledge computing is universal, scalable, and developer-friendly. By standardizing proof APIs, enabling recursive proofs, accelerating performance with hardware, expanding language and tooling support, and streamlining the developer experience, RISC Zero aims to make ZKVMs a core primitive across blockchains and beyond.
References
[1] https://dev.risczero.com/api/zkvm/
[2] https://en.wikipedia.org/wiki/Arithmetic_circuit_complexity
[3] https://docs.circom.io/
[4] https://risczero.com/blog/RISCZero-formally-verified-zkvm
[5] https://risczero.com/blog/designing-high-performance-zkVMs
[6] See details of 0STARK technical paper: https://dev.risczero.com/proof-system-in-detail.pdf
[7] High-end 1990s computers like the Pentium operated at 60 MHz: https://en.wikipedia.org/wiki/Pentium_(original)
[8] See ZK Moore’s Law:
[9] ZK11: SNARK proving ASICs - Justin Drake
[10] https://risczero.com/blog/kailua-how-it-works
[11] Zeth: https://risczero.com/blog/zeth-release
[12] Bonsai Pay: https://risczero.com/blog/bonsai-pay
[13] HashFlow: https://medium.com/@hashflowdex/introducing-xos-the-provable-exchange-e875f4e6b30e
[14] RISC Zero JSON Example: https://github.com/risc0/risc0/tree/release-2.0/examples/json
[15] Image Metadata: https://libguides.graduateinstitute.ch/rdm/image-metadata
About the Interviewees
Jeremy Bruestle
Jeremy Bruestle is the co-founder and CEO of RISC Zero, a company pioneering general-purpose zero-knowledge virtual machines (zkVMs). With over two decades of experience in cryptography, distributed computing, and software engineering, Jeremy has consistently focused on bridging emerging mathematical research with real-world applications. Prior to RISC Zero, he co-founded Spiral Genetics, where he served as CTO, developing cloud-based bioinformatics platforms for rapid genome analysis. He also held roles such as Principal Engineer at Intel and Chief Scientist at Vertex.AI, contributing to advancements in mathematical models and algorithms.
Yavor Litchev
Yavor is an undergrad at Stanford pursuing a degree in computer science with a focus on cybersecurity and cryptography. He has previously engaged in research projects relating to secure machine learning and digital signatures with more flexible access structures at MIT PRIMES. More recently, he is researching secure systems and program execution using software fault isolation through the CURIS program. He is currently the cryptography research lead for the Stanford Blockchain Club.
Jay Yu
Jay is an undergrad at Stanford pursuing a double major in Computer Science and Philosophy. He is President of the Stanford Blockchain Club and founder of the Stanford Blockchain Review. He researches designs for Decentralized Autonomous Organizations (DAOs) and blockchain governance with Stanford Law School faculty and as a Research Fellow for IC3. He also works on the investments team at Pantera Capital.