Designing secure zkVM applications: A fireside chat with Rami Khalil (RISC Zero)

In this fireside chat, we invited Rami Khalil, Senior Protocol Engineer at RISC Zero, to discuss the design space for building applications using the RISC Zero zkVM.

Rami explores the types of applications now possible thanks to zkVMs, addresses key security and privacy-related questions, and explains how decentralized proving works with RISC Zero’s Boundless. He also shares advice for developers building zkVM-based applications.

Finally, Jon shares security insights from Veridise’s experience auditing zkVM applications, and Rami offers a glimpse into what’s next for RISC Zero.

See the full timestamps and text summary below.

Conversation highlights

Here’s a breakdown of the topics covered:

• 00:17 — What is a zkVM, specifically RISC Zero’s zkVM?
• 03:04 — What’s the dev experience like, and what are the benefits?
• 06:01 — What guarantees does the zkVM provide that devs don’t need to worry about?
• 08:04 — What do you mean by “underconstrained input”?
• 10:24 — Can you build privacy apps with RISC Zero?
• 11:11 — Can you maintain privacy while using the proving network?
• 13:08 — What new apps are now possible thanks to zkVMs?
• 17:22 — Who’s the Boundless proving network for, and how will decentralized proving work?
• 20:42 — How does integrating RISC Zero impact a protocol’s security?
• 24:17 — How do you ensure the zkVM is secure?
• 26:03 — Are you using the best cryptography, constraint and proving systems?
• 29:18 — Can you take advantage of parallelism based on the number of machines you have?
• 30:17 — What would you love to see built with RISC Zero?
• 30:47 — What’s the value of using FHE inside a zkVM?
• 32:28 — What advice do you have for devs building zkVM-based apps?
• 33:12 — Examples when ZK proofs won’t benefit an application?
• 34:45 — Jon’s security tips for developers
• 40:02 — Has anyone shared interesting use cases for Steel?
• 46:37 — What else is RISC Zero building beyond Boundless?
• 49:17 — Any upcoming apps aside from Keccak?

Summary of the fireside chat

Below is a text summary of the fireside chat content. The conversation covered the fundamental concepts of zkVMs, the specifics of RISC Zero’s technology, application development, security considerations, and future developments.

What is a zkVM?

Rami explained that a zkVM is essentially a practical realization of zero-knowledge proofs. He likened a zero-knowledge proof to a generalization of signatures. In a signature, a private key produces a signature on a message, verifiable by a public key. With a zero-knowledge proof, the “private part” can be any input, the “signing algorithm” is any program, and the “signature” is a zero-knowledge proof alongside the program’s output. This proof provides confidence that only someone with the correct input could have generated that specific output using the program.

Developer experience and benefits

Rami highlighted that the RISC Zero zkVM was the first general-purpose zkVM. A key innovation was support for any program compiled down to the standard RISC-V instruction set architecture. This offered a huge unlock for developers because it allowed them to write programs using most regular programming languages, primarily Rust, instead of needing to learn domain-specific languages (DSLs) like Circom.

Tasks that might have taken months to build and debug using hand-written R1CS circuits in C++ can now be implemented over a weekend using the RISC Zero zkVM.

This approach supports familiar programming patterns like loops and conditionals, which execute naturally in the virtual machine. The application format is intuitive and requires minimal additional knowledge beyond conventional Rust development. Most Rust crates will work out of the box, provided they don’t rely on features like hardcoded assembly or system-specific calls that aren’t compatible with RISC-V. This significantly lowers the barrier to entry and accelerates development of ZK applications.

Security of zkVM applications and the zkVM

While the RISC Zero zkVM itself provides a crucial ZK guarantee, meaning the verifier learns nothing about the program’s execution trace, developers still bear responsibility for designing secure applications. Rami discussed potential pitfalls, emphasizing two main areas:

1. Under-constrained inputs / missing validation: This occurs when a program accepts inputs from untrusted sources without proper validation. A program might make assumptions about the input, and if a malicious party provides forged or unauthenticated inputs, the resulting proof doesn’t guarantee what the developer intended. For example, in a naive zkEVM implementation using the revm crate, if storage values aren’t authenticated (e.g., via Merkle inclusion proofs against the state trie), an attacker could prove execution against a falsified state. To prevent this, critical input data must either be validated within the zkVM or made part of the public output, so that the verifier can assess its correctness.
2. Privacy leaks: Although the zkVM provides a ZK guarantee over the execution trace, the program’s output can still leak private information if not carefully designed. For applications requiring privacy with private inputs, the proof generation should ideally be done by a trusted party, such as the user’s own machine. While proving networks like Boundless or Bonsai exist, using them with private input requires careful consideration to avoid exposing sensitive data. It’s also important to ensure that even if private inputs don’t flow directly to public outputs, information about them can’t be inferred by cobbling together facts from other public data.

The fundamental trust assumption when using a zkVM is the safety and correct implementation of the zkVM itself. Rami explained that RISC Zero addresses this through rigorous auditing and formal verification efforts to ensure the zkVM is deterministic and complies with the RISC-V specification. They also dedicate resources to keeping up with the latest ZK research, constraint systems, and proving systems, with a team quantifying the potential impact of new developments on their proving infrastructure.

Proving network: Boundless

