Prover

A CPU prover executes proof generation on general-purpose central processing units (CPUs).

• Characteristics: Highly accessible, as it runs on standard server hardware, but is typically the slowest and most computationally expensive option.
• Use Case: Often used in development, testing, or for chains prioritizing maximum hardware decentralization over performance.
• Example: Early versions of proof systems or research implementations often start as CPU-based provers.

A GPU prover leverages graphics processing units to parallelize proof computation.

• Characteristics: Offers a significant speed-up (10-100x) over CPU provers by performing many cryptographic operations in parallel, making it cost-effective for production.
• Use Case: The standard for most high-throughput zkRollups (e.g., zkSync, Polygon zkEVM) requiring frequent proof generation.
• Hardware: Utilizes consumer (NVIDIA, AMD) or specialized server-grade GPUs.

An ASIC prover uses Application-Specific Integrated Circuits, hardware custom-built for a single proof system.

• Characteristics: Delivers the ultimate performance and energy efficiency for a specific zk-SNARK or zk-STARK algorithm but lacks flexibility and has high upfront development cost.
• Use Case: Essential for maximizing the throughput of a single, settled proof system where economies of scale justify the investment.
• Trade-off: Creates potential centralization risks if prover hardware is controlled by few entities.

An FPGA prover uses Field-Programmable Gate Arrays, reconfigurable hardware that can be optimized for specific proof algorithms.

• Characteristics: Offers a middle ground between GPU flexibility and ASIC performance. Faster and more efficient than GPUs for the targeted algorithm, but can be reprogrammed if the proof system changes.
• Use Case: Ideal for proof systems still under active development or for operators seeking a performance boost without permanent hardware commitment.
• Example: Used in some high-frequency trading environments and specialized proving services.

A distributed prover network breaks a single large proof into smaller sub-proofs computed across many machines, then aggregates the results.

• Mechanism: Employs recursive proof composition or proof aggregation to combine work from multiple, potentially weaker, hardware nodes.
• Characteristics: Aims to democratize access to proving, reduce hardware centralization, and leverage idle compute resources. Can introduce networking overhead.
• Goal: To create a more decentralized and censorship-resistant proving layer, akin to mining pools or validator networks.

A cloud prover service provides proving computation as a managed API, abstracting hardware complexity for developers.

• Model: Developers submit proof tasks to a service provider's endpoint, which runs on optimized backend hardware (often GPU clusters).
• Characteristics: Lowers the barrier to entry for dApp and chain developers, who pay per proof. Shifts the burden of hardware procurement, maintenance, and optimization to the service.
• Consideration: Introduces a trust assumption in the service provider's reliability and introduces potential centralization points in the stack.

Generates validity proofs for transaction batches in ZK-Rollups. It is the core component that computes the state transition and outputs a Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) or zk-STARK. This proof is posted to the underlying Layer 1 (e.g., Ethereum) for final settlement.

• Primary Role: Ensure the new state root is correct without revealing transaction details.
• Example: The prover in zkSync Era or StarkNet sequencer nodes.

Decentralized networks that provide proving-as-a-service. They allow any application to offload computationally intensive proof generation to a specialized network of hardware operators.

• Key Concept: Separates the roles of application logic and proof computation.
• Use Case: A dApp can send a complex computation (e.g., a machine learning inference) to a co-processor like Risc Zero or Brevis, which returns a verifiable proof of the result.

Specialized hardware like GPUs, FPGAs, and ASICs designed to accelerate the most computationally intensive parts of proof generation, particularly elliptic curve operations and Fast Fourier Transforms (FFT).

• Purpose: Drastically reduce proving times and costs, which is critical for scalability.
• Players: Companies like Ingonyama, Cysic, and Ulvetanna develop hardware optimized for zk-SNARKs and zk-STARKs.

A technique where multiple proofs are combined into a single, verifiable proof. This reduces the on-chain verification cost and data footprint for systems processing high volumes of transactions or proofs.

• Mechanism: Uses recursive proof systems where one proof can verify the correctness of other proofs.
• Benefit: Enables layer-3 networks or proof batching for greater economic efficiency on Layer 1.

A fundamental distinction in proof systems based on their requirement for a trusted setup ceremony.

• Trusted Setup (zk-SNARKs): Requires a one-time generation of proving and verification keys using secret parameters that must be destroyed (e.g., Groth16). Carries a minor trust assumption.
• Transparent (zk-STARKs, Bulletproofs): Requires no trusted setup, relying only on cryptographic hashes. Offers stronger trust minimization at the cost of larger proof sizes.

Provers are incentivized through fees and slashed for malfeasance, aligning their economic interests with network security.

• Incentives: Earn fees from users for proof generation services.
• Slashing: In some networks, provers must stake collateral (bond) which can be slashed if they submit an invalid proof.
• Decentralization Goal: Moving from centralized, permissioned provers to decentralized networks is a key challenge for the ecosystem.

