Proof of Validity

A Validity Proof is a cryptographic attestation that a state transition (e.g., a batch of transactions) was executed correctly according to the rules of the underlying Virtual Machine (VM). It is generated off-chain by a prover and verified on-chain by a verifier contract. This allows the blockchain to trust the result of complex computations without re-executing them, a key innovation for Layer 2 scaling.

These are the two primary cryptographic systems used to construct Validity Proofs.

• ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) are compact and fast to verify but require a trusted setup ceremony.
• ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge) are larger but offer post-quantum security and do not require a trusted setup. Both provide computational integrity and data privacy (zk-rollups).

The final, succinct proof is posted to the parent Layer 1 blockchain (e.g., Ethereum) and verified by a smart contract. This verification is computationally cheap and fast compared to re-executing the transactions, creating a cryptographic security bridge. The state root is only updated on L1 after the proof is verified, ensuring the rollup's state is as secure as the underlying L1.

Unlike Optimistic Rollups which have a fraud proof challenge period, systems using Proof of Validity are trustless by design. The cryptographic proof guarantees correctness instantly. Users do not need to trust the operator's honesty, only that the cryptographic primitives are secure. This eliminates the need for watchers to monitor for fraud and removes withdrawal delays.

For a Validity Proof to be meaningful, the input data (transaction data) must be available. Data Availability (DA) ensures anyone can reconstruct the state and generate proofs independently. Solutions include:

• Posting all data to L1 (zkRollup).
• Using a separate Data Availability layer or committee. Without available data, the system becomes a validium, which trades off some decentralization for lower costs.

The system relies on a clear separation of roles:

• Prover (Sequencer): Aggregates transactions, executes them off-chain, and generates the validity proof. This is computationally intensive.
• Verifier (Smart Contract): A lightweight on-chain program that checks the proof's mathematical validity. This role is passive and automated. This separation is what enables massive scalability while inheriting L1 security.

A foundational cryptographic primitive for Proof of Validity. zk-SNARKs allow a prover to convince a verifier that a statement is true without revealing any information beyond the statement's validity.

• Key property: Extremely small proof size and fast verification.
• Use case: Pioneered by Zcash for private transactions and is a core component of zkRollups like zkSync.

A validity proof system that improves upon zk-SNARKs by being post-quantum secure and not requiring a trusted setup.

• Key property: Relies on cryptographic hashes only, making it transparent. Proofs are larger but scale better with computation.
• Use case: Used by StarkNet and other validity rollups for scalable, transparent proving.

A Layer 2 scaling solution that bundles transactions and posts a validity proof (zk-SNARK or zk-STARK) to the base layer (e.g., Ethereum).

• Mechanism: All transaction execution happens off-chain. The proof cryptographically guarantees the correctness of the new state root.
• Examples: zkSync Era, StarkNet, Polygon zkEVM. These inherit the security of Ethereum's consensus for data availability and proof verification.

A type of validity rollup that maintains full EVM bytecode compatibility. They generate a validity proof for the execution of standard Ethereum smart contracts.

• Implementation: Circuits are designed to prove the correctness of EVM opcode execution.
• Benefit: Allows developers to deploy existing Solidity/Vyper contracts with minimal changes while leveraging the security and scalability of zk-proofs.

Universal or updatable proving systems that simplify the development of zk-applications.

• Plonk: Allows many different programs to use a single, universal trusted setup ceremony.
• Benefit: Reduces the complexity and security overhead of creating new zk-circuits, enabling broader developer adoption for custom logic.

The final, critical step where the validity proof is checked on-chain. A verifier smart contract on the base layer (L1) performs this check.

• Process: The contract receives the new state root and the proof. It runs a verification function; if it returns true, the state root is accepted.
• Result: This provides the cryptographic security guarantee that the off-chain execution was correct, enabling trustless bridging of assets back to L1.

A Proof of Validity is a succinct cryptographic argument that a state transition—such as processing a batch of transactions—was executed correctly according to the rules of the chain. It is generated by a prover and verified by a verifier. This shifts security from economic staking (Proof of Stake) to computational integrity, enabling trust-minimized bridging between execution and settlement layers.

In optimistic rollups, validity is assumed (optimistic). A fraud proof is a specific type of validity proof that is only generated and submitted if a state root is challenged. This system relies on a challenge period (e.g., 7 days) where any watcher can dispute invalid state transitions. Examples: Arbitrum One, Optimism.

• Pro: Lower computational overhead for provers.
• Con: Long withdrawal delays due to the challenge window.

ZK-Rollups use zero-knowledge proofs (ZKPs), specifically ZK-SNARKs or ZK-STARKs, as their validity proof. A ZK-proof is generated for every batch, cryptographically guaranteeing its correctness. The settlement layer only needs to verify the tiny proof, not re-execute transactions.

• Pro: Immediate finality and no withdrawal delays.
• Con: High computational cost for proof generation (prover overhead).
• Examples: zkSync Era, Starknet, Polygon zkEVM.

The Proof of Validity is published and verified on a settlement layer (e.g., Ethereum L1). This layer acts as the ultimate arbiter of truth. Critical to this process is Data Availability (DA)—the guarantee that the transaction data needed to reconstruct the state is published. Without DA, a valid proof cannot be verified or challenged. Modular designs often separate DA (e.g., Celestia, EigenDA) from settlement.

Generating validity proofs (especially ZKPs) is computationally intensive. This has led to the emergence of specialized prover networks (e.g., RiscZero, Succinct) that offer proof-generation as a service. The economic model involves prover fees paid by rollup sequencers. This creates a marketplace for proving power, separating the roles of block production and proof generation in the modular stack.

Proofs of Validity enable secure cross-chain communication. A light client on one chain can verify a validity proof from another, enabling trust-minimized bridges. Furthermore, shared settlement layers (like Ethereum) can secure multiple rollups by verifying their distinct validity proofs, creating a hub-and-spoke security model. This is foundational for sovereign rollups and modular interoperability.

A Sequencer is a node in a rollup network (like Optimism, Arbitrum, or a zkRollup) that orders transactions, batches them, and submits them to the base layer (L1). In a Proof of Validity rollup, the sequencer's batch is accompanied by a validity proof. It provides fast pre-confirmations and is often the first point of censorship resistance debate in rollup designs.

A State Diff is a compressed representation of the changes to the blockchain's state (e.g., account balances, contract storage) resulting from a batch of transactions. In Proof of Validity rollups, the validity proof cryptographically guarantees the correctness of this state diff. Publishing only the diff, rather than all transaction data, is a key scaling technique, though most zkRollups publish full calldata for data availability.

A Verifier Contract is a smart contract deployed on the base layer (e.g., Ethereum L1) whose sole function is to verify Validity Proofs. It contains the verification key and logic to check the cryptographic proof submitted by a rollup's prover. If the proof is valid, the contract accepts the new state root. This contract is the ultimate arbiter of state correctness in a zkRollup.