Prover

Hardware-accelerated provers use Field-Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs) to perform the computationally intensive cryptographic operations required for proof generation. These specialized machines:

• Dramatically reduce proving times (from minutes to seconds).
• Lower the operational cost of running a prover node.
• Are essential for high-throughput applications and decentralized prover networks. Companies like Ingonyama and Cysic are developing such hardware to democratize access to efficient proving.

The primary function of a prover is to execute a computation and generate a zero-knowledge proof (ZKP) or validity proof. This process involves:

• Taking a witness (private inputs and intermediate states) and a circuit (the program logic).
• Running a proving algorithm (e.g., Groth16, PLONK, STARK) to create a cryptographic proof.
• Outputting a small, succinct proof that can be verified much faster than re-running the original computation.

Provers are categorized by their underlying proof system and trust model:

• ZK-SNARK Provers: Generate small, fast-to-verify proofs but often require a trusted setup (e.g., Groth16).
• ZK-STARK Provers: Generate larger proofs but are post-quantum secure and do not require a trusted setup.
• Validity Provers (Optimistic Rollups): In systems like Arbitrum and Optimism, a prover creates a fraud proof only if a state assertion is challenged, differing from always-on ZK provers.

These are the two essential, complementary components in a proving system:

• Prover: Computationally expensive. Responsible for proof generation, requiring significant processing power and memory.
• Verifier: Computationally cheap. A smart contract or light client that checks the proof's validity in constant time, regardless of the original computation's complexity. The prover's output enables the verifier's efficiency.

Generating ZK proofs is highly computationally intensive, leading to specialized hardware solutions:

• GPU Provers: Utilize parallel processing (e.g., with CUDA/OpenCL) for faster MSM (Multi-Scalar Multiplication) and FFT (Fast Fourier Transform) operations.
• FPGA/ASIC Provers: Offer even greater performance and efficiency for specific proof systems, used by professional proving services to minimize latency and cost.

In a ZK-Rollup, the prover is a core off-chain component:

1. Sequencer batches transactions and produces a new state root.
2. Prover generates a validity proof (ZK-SNARK/STARK) attesting to the correctness of the state transition.
3. The proof is posted on the parent chain (e.g., Ethereum) to a Verifier Contract, which finalizes the state update. This allows for secure scaling by moving execution off-chain.

A prover's security depends on its cryptographic setup and implementation:

• Trusted Setup: Some SNARK provers require a ceremony to generate public parameters; compromise corrupts all future proofs.
• Transparent Setup: STARK provers and some SNARKs (e.g., Halo2) have no trusted setup, enhancing decentralization.
• Correctness: The prover must be implemented flawlessly; bugs can generate valid proofs for invalid state transitions, breaking the system's security.

A prover's primary role is to execute a computation and generate a cryptographic proof (e.g., a SNARK or STARK) attesting to its correct execution. This proof is small and can be verified on-chain much faster and cheaper than re-running the original computation. Key tasks include:

• Witness Generation: Processing private inputs and intermediate states.
• Constraint Satisfaction: Ensuring the computation adheres to a predefined set of rules (the circuit).
• Proof Output: Producing a succinct, verifiable proof of correctness.

Provers are specialized for different proof systems and architectures:

• zkEVM Provers: Generate proofs for Ethereum-compatible smart contract execution (e.g., used by Scroll, zkSync Era).
• ZK Rollup Provers: Create proofs for batched transactions in Layer 2 scaling solutions (e.g., StarkNet, Polygon zkEVM).
• Coprocessor Provers: Generate proofs for complex off-chain computations that feed data back to a main chain (e.g., RISC Zero, Axiom).
• Storage Provers: Prove data availability or the correct state of a data repository (relevant to validity-proof-based data availability layers).

Proof generation is computationally intensive, often requiring specialized hardware for efficiency.