A prover is a computational agent that generates a cryptographic proof (e.g., a zk-SNARK or zk-STARK) attesting to the correct execution of a program or transaction batch. It takes a computational statement (the program and its inputs) and produces a small, easily verifiable proof that the output is valid. This enables trustless verification where the verifier only needs to check the proof, not re-run the entire computation.

In a zk-Rollup, the prover (often called a sequencer or operator) batches hundreds of transactions off-chain, executes them, and generates a validity proof (a zk-SNARK/STARK). This proof, along with the new state root and minimal data, is posted to the underlying Layer 1 (e.g., Ethereum). The L1 smart contract (the verifier) checks the proof to finalize the state update, ensuring data availability and execution integrity without trusting the prover.

Decentralized prover networks distribute the computationally intensive proof generation task. Key architectures include:

• Permissionless Networks: Anyone can run a prover node and earn fees for generating proofs (e.g., Aleo, Risc Zero).
• Proof Marketplaces: Protocols like Risc Zero's Bonsai or =nil; Foundation's Proof Market allow applications to request proofs from a decentralized network of provers.
• Specialized Hardware: Proving often requires optimized hardware (GPUs, FPGAs, ASICs) for performance, leading to specialized prover services.

The prover's implementation depends on the underlying proof system. Common systems include:

• zk-SNARKs (Succinct Non-Interactive Argument of Knowledge): Requires a trusted setup but produces very small, fast-to-verify proofs. Used by Zcash and zkSync Era.
• zk-STARKs (Scalable Transparent Arguments of Knowledge): No trusted setup, with larger proof sizes but faster prover times. Used by StarkNet.
• PLONK and Groth16: Popular zk-SNARK constructions with different trade-offs in setup, proof size, and prover speed.
• RISC Zero's zkVM: Uses a zero-knowledge virtual machine to generate proofs for arbitrary Rust code.

Proving is computationally expensive, creating key trade-offs:

• Prover Time: The latency to generate a proof, which scales with computation complexity. This is a major bottleneck for real-time applications.
• Cost: Proving cost includes hardware (GPU/ASIC) and electricity. Proof aggregation (batching multiple proofs into one) can reduce cost per transaction.
• Incentives: Provers are typically incentivized by transaction fees or protocol rewards. The economic model must ensure liveness and decentralization of the prover network.

The verifier is the prover's cryptographic counterpart. It is a lightweight algorithm or smart contract that checks the proof's validity. Key characteristics:

• Efficiency: Verification is orders of magnitude faster and cheaper than proof generation.
• On-Chain Role: In L2s, the verifier is typically a smart contract on the L1 blockchain.
• Trust Model: The system's security rests on the verifier correctly checking the proof. A malicious or buggy verifier compromises the entire system.

The counterpart to a prover. A verifier is a smart contract or off-chain program that cryptographically checks the validity of a proof submitted by a prover. Its role is to be computationally lightweight, confirming the proof's correctness without re-executing the original complex computation.

• Function: Accepts a proof and public inputs, runs a verification algorithm, and returns a boolean (true/false) result.
• Key Trait: Verification must be significantly cheaper than the original computation to enable scalability.

The cryptographic primitive that enables a prover's function. A Zero-Knowledge Proof allows one party (the prover) to prove to another (the verifier) that a statement is true, without revealing any information beyond the validity of the statement itself.

• Core Properties: Completeness, Soundness, and Zero-Knowledge.
• Prover's Role: Generates the ZKP, which is the output of its proving process.

The private input data known only to the prover. A witness is the set of secret information that satisfies the constraints of a computational statement. The prover uses the witness to generate a proof, but the witness itself is never revealed to the verifier.

• Example: In proving you know the password to an account, the password is the witness.
• Relation to Prover: The prover's core job is to process the witness and public inputs to create a valid proof.

The computational model for which proofs are generated. An arithmetic circuit is a representation of a computation as a series of addition and multiplication gates over a finite field. Most ZK-proof systems require the original program logic to be compiled into this format.

• Prover's Task: The prover executes the computation trace for this circuit using the witness, generating the proof that all gates were evaluated correctly.
• Foundation: Circuits define the Rank-1 Constraint System (R1CS) or similar structures that the proof attests to.

A key role in rollup architectures that often works with a prover. A sequencer orders and batches transactions off-chain. In a ZK-Rollup, the sequencer's batch of transactions is given to a prover to generate a validity proof.

• Workflow: Sequencer batches tx → Prover generates proof of correct state transition → Verifier checks proof.
• Separation of Duties: The sequencer handles liveness and ordering; the prover handles computational integrity.

The specific cryptographic protocol used by the prover. A proof system (e.g., zk-SNARKs, zk-STARKs, Bulletproofs) defines the algorithms for proof generation and verification. The choice of system dictates the prover's efficiency, proof size, and trust assumptions.

• Prover Implementation: The prover is built to run the Prove algorithm of a specific proof system.
• Trade-offs: Systems vary in prover speed, setup requirements (trusted setup), and proof verification cost.