Skip to main content

Network Architecture

Auctioneer and Settlement Diagram

The Succinct Prover Network is a protocol for generating zero-knowledge proofs. While architecting the network, we thought about a user experience for both requesters and provers that would enable secure payments, verifiable matching, and a high performance user experience.

To achieve this, the prover network implements a decentralized marketplace where any requester can expect to receive competitive prices and any prover can quickly join and begin fulfilling proofs as a verifiable application (vApp). This architecture is similar to the design pattern of an L2 sequencer and onchain settlement of an L2, in that it separates execution from settlement.

The network is architected with off-chain components that manage the auction process and proof assignment (akin to a sequencer) and on-chain smart contracts that settle state roots and proofs of correct execution. This enables a unified deployment that avoids the limitations in transaction throughput of existing chains. Users do not have to deal with the block latency of any current blockchain and instead face a real-time experience.

This provides users with the experience of interacting with a high performance web application while giving them the assurance that their deposits are secure and enabling them to independently verify the state of the network.

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 prover gas: An upper bound on the computational complexity of generating the proof, in prover gas units (PGUs).
  • Maximum fee: The maximum amount in PROVE tokens the user is willing to pay for the proof.
  • Deadline: The maximum amount of time the user is willing to wait for the proof's delivery after assignment.
  • Verification key: The key required to verify the proof on-chain or off-chain.

Provers​

Provers are participants who generate proofs in response to requests by bidding in auctions:

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

Provers can support specialized hardware and can run proving in clusters of hundreds of GPUs, depending on the requirements of the requesters and the network.

Network Components​

The network has two primary components:

  • Off-chain auctioneer service – the auctioneer service is the main off-chain entity responsible for matching user requests to provers. Requesters submit proof requests and payments and provers submit bids to the auctioneer; requesters receive proofs and provers receive payments in return. Because users interact with the auctioneer directly through RPC calls, they face a high performance, real-time system.
  • On-chain settlement contracts – the settlement contracts settle state roots and ZK proofs periodically submitted by the auctioneer. These proofs contain the updates that the auctioneer makes to the state of the network, via incoming requests, cancellations, and fulfillments. The settlement contracts also allows users to withdraw their funds directly from Ethereum and manage staking.

Because the auctioneer is responsible for processing requests and proof fulfillments, users face a fast web application. The settlement contract ensures the verifiability of the network and the security of user deposits. In particular, the auctioneer does not custody any user funds. Funds live on Ethereum, where they can be withdrawn directly by the user.

Auctioneer Service and Verifiable Database​

Verifiable Backend

The network makes use of a backend architecture that can allow anyone to independently verify updates of balances and proof fulfillments made in the network with the high performance of a normal web application. The auctioneer service is the main actor that holds user state and periodically posts proofs of state updates to Ethereum. The auctioneer service is composed of two pieces:

  • A verifiable database that stores user balances, pending proof requests, and proof fulfillments. This database is made commitment-friendly via Merkle proofs of read and write operations that are posted to Ethereum.

  • A prover that reads from the database and computes a ZK proof of the new state of the network. The prover is composed of an SP1 program that contains the state transition function of the network. The state transition function tracks balance updates, proof assignments, and proof fulfillments. The prover then executes and generates proofs of this program and periodically settles these proofs on Ethereum, which can be used by anyone to independently verify the state of the network.

Data Availability Layer​

The network currently ephemeral storage to store proof request data; as on-chain data availability becomes increasingly abundant, the network will move to persistent data storage. This data availability layer can store proof data and provide fast retrieval of the data for verifiation.

Ethereum Smart Contracts​

Smart contracts on Ethereum provide a trust-minimized settlement layer for the Succinct Prover Network. These contracts handle:

  • Deposits and withdrawals: Requesters deposit PROVE tokens to pay for proof requests. Requesters can easily withdraw their funds from Ethereum, even if the auctioneer is not live, enabling trust-minimized payments.
  • Staking and slashing: Provers stake PROVE tokens in order to be eligible to participate in auctions in the network. Their stake acts as economic security to cover the costs of missed deadlines and griefing. 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.
  • Payments and value distribution: Payments, fee, and network emissions handled on Ethereum.
  • Network governance: Enables decentralized governance of the parameters related to the vApp, staking, slashing, and auctions.

These contracts ensure that economic guarantees for deposits, withdrawals, and slashing are enforced without relying on any centralized entity.