Security Model

RISC Zero provides an end-to-end solution for verifiable computation with strong cryptographic guarantees. This page details the security properties, cryptographic assumptions, and potential vulnerabilities of the zkVM.

Overview

The RISC Zero zkVM implements a three-layer recursive proof system that provides:

Soundness: Cryptographically infeasible to generate fake proofs
Zero-knowledge: Proofs reveal nothing beyond the public outputs
Completeness: Valid executions always produce verifiable proofs

With default parameters, the system achieves 98 bits of conjectured security and targets perfect zero-knowledge.

System Components

The zkVM consists of five high-level components, each with distinct security properties:

1. cargo risczero Tool

Compiles Rust code into RISC-V ELF binaries deterministically. Audit: October 31, 2023 Security considerations:

Deterministic builds ensure consistent Image IDs
Users should verify Image IDs independently
Compiler bugs could affect guest code correctness

2. RISC-V Prover

Executes and proves execution of ELF binaries using zk-STARKs. Audit: October 31, 2023 Cryptographic properties:

Protocol: zk-STARK
Security: 96 bits
Quantum-safe: Yes (hash-based)
Assumptions: Random Oracle Model, Toy Problem Conjecture

3. Recursion Prover

Aggregates proofs from the RISC-V Prover using recursion programs (lift, join, resolve). Audit: October 31, 2023 Cryptographic properties:

Protocol: zk-STARK
Security: 99 bits
Quantum-safe: Yes
Assumptions: Random Oracle Model, Toy Problem Conjecture

Control mechanisms:

Each recursion program has a control ID
Allowed programs identified by control root
Updates to recursion programs don’t require new trusted setup

4. STARK-to-SNARK Prover

Verifies STARK proofs and compresses them into Groth16 SNARKs for efficient on-chain verification. Audit: May 20, 2024 Cryptographic properties:

Protocol: Groth16 over BN254 curve
Security: 99+ bits
Quantum-safe: No (elliptic curve based)
Assumptions:
- Security of BN254 elliptic curve pairing
- Knowledge of Exponent assumption
- Integrity of Groth16 trusted setup ceremony

The STARK-to-SNARK Prover is not quantum-safe. Quantum computers could potentially break BN254-based proofs. STARK proofs remain quantum-safe.

5. On-Chain Verifier Contracts

Smart contracts that verify Groth16 proofs on Ethereum and EVM-compatible chains. Audit: June 5, 2024 Security considerations:

Control root is hard-coded into contracts
Version management and governance documented in Version Management Design
Contract addresses available in verifier contract docs

Cryptographic Security Analysis

Soundness

Question: Can a malicious user create a fake proof for an invalid execution? Answer: The probability is cryptographically negligible (less than 2^-96).

STARK Security Estimate

With 96 bits of security, breaking the STARK protocol would require approximately 100,000 years using:

1 million high-end GPUs (e.g., RTX 4090)
Each performing ~25 billion SHA-256 hashes per second

Calculation:

2^96 / (25,000,000,000 hashes/s × 1,000,000 GPUs) 
  / (60s × 60min × 24h × 365days) 
  ≈ 100,492 years

Detailed analysis available in the security calculator. Run the calculator with:

RUST_LOG=risc0_zkp=debug cargo run --release

The security calculation assumes the Toy Problem Conjecture, which states that the best known attack on STARK systems is the best possible attack.

Groth16 Security

The STARK-to-SNARK prover’s best known attack vector is against the BN254 elliptic curve pairing:

BN254 has been battle-tested since EIP-197 on Ethereum
Provides 99+ bits of security
Security analysis in Zcash GitHub discussion

Zero-Knowledge

Question: Can a verifier extract secret information from a proof? Answer: The zkVM targets perfect zero-knowledge, meaning proofs reveal nothing beyond:

The journal (public output)
The Image ID (what code ran)
The exit code (how execution terminated)

Zero-Knowledge Caveats

Privacy Warning: Whoever generates the proofs can see all secret data. Use local proving for sensitive applications.

Execution length leakage:

Segment receipts leak information about execution length
Succinct receipts (after recursion) do not leak execution length
Use succinct receipts for applications requiring full privacy

Mathematical proof status: RISC Zero has not yet published a mathematical proof of zero-knowledge. Minor engineering changes are planned to facilitate such a proof.

Applications with critical privacy requirements should wait for formal zero-knowledge proof or conduct independent security analysis.

Threat Model

Trusted Components

Users must trust:

RISC Zero implementation - Audited but complex software
Cryptographic assumptions - Standard in the field
Compilation toolchain - cargo risczero and RISC-V compiler
Control root - Identifies allowed recursion programs
Trusted setup (Groth16 only) - One-time ceremony

Untrusted Components

The system is secure even if these are malicious:

Prover - Cannot create fake proofs
Guest code - Execution is proven, bugs are guest’s problem
Input data - Can be malicious, guest must validate
Network - Proofs can be verified offline

Out of Scope

RISC Zero cannot prevent:

Bugs in guest code logic
Vulnerabilities in smart contracts using receipts
Social engineering attacks
Misuse of verified outputs
Side-channel attacks on prover hardware

Important: zkVM adopters must validate the security of their guest programs and smart contracts through secure development practices and external audits.

Development vs. Production

Development Mode

Enabled with RISC0_DEV_MODE=1:

export RISC0_DEV_MODE=1

Properties:

