Skip to main content

Proof Lifecycle

The proof request lifecycle encompasses the entire journey of a zero-knowledge proof from its initial request to final verification. This page provides a comprehensive walkthrough of each stage in this process, detailing how the network and provers interact to generate proofs.

Overview​

The Succinct Prover Network orchestrates a sophisticated multi-step process to transform a proof request into a verified, usable zero-knowledge proof. This process involves multiple parties and components working together in a coordinated sequence.

The following sequence diagram illustrates the lifecycle of a proof request from creation to completion:

Lifecycle Stages​

1. Proof Request Submission​

The lifecycle begins when a client application needs a zero-knowledge proof:

  • The client first uploads the necessary artifacts to the network's artifact service:

    • The program to be proven (compiled ELF binary)
    • The stdin input data
    • The network returns URIs for each uploaded artifact

  • The client prepares a proof request containing:

    • The artifact URIs for the program and stdin
    • Public and/or private inputs
    • Maximum prover gas units (computational complexity limit)
    • Proof deadline
    • Maximum fee in PROVE offered for proof generation
    • Circuit version requirements
    • Whitelisted provers

  • Using the Succinct SDK, the client submits this request to the network:

    // Set environment variables
    std::env::set_var("SP1_PROVER", "network");
    std::env::set_var("NETWORK_PRIVATE_KEY", "<YOUR_PRIVATE_KEY>");
    std::env::set_var("NETWORK_RPC_URL", "https://rpc.production.succinct.xyz");

    // Create client and submit proof request
    let client = ProverClient::from_env();
    client.prove(&pk, &stdin)
      .core()
      .run();

  • The network registers the request, assigns it a unique identifier, and confirms receipt to the client:

    RequestProofResponse(request_id: "0x7647102964f2c8116637472379dc8d427a4b267089fe961074bc223a7c4833dd")

  • The client's payment is held in escrow to ensure funds are available for the eventual prover.

2. Bidding and Prover Selection​

Once the request is registered, the network selects a prover through a reverse auction process:

  1. Provers periodically call GetFilteredProofRequests() to discover new, unassigned requests.
  2. Each interested prover evaluates the request to determine if they can meet the requirements.
  3. Eligible provers submit bids through BidRequest(), specifying their proposed fee.
  4. The network evaluates bids based on price, prover stake, historical performance, and other factors.
  5. The winning prover receives an assignment notification.

This auction process ensures proofs are generated efficiently and at competitive prices, while maintaining quality and reliability.

3. Request Assignment and Preparation​

Once a prover is selected, preparation for proof generation begins:

  • The prover receives an assignment notification from the network.
  • The prover calls GetProofRequestDetails() to retrieve comprehensive information about the request.
  • If needed, the prover may create additional artifacts using CreateArtifact(), such as auxiliary data required for proving.
  • The network provides URIs for all artifacts, including the program binary and input data.
  • The prover downloads all necessary artifacts from the network's storage layer.

This preparation phase ensures the prover has all information and resources needed to complete the proof generation successfully.

4. Proof Generation​

With all preparations complete, the prover generates the zero-knowledge proof:

  • The prover initializes its local proving environment with the appropriate circuit version.
  • It loads the program binary and inputs into the prover system.
  • The prover executes the program to record its execution trace.
  • It generates a proof from the execution trace.
  • Throughout the process, the prover monitors progress to ensure it can meet the deadline.
  • If the prover encounters issues that prevent successful proof generation, it may report a failure.

Proof generation is computationally intensive and represents the core value provided by provers in the network. The complexity and duration depend on the prover gas units, circuit version, and other factors.

5. Proof Submission​

Once the proof is generated, the prover submits it back to the network:

  • The prover calls FulfillProof(), passing the proof data and any required metadata.
  • The network acknowledges receipt with FulfillProofResponse().
  • The proof is stored in the network's data availability layer for future access.
  • The network records the completion time and updates the request status.

Successful proof submission triggers the release of the escrowed payment to the prover, and a fraction of this payment is transferred to the protocol treasury.