• CPU/GPU Provers: General-purpose hardware, common for development and certain proof systems.
• FPGA Provers: Field-Programmable Gate Arrays offer a balance of flexibility and performance optimization.
• ASIC Provers: Application-Specific Integrated Circuits provide the highest performance and efficiency for mass production of proofs (a key focus for networks like Succinct). Performance is measured in proof generation time and cost, which directly impacts transaction finality and fees.

To avoid centralization and single points of failure, projects are building decentralized prover networks.

• Permissionless Proving: Anyone with sufficient hardware can join the network to generate proofs and earn rewards.
• Proof Marketplaces: Platforms (e.g., GeVault, Succinct SP1) where proof generation tasks are auctioned to a network of provers.
• Incentive Models: Provers are typically incentivized with protocol tokens or fee sharing. This creates a competitive market for proof generation, improving robustness and censorship resistance.

The prover is a critical economic and security actor in a validity-proof system.

• Cost Bearer: The prover incurs the high computational cost of proof generation, which is offset by fees from users.
• Security Guarantee: A malicious prover cannot produce a valid proof for an incorrect computation. The system's security relies on the cryptographic soundness of the proof system, not the prover's honesty.
• Staking & Slashing: Some networks require provers to stake collateral (bond) that can be slashed if they submit faulty proofs or go offline.

A prover implementation integrates several sophisticated components:

• Arithmetization: Translates a program into a system of polynomial equations (a circuit).
• Polynomial Commitment Scheme (PCS): A cryptographic primitive (like KZG) used to commit to polynomials in the proof.
• FRI Protocol: Used in STARK proofs for low-degree testing.
• Groth16 / Plonk / Halo2: Specific SNARK constructions with different trust setups and performance profiles.
• Recursive Proofs: A technique where a prover generates a proof that verifies other proofs, enabling aggregation and scaling.

The cryptographic counterpart to a prover. A verifier is a smart contract or program that receives a proof and verifies its correctness with minimal computational effort. Its role is to check the proof's validity, not to recompute the underlying computation.

• Function: Executes a lightweight verification algorithm.
• Location: Typically deployed on-chain (e.g., Ethereum L1).
• Outcome: Accepts or rejects the prover's claim, enabling trustless state updates.

A node that orders transactions before they are proven. The sequencer batches user transactions, executes them to generate a new state root, and submits this data (and sometimes a proof) to a base layer.

• Role: Provides liveness and determines transaction order.
• Output: Produces a state delta or rollup block.
• Relationship to Prover: The sequencer's output is the input for the proving circuit; it creates the execution trace that the prover must attest to.

A programmatic representation of a computation, encoded as a set of mathematical constraints. This is the code that the prover executes to generate a proof.

• Formalization: Converts program logic into a system of polynomial equations.
• Prover's Input: Takes a witness (private computation data) and public inputs.
• Output: Generates a proof that the witness satisfies all circuit constraints without revealing it.

The set of private inputs and intermediate variables that satisfy the constraints of a ZK circuit. The witness is the prover's secret knowledge.

• Content: Includes private user data, transaction details, and internal state transitions.
• Role: Serves as the solution to the circuit's equations.
• Key Property: The prover uses the witness to generate a proof, but the witness itself is never revealed to the verifier.

The cryptographic output generated by a prover. A validity proof (or ZK proof) is a succinct piece of data that attests to the correct execution of a program, as defined by a ZK circuit.

• Types: Includes ZK-SNARKs, ZK-STARKs, and Bulletproofs.
• Property: Allows a verifier to be convinced of the proof's truth with near-certainty.
• On-Chain Use: Submitted to a verifier contract to finalize state transitions on a base chain.

The underlying cryptographic protocol that defines how proofs are generated and verified. The proof system (e.g., Groth16, Plonk, STARK) provides the mathematical framework for the prover and verifier.

• Components: Includes a key generation phase, proving algorithm, and verification algorithm.
• Trade-offs: Different systems offer varying balances of proof size, verification speed, and trust assumptions (e.g., trusted setup).
• Prover's Tool: The prover is an implementation of a specific proof system's proving algorithm.