Zero-Knowledge Proofs in SnarkVM

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/provablehq/snarkvm/llms.txt

Use this file to discover all available pages before exploring further.

​

What are Zero-Knowledge Proofs?

​

Properties of SNARKs

• Succinct: Proofs are small (~few KB) regardless of computation size
• Non-interactive: No back-and-forth between prover and verifier
• Arguments of Knowledge: Prover must actually know the witness
• Zero-Knowledge: Proof reveals nothing about private inputs

​

Use Cases in Aleo

• Private Transactions: Transfer tokens without revealing amounts or addresses
• Private Programs: Execute arbitrary logic with hidden inputs
• Proof-Carrying Data: Chain proofs to create complex privacy-preserving applications
• Verifiable Computation: Prove correct execution without re-running

​

R1CS Constraint Systems

​

Rank-1 Constraint System

A * B = C

A = a₀ + a₁·x₁ + a₂·x₂ + ... + aₙ·xₙ

​

Variables and Witnesses

pub struct Variable(Index);

pub enum Index {
    Public(usize),   // Public input variable
    Private(usize),  // Private witness variable
}

• Public Variables: Known to both prover and verifier (public inputs/outputs)
• Private Variables: Known only to prover (private witness)
• Constants: Fixed values compiled into circuit

​

Linear Combinations

pub struct LinearCombination<F: Field> {
    constant: F,
    terms: Vec<(Variable, F)>,  // (variable_id, coefficient)
}

LinearCombination {
    constant: 3,
    terms: vec![(Variable(Index::Public(1)), 2),
                (Variable(Index::Private(2)), 5)],
}

​

Constraint System Trait

pub trait ConstraintSystem<F: Field> {
    fn new_variable<Fn>(
        &mut self,
        mode: Mode,
        f: Fn,
    ) -> Result<Variable>;
    
    fn enforce_constraint(
        &mut self,
        a: LinearCombination<F>,
        b: LinearCombination<F>,
        c: LinearCombination<F>,
    ) -> Result<()>;
}

​

Circuit Construction

​

From Operations to Constraints

temp1 = a + b
temp2 = c + d
result = temp1 * temp2

temp1 = (1·a + 1·b + 0)  // No constraint needed
temp2 = (1·c + 1·d + 0)  // No constraint needed

temp1 * temp2 = result  // 1 R1CS constraint

​

Example: Field Multiplication

impl<E: Environment> Mul<Field<E>> for Field<E> {
    type Output = Field<E>;

    fn mul(self, other: Field<E>) -> Self::Output {
        // Allocate output variable with computed value
        let output = witness!(|a, b| console::Field::new(a * b));
        
        // Enforce: self * other = output
        E::enforce_constraint(
            (&self).into(),   // A = self
            (&other).into(),  // B = other
            (&output).into(), // C = output
        );
        
        output
    }
}

​

Cost Model

​

Varuna SNARK System

​

Architecture

pub mod ahp;         // Algebraic Holographic Proof for R1CS
pub mod varuna;      // Varuna zkSNARK proof system

​

Components

pub struct UniversalSRS<N: Network> {
    // Polynomial commitment parameters
    // Universal for all circuits up to a maximum size
}

pub struct ProvingKey<N: Network> {
    circuit_verifying_key: CircuitVerifyingKey<N>,
    circuit_proving_key: CircuitProvingKey<N>,
    // Circuit-specific polynomial commitments
}

pub struct VerifyingKey<N: Network> {
    circuit_commitments: Vec<Commitment<N>>,
    circuit_verifying_key: CircuitVerifyingKey<N>,
}

pub struct Proof<N: Network> {
    commitments: Vec<Commitment<N>>,
    evaluations: Vec<N::Field>,
    batch_proof: BatchProof<N>,
}

​

Proof Generation Flow

​

Polynomial Commitment Scheme

1. Commit: Prover commits to witness polynomials (few KB)
2. Query: Verifier challenges prover at random points
3. Open: Prover provides evaluations and opening proofs
4. Verify: Verifier checks commitments match opened values

​

Program Execution and Proving

​

Stack and Process

pub struct Stack<N: Network> {
    program: Program<N>,
    universal_srs: UniversalSRS<N>,
    proving_keys: Arc<RwLock<IndexMap<Identifier<N>, ProvingKey<N>>>>,
    verifying_keys: Arc<RwLock<IndexMap<Identifier<N>, VerifyingKey<N>>>>,
    // ...
}

​

Execution Modes

pub enum CallStack<N: Network> {
    Authorize(/* ... */),      // Sign execution request
    Synthesize(/* ... */),     // Generate circuit (no proof)
    CheckDeployment(/* ... */),// Validate deployment circuit
    Evaluate(/* ... */),       // Execute console types only
    Execute(/* ... */),        // Execute + generate proof
    PackageRun(/* ... */),     // Development mode execution
}

