Frequently Asked Questions

Common questions about RISC Zero zkVM, zero-knowledge proofs, and building zkVM applications

Zero-Knowledge Basics

What is a zero-knowledge proof?

A zero-knowledge proof (ZKP) is a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true without conveying any additional information.

RISC Zero’s zkVM makes it easy to produce ZKPs to prove the correct execution of arbitrary code.

How it works:

1. Alice executes code inside the zkVM
2. Alice receives a receipt as proof
3. Alice passes the receipt to Bob
4. Bob verifies the receipt

By verifying the receipt, Bob can confirm that the expected code executed and produced the asserted results. Any inputs Alice passes to the program remain private unless Alice chooses to share them.

Do I need to write ZK circuits to use RISC Zero?

No! RISC Zero handles all circuit construction for you.

You can focus on building applications using familiar programming languages (primarily Rust) and standard development tools. Everything you need is outlined in the zkVM documentation and Getting Started guide.

RISC Zero’s circuits:

• RISC-V circuit: Executes your compiled code
• Recursion circuit: Compresses multiple receipts into one
• STARK-to-SNARK circuit: Enables on-chain verification

What languages can I use to develop zkVM applications?

Rust is the recommended and fully supported language for writing zkVM applications.

While the zkVM can technically execute any RISC-V code, we only provide documentation and API support for Rust development. C++ development is possible but not officially supported.

For C++ examples from earlier releases, see the 0.11 release examples. The RISC Zero team can provide guidance on Discord for C++ development.

Building zkVM Applications

What should I compute in the guest vs. the host?

Compute in the guest (zkVM) when:

• The computation must be verifiable
• Others need to trust the result
• The output is used by downstream systems
• Security and correctness are critical

Compute on the host when:

• The computation doesn’t need to be proven
• It’s purely for convenience or preprocessing
• Performance is more important than verifiability

Design with an untrusted host in mind. Other parties should not need to trust the host’s output or operations to benefit from the work done in the zkVM.

What do I do with the receipt once I've created it?

After creating a receipt, you typically:

1. Pass it to a verifier who wants to check the computation
2. Provide the Image ID of the expected program
3. Optionally share the source code or ELF binary so the verifier can reconstruct the Image ID

The verifier can confirm:

• The correct code was executed (via Image ID matching)
• The execution was valid (via cryptographic proof)
• The public outputs (journal) are correct

In production systems, the receipt is typically passed to a third party for verification, not verified in the same program that generated it.

What is the Image ID and why is it important?

The Image ID is a unique cryptographic identifier for your zkVM application. It ensures applications run unaltered.

Key properties:

• Merkleization of the initial zkVM memory state
• Deterministically computed from the ELF binary
• Only includes functional code (excludes debug info, timestamps)
• Cryptographically links the binary to its receipts

Functionally equivalent binaries produce identical Image IDs, even if the compiled ELF files differ bitwise. This is a feature, not a bug.

If the binary is modified, the receipt’s seal will not match the expected Image ID, and verification will fail.

How do I prevent buffer overflows when sharing data with the guest?

The zkVM uses a memory-mapped communication mechanism with built-in protections:

• Write-once memory: Host-writable memory can only be written once
• No adjacent overwrites: Adjacent memory regions cannot be overwritten and executed
• Controlled input: Data is sent during program execution via secure channels

These protections prevent buffer overflow attacks while allowing efficient host-to-guest communication.

Performance and Limitations

What is the maximum execution length for a zkVM program?

With continuations support, execution length can be very large.

RISC Zero has successfully generated proofs for executions exceeding 4 billion cycles, with room to expand further.

Continuations split large executions into segments that are proven independently, then compressed into a single receipt through recursion.

How can I speed up processing in the zkVM?

Optimization strategies:

1. Use precompiles for cryptographic operations (SHA-256, BigInt, Keccak, ECDSA)
2. Offload to the host - Perform non-critical computation on the host and verify results in the zkVM
3. Enable GPU proving with CUDA or Metal backends
4. Profile and optimize using RISC0_INFO=1 and the profiling guide
5. Use composition to split large programs into smaller, parallelizable parts

For detailed optimization guidance, see the Optimization Guide and Precompiles documentation.

How do I handle large volumes of data in the guest?

Strategies for large data:

1. Stream data incrementally rather than loading everything at once
2. Use Merkle proofs to verify data integrity without loading all data
3. Compute SHA hashes of large datasets externally and verify in the guest
4. Leverage continuations to process data across multiple segments

The main constraint is instruction cycles, not memory. Loading and processing data both consume cycles.

Use env::read_frame() and env::read_framed() for improved cycle counts when reading input from the host.

Security

Can't the host tamper with the guest code if it runs on the host machine?

No. RISC Zero’s cryptographic proof system makes it infeasible to generate an invalid receipt:

• Modified binary: The seal won’t match the expected Image ID
• Modified execution: The execution trace will be invalid
• Modified output: The journal hash won’t match the hash in the receipt

The zkVM provides strong security guarantees even when running on completely untrusted hardware.

How can I verify that specific source code was executed?

To confirm a receipt corresponds to specific source code:

1. Reproduce the build using deterministic builds:
   cargo risczero build --manifest-path path/to/guest/Cargo.toml
   
2. Compare Image IDs: Check that the computed Image ID matches the Image ID in the receipt
3. Verify the receipt: Use the Image ID to verify the receipt cryptographically

RISC Zero uses containerized builds to ensure reproducibility across different machines and build environments.

Troubleshooting

I'm running into build errors. Where should I look for help?

Resources:

1. Check the Troubleshooting Guide for common issues
2. Search GitHub issues tagged “rust guest workarounds”
3. Open a new issue if your problem isn’t documented
4. Ask for help on the RISC Zero Discord

When reporting issues, include your RISC Zero version, Rust version, and a minimal reproduction case.

Next Steps

Quickstart

Build your first zkVM application

Troubleshooting

Solutions for common problems

Examples

Learn from working examples

Discord Community

Get help from the community