Skip to main content

Prover Network FAQ

tip

For organizations prioritizing security, minimum latency, and proving at scale, please get in touch. In other words if you're interested in volume-based discounts, latency-optimized proving, and uptime / latency SLAs, let's talk.

Latency-Optimized Proving​

The prover network currently parallelizes proof generation across multiple machines. As a result, proof latency does not scale linearly with prover gas units. Proving times are a function of both the prover gas units, and the number of machines utilized for proof generation.

Benchmarking latency-sensitive apps on the default prover endpoint is suboptimal for various reasons. For accurate results or production use, contract us to set up a latency-optimized environment.

Note: if you are currently using GPU acceleration, keep in mind it operates on a single GPU. The only way to have distributed and parallelized proof generation is through the prover network.

Succinct Prover Network Costs​

Proof generation costs are currently tied to the amount of resources your proof consumes, which is a function of prover gas units (PGUs) and proof type (Groth16 and PLONK each have a small fixed cost).

If you are planning to use the Succinct Prover Network regularly for an application, please reach out to us. For applications above a certain scale, we offer volume based discounts.

Benchmarking on Small vs. Large programs​

In SP1, there is a fixed overhead for proving that is independent of your program's prover gas usage. This means that benchmarking on small programs is not representative of the performance of larger programs. To get an idea of the scale of programs for real-world workloads, you can refer to our benchmarking blog post and also some numbers below:

  • An average Ethereum block ranges between 300-500M PGUs (including Merkle proof verification for storage and execution of transactions) with our keccak and secp256k1 precompiles.
  • For a Tendermint light client, the average resource consumption is ~100M PGUs (including our ed25519 precompiles).
  • We consider programs with <2M PGUs to be "small" and by default, the fixed overhead of proving will dominate the proof latency. If latency is incredibly important for your use-case, we can specialize the prover network for your program if you reach out to us.

Note that if you generate Groth16 or PLONK proofs on the prover network, you will encounter a fixed overhead for the STARK -> SNARK wrapping step (~6s and ~70s respectively). We are working on optimizing the wrapping latencies