Generates fake receipts instantly
NO cryptographic security
Useful for testing and debugging
Verification succeeds without actual proofs

Checking dev mode:

use risc0_zkvm::is_dev_mode;

if is_dev_mode() {
    eprintln!("WARNING: Dev mode enabled!");
}

Disabling Dev Mode

For production systems, use the disable-dev-mode feature:

[dependencies]
risc0-zkvm = { version = "1.0", features = ["disable-dev-mode"] }

This prevents accidental use of RISC0_DEV_MODE in production.

Never deploy dev mode to production! Fake receipts provide zero security guarantees.

Security Best Practices

For Developers

Validate inputs in guest code

// Guest code
let input: InputData = env::read();

// ALWAYS validate
if !input.is_valid() {
    panic!("Invalid input");
}

Use appropriate receipt types

Development: Fake receipts
Testing: Succinct receipts
Production: Succinct or Groth16 (as needed)
Privacy-critical: Succinct receipts only

Verify Image IDs

// Use const IMAGE_ID from build process
receipt.verify(IMAGE_ID)?;

// Don't use hardcoded values that might be wrong

Handle verification errors

match receipt.verify(IMAGE_ID) {
    Ok(()) => /* use journal */,
    Err(e) => {
        // Log, alert, reject - never ignore!
        return Err(e.into());
    }
}

For Verifiers

Check the Image ID

// Know what code you expect
const EXPECTED_IMAGE_ID: [u8; 32] = /* ... */;

receipt.verify(EXPECTED_IMAGE_ID)?;

Validate journal contents

let output: Output = receipt.journal.decode()?;

// Check output makes sense
if output.value > MAX_ALLOWED {
    return Err("Invalid output");
}

Use appropriate verifier context

let ctx = VerifierContext::default();
receipt.verify_with_context(&ctx, IMAGE_ID)?;

For On-Chain Applications

Validate contract addresses

Use official RISC Zero verifier contracts
Verify control root matches expectations
Monitor for contract upgrades

Gas considerations

Groth16 verification: ~270,000 gas
Budget appropriately for verification calls

Handle verification failures

try verifier.verify(seal, imageId, journalDigest) {
    // Success - proceed with application logic
} catch {
    // Verification failed - reject
    revert("Invalid proof");
}

Audit History

All security audits are publicly available:

Component	Date	Auditor	Report
zkVM (RISC-V + Recursion)	Oct 31, 2023	Hexens	Link
STARK-to-SNARK	May 20, 2024	Hexens	Link
Verifier Contracts	Jun 5, 2024	Hexens	Link

Responsible Disclosure

If you discover a security vulnerability:

Do not publish it publicly
Email security reports to: [email protected]
Include detailed reproduction steps
Allow time for patch development and disclosure

RISC Zero follows responsible disclosure practices and may offer bug bounties for critical vulnerabilities.

Additional Resources

Proof System in Detail - Full cryptographic specification
Security Calculator - Bits of security analysis
Audit Reports - All security audits
ethSTARK Documentation - STARK security analysis
BN254 Security Discussion - Curve security

Next Steps

zkVM Overview - Understanding the zkVM
Architecture - System design
Blockchain Integration - On-chain verification

Get Started

Core Concepts

zkVM Development

Proving

Advanced

Blockchain Integration

Security Model

Security Model

Overview

System Components

1. cargo risczero Tool

2. RISC-V Prover

3. Recursion Prover

4. STARK-to-SNARK Prover

5. On-Chain Verifier Contracts

Cryptographic Security Analysis

Soundness

STARK Security Estimate

Groth16 Security

Zero-Knowledge

Zero-Knowledge Caveats

Threat Model

Trusted Components

Untrusted Components

Out of Scope

Development vs. Production

Development Mode

Disabling Dev Mode

Security Best Practices

For Developers

For Verifiers

For On-Chain Applications

Audit History

Responsible Disclosure

Additional Resources

Next Steps

Build docs developers (and LLMs) love

Get Started

Core Concepts

zkVM Development

Proving

Advanced

Blockchain Integration

​Security Model

​Overview

​System Components

​1. cargo risczero Tool

​2. RISC-V Prover

​3. Recursion Prover

​4. STARK-to-SNARK Prover

​5. On-Chain Verifier Contracts

​Cryptographic Security Analysis

​Soundness

​STARK Security Estimate

​Groth16 Security

​Zero-Knowledge

​Zero-Knowledge Caveats

​Threat Model

​Trusted Components

​Untrusted Components

​Out of Scope

​Development vs. Production

​Development Mode

​Disabling Dev Mode

​Security Best Practices

​For Developers

​For Verifiers

​For On-Chain Applications

​Audit History

​Responsible Disclosure

​Additional Resources

​Next Steps

Build docs developers (and LLMs) love

Security Model

Overview

System Components

1. cargo risczero Tool

2. RISC-V Prover

3. Recursion Prover

4. STARK-to-SNARK Prover

5. On-Chain Verifier Contracts

Cryptographic Security Analysis

Soundness

STARK Security Estimate

Groth16 Security

Zero-Knowledge

Zero-Knowledge Caveats

Threat Model

Trusted Components

Untrusted Components

Out of Scope

Development vs. Production

Development Mode

Disabling Dev Mode

Security Best Practices

For Developers

For Verifiers

For On-Chain Applications

Audit History

Responsible Disclosure

Additional Resources

Next Steps