Rami introduced Boundless as RISC Zero’s decentralized proving network. It acts as a marketplace connecting “seekers” who need proofs generated with “provers” capable of fulfilling those requests. Boundless can operate on any chain supporting its smart contracts. Its core purpose is to make block space “abundant instead of scarce” by offloading compute to the network, effectively providing “more execution” without altering the underlying chain’s security consensus (though it introduces cryptographic assumptions). The system uses an auction mechanism where provers bid, aiming for efficient price discovery for the seeker. RISC Zero plans to extend Boundless to support other zkVMs in the future.

Applications enabled by zkVMs

The general-purpose nature and scalability of the RISC Zero zkVM enable previously difficult or impossible applications.

• ZK fault proofs for layer 2s: Rami is particularly passionate about Layer 2 systems and highlighted Kailua, RISC Zero’s ZK fault proof system for rollups. Unlike previous interactive fault proof systems susceptible to attacks from wealthy adversaries, Kailua makes fault proofs non-interactive. It requires only a single honest transaction from one honest party for safety. Kailua achieves this by throwing the entire block execution and derivation process into the zkVM, relying on its ability to compute and prove even very long executions (“a few trillion cycles”).
• Secure bridging and light clients: Jon and Rami discussed how zkVMs can enhance bridging security, especially for cross-chain scenarios like Bitcoin and Ethereum. While some trust assumptions remain necessary for consensus and synchrony, the zkVM can reduce the cost and impact of worst-case scenarios where malicious parties try to misrepresent the state of a chain. The ability to prove very short summaries of execution helps provide strong integrity guarantees for the reported state, facilitating the creation of more secure on-chain light clients.
• Verifiable view calls (Steel): Rami mentioned Steel, a RISC Zero library that allows developers to replicate and prove the results of Ethereum view calls inside the zkVM for off-chain verification. Steel is a library developers can build on to interact with Ethereum and prove things like block data consistency without implementing complex validation themselves. As an example of its power, one client used Steel to generate a proof that would have cost 10 billion gas on-chain (millions of dollars). RISC Zero is adding features to Steel to allow verifying receipts and events that happen on-chain.
• Combining zkVM with FHE: Rami brought up the potential, though currently expensive, application of combining Fully Homomorphic Encryption (FHE) with a zkVM. FHE provides privacy by allowing computations on encrypted data. However, FHE alone doesn’t guarantee the computation was run correctly. By running FHE computations inside a zkVM, the zkVM provides the certification (proof of correct execution), while FHE ensures the data remains private during the computation, enabling secure delegation of the proving task. The output would initially be encrypted, and the user would then prove locally that they know how to decrypt the output in the zkVM receipt.

Rami’s advice for developers considering building zkVM application

Rami shared a key piece of advice for developers exploring zkVM-based applications: First, ask whether zero-knowledge is truly necessary. Before committing to a ZK-based approach, carefully assess if it’s the right tool for the problem. In some cases, alternatives like multi-party computation (MPC) may be what offers the required guarantees.

Jon’s security advice for developers building zkVM applications:

Jon shared the following advice based on Veridise’s experience auditing zkVM applications:

• Validate inputs: Ensure that any data your program relies on, especially from untrusted sources, is properly validated either on-chain or within the zkVM itself. Pay close attention to the flow of information from input to output to avoid under-constrained inputs.
• Be careful with privacy: If using private inputs, design the program and output to avoid leaking sensitive information. Be aware that information about private inputs might be inferable from other public data or outputs.
• Understand on-chain interaction: When proofs are verified on-chain, remember that a proof typically should only result in an action being taken once to prevent replay attacks. Do not rely on the cryptographic uniqueness of the proof itself as a nullifier, as slight input variations or even inherent randomization in the proof system might produce different proof hashes for the same logical execution outcome. Design proofs and on-chain verification logically.
• Side channel awareness: The efficiency focus of zkVMs (including hardware acceleration via precompiles) might mean constant-time execution isn’t guaranteed for all operations. The non-straight-line nature of general-purpose programs also allows for timing channels based on execution paths, which can be exacerbated by the long computation times in ZK proving. Rami noted that currently, the RISC Zero prover prioritizes speed over mitigating timing side channels by adding delays.

What’s next for RISC Zero?

Rami shared that RISC Zero is currently very focused on the release of Boundless. (Editor’s note: Boundless has been recently published after shooting the fireside chat). They also have a strong performance roadmap planned for the zkVM itself. This includes:

• An exclusive deal with the Binius team to integrate Binius into the zkVM, which is expected to enable the creation of high-performance ASICs (Application-Specific Integrated Circuits) for proving. Internal tests have shown potential for 30x improvements.
• Continued development of precompiles for cryptographic operations like BN254 for pairings and BLS381 for KZG-related tasks. The Keccak precompile is already live for example.
• A second version of the zkVM circuit is coming soon, anticipated to provide a 2–3x performance improvement across most programs. This has also already been released after the interview.

The conversation concluded with Jon and Rami thanking each other for the insightful discussion, acknowledging the complexities and exciting future of zkVM technology.

About RISC Zero & Boundless:

RISC Zero is a company that provides a zkVM (zero-knowledge virtual machine), enabling developers to generate ZK proofs of ordinary software execution for secure and verifiable computation. Boundless is RISC Zero’s latest product — a universal protocol that brings zero-knowledge (ZK) capabilities to every blockchain.

Learn more:

• Boundless website: https://beboundless.xyz/
• Boundless docs: https://docs.beboundless.xyz/developers/what
• Boundless Twitter: https://x.com/boundless_xyz
• RISC Zero website: https://risczero.com/