let response = stack.evaluate_function(
    function_name,
    inputs,
)?;
// Returns output values, no proof

let (response, proof) = stack.execute_function(
    proving_key,
    function_name,
    inputs,
    rng,
)?;
// Returns output values + SNARK proof

​

Proof Generation Steps

1. Evaluation: Run console types to compute output
2. Injection: Convert console values to circuit variables
3. Synthesis: Execute circuit, generating constraints
4. Witness Assignment: Populate all variables with values
5. AHP Proving: Convert R1CS to algebraic holographic proof
6. Polynomial Commitment: Commit to witness polynomials
7. Proof Assembly: Package commitments and evaluations

​

Proof Verification Steps

1. Parse Public Inputs: Extract public variables from proof
2. Circuit Verification: Check proof against verifying key
3. Polynomial Checks: Verify polynomial commitment openings
4. Output Validation: Ensure outputs match public values

​

Cryptographic Primitives

​

Elliptic Curves

// curves/src/bls12_377/mod.rs
pub struct Bls12_377;

pub type Fq = Fp384<FqParameters>;  // Base field (384-bit)
pub type Fr = Fp256<FrParameters>;  // Scalar field (256-bit)

pub struct G1Affine;  // Group 1 (on base curve)
pub struct G2Affine;  // Group 2 (on twist)

• 128-bit security level
• Efficient pairing computation
• Edwards curve (EdDSA) compatible scalar field

​

Hash Functions

// algorithms/src/crypto_hash/poseidon.rs
pub struct Poseidon<F: Field, const RATE: usize> {
    // Algebraic hash function optimized for R1CS
}

• Designed for SNARK circuits
• Low constraint count (~150 constraints per hash)
• Collision-resistant and one-way

​

Performance Characteristics

​

Typical Proof Times

​

Verification Performance

• Verification Time: ~1-10ms (independent of circuit size)
• Verification Cost: Dominated by pairing computations
• Batch Verification: Amortized cost for verifying multiple proofs

​

Optimization Strategies

​

Circuit-Level Optimizations

1. Minimize Multiplications: Each multiplication = 1 constraint
2. Reuse Computations: Cache intermediate results
3. Algebraic Tricks: Use field properties (e.g., Fermat’s little theorem for inversion)
4. Boolean Packing: Pack multiple booleans into field elements

​

System-Level Optimizations

1. Parallel Proving: Leverage multi-core CPUs
2. GPU Acceleration: Use CUDA for MSM and FFT
3. Caching: Precompute proving keys for common circuits
4. Batch Processing: Generate multiple proofs in parallel

​

Example: Optimized Range Proof

let bits = value.to_bits_le();  // O(bits) constraints
for bit in bits {
    // Constrain each bit is 0 or 1: bit * (1 - bit) = 0
    bit * (1 - bit).enforce_equal(&zero);  // 1 constraint per bit
}

// Use lookup tables or algebraic range proofs
// Reduces constraint count logarithmically

​

Security Considerations

​

Trusted Setup

• One-time ceremony generating SRS
• Universal parameters for all circuits
• Security relies on at least one honest participant

​

Soundness

• Invalid proofs are rejected with overwhelming probability
• Prover cannot convince verifier of false statements
• Security based on cryptographic assumptions (e.g., discrete log)

​

Zero-Knowledge

• Public Inputs: Intentionally disclosed (e.g., transaction outputs)
• Public Outputs: Computation results
• Nothing Else: Private witnesses remain hidden

​

Best Practices

​

For Circuit Design

1. Profile First: Measure constraint counts before optimizing
2. Test Soundness: Verify invalid inputs are rejected
3. Validate Ranges: Ensure integers stay within bounds
4. Check Edge Cases: Test zero, max, and boundary values

​

For Program Development

1. Minimize Circuit Operations: Use console types where possible
2. Batch Transactions: Amortize proof costs across multiple operations
3. Cache Proving Keys: Avoid regenerating keys repeatedly
4. Monitor Constraint Growth: Track circuit size as programs evolve

​

Debugging Circuits

​

Constraint Counting

use snarkvm_circuit::prelude::*;

let count_before = Circuit::num_constraints();
let result = complex_operation(a, b, c);
let count_after = Circuit::num_constraints();

println!("Constraints generated: {}", count_after - count_before);

​

Witness Inspection

let value = circuit_variable.eject_value();  // Extract console value
println!("Circuit value: {}", value);

​

Constraint Checking

// In tests:
assert!(Circuit::is_satisfied());
assert_count!(1000, 1050);  // Min, max expected constraints

​

Further Reading