Skip to content

Feature Request: Separate Verifier Generation from Proof Generation #93

Description

@june-in-exile

Currently, the Pico zkVM SDK requires developers to generate a full proof (via prove_evm) in order to obtain the Groth16Verifier.sol contract. This creates an unnecessary coupling between two conceptually distinct operations:

  1. Setup/Keygen (circuit-dependent) → Generate verifier contract
  2. Proving (input-dependent) → Generate proofs for specific inputs

Current Workflow Problem

To deploy a verifier contract, developers must:

// Currently required - generates BOTH proof AND verifier
client.prove_evm(stdin_builder, true, output_dir, "kb")?;

This approach has significant drawbacks:

Resource Overhead

  • Time: ~30 minutes per generation
  • Memory: ~32GB Docker container requirement
  • Output: Generates unnecessary proof files when only verifier is needed

Use Case Mismatch

  • The verifier contract only depends on the circuit structure (ELF file), not on specific input values
  • In production workflows, we typically:
    1. Deploy verifier contract once (needs only Groth16Verifier.sol)
    2. Generate proofs many times with different inputs (needs proof.data + inputs.json)

Current Workaround

The only way to obtain Groth16Verifier.sol is to provide dummy inputs and run the full proving pipeline, which is wasteful:

// Dummy inputs just to generate verifier
stdin_builder.write(&0u32);
stdin_builder.write(&0u32);
// ... more dummy inputs

client.prove_evm(stdin_builder, true, output_dir, "kb")?;
// Wait 30 minutes for proof we don't need
// Just to get Groth16Verifier.sol

Proposed Solution

Add a dedicated method for verifier generation:

// Proposed API
let client = DefaultProverClient::new(&elf);
client.generate_verifier(output_dir)?;

This would:

  • Accept only the ELF file (circuit definition)
  • Skip witness generation, constraint solving, and proof computation
  • Output only Groth16Verifier.sol and verification key (vm_vk)
  • Complete in seconds instead of minutes

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions