Skip to main content

Network Components

The Succinct Prover Network is a protocol for generating zero-knowledge proofs on demand. It is architected with three components: off-chain coordination through an auction node, a data availability layer for storing proof data, and Ethereum smart contracts for final settlement. The goal is to provide a fast, decentralized marketplace for proof generation that is both performant and trust-minimized.

In this section, we will cover the participants of the network and outline the key network components.

Participants​

The network consists of two main participants: Requesters (applications that need zero-knowledge proofs) and Provers (entities that generate these proofs).

Requesters​

Requesters, or applications seeking zero-knowledge proofs, submit proof requests to the network. A proof request typically includes:

  • Program: A Rust program representing the computation to be proven.
  • Inputs: The public or private inputs to the program.
  • Maximum cycle count: An upper bound on the computational complexity (or resource usage) for generating the proof.
  • Fee: An amount offered as payment for successful proof generation.
  • Deadline: A block or time-based deadline by which the proof must be delivered.
  • Verification key: The key required to verify the proofs on-chain or off-chain.

These fees are held in escrow by the protocol, ensuring that the prover who eventually delivers a valid proof is paid. Once a proof is generated and verified, the requester can relay it to their desired chain or application. The fee is then released to the winning prover.

Provers​

Provers are permissionless participants who generate proofs in response to requests:

  • They deposit collateral on-chain to become eligible for bidding in proof contests.
  • They run node software that listens for new requests, places bids, and generates proofs.
  • They compete with other provers in an auction (proof contest) by offering bids to generate the requested proofs.
  • The winning prover for each request is obligated to deliver the proof by the given deadline, or risk having part of their collateral slashed if they fail.

Provers can support specialized hardware, depending on the requirements of the requesters and the network.

Network Components​

The Succinct Prover Network has three primary components:

  1. Auction Node – Handles core network logic, including coordinating proof requests and selecting winning provers.
  2. Data Availability Layer – Stores proof data off-chain for efficient retrieval and decentralized access.
  3. Smart Contracts – Enforces settlement, staking, slashing, and fee payouts on Ethereum.

Each component plays a crucial role in ensuring the network remains efficient, permissionless, and secure.

Auction Node​

The auction node is an off-chain system that performs most of the network’s coordination functions. It runs as a single binary that contains:

  • An off-chain sequencer to receive and order proof requests from requesters.
  • The proof contest mechanism to select provers based on their bids and collateral.

This design allows the auction node to be gradually decentralized in future iterations.

Sending a Proof Request​

To submit a proof request, a requester uses the sp1_sdk::ProverClient (a Rust SDK) with specific environment variables. For example:

SP1_PROVER=network NETWORK_PRIVATE_KEY=... RUST_LOG=info cargo run --release

This command instructs the SDK to send the proof request to the network’s auction node, along with the necessary configuration. The request includes all required parameters (program, inputs, cycle count, fee, deadline, verification key).

Proof Contests​

When the auction node receives a proof request, it initiates a proof contest where provers have a fixed time window to submit bids. These contests are essentially auctions, where:

  1. Provers post collateral in advance.
  2. Provers bid from their collateral to secure the right to generate the requested proof.
  3. The auction node selects the winning prover(s) based on their bids; most of the time, the winning prover is the one with the highest bid, but in some cases, proof contests can be won by lower bidders. The parametrization of the proof contest is configurable by the network.

Once a prover wins the auction, they are responsible for generating and submitting the proof by the provided deadline. If they fail, they risk having their collateral slashed according to the protocol’s rules.

Streaming Proofs​

To minimize latency and allow for near-real-time verification, the auction node streams proof data to the data availability layer as proofs are generated. This approach:

  • Reduces proof latency by allowing proof data to be streamed as soon as proofs are ready.
  • Ensures global availability of the proof data, so that multiple parties can verify or replicate it.

Data Availability Layer​

The Data Availability (DA) layer is an off-chain system responsible for:

  • Storing proof data.
  • Providing fast retrieval of proof data for verification.

By maintaining the proof data off-chain, the data availability layer helps keep on-chain overhead minimal. Requesters or verifiers can quickly fetch the data to confirm that a proof is valid without overburdening Ethereum.

In a typical workflow:

  1. A proof is generated.
  2. The auction node streams the proof to the DA layer.
  3. Any user, including on-chain smart contracts, can fetch the proof data from the DA layer to verify the proof or store it locally.

Ethereum Smart Contracts​

On Ethereum, a set of smart contracts provide the trust-minimized settlement layer for the Succinct Prover Network. These contracts handle:

  • Deposits and Withdrawals: Requesters deposit fees in USDC (or another token), while provers deposit collateral.
  • Slashing: If a winning prover fails to deliver a valid proof in time, part or all of their collateral may be slashed according to protocol rules.
  • Payment and Fee Distribution: Once a proof is verified, the fee is automatically released to the correct prover.
  • Proof Verification: On-chain smart contracts can verify proofs.
  • Network Governance (future iterations): Potentially manages upgrades, parameter changes, or other aspects of the network in a decentralized way.

These contracts ensure that economic guarantees—like escrow, collateral, and slashing—are enforced without relying on any centralized entity.