Validity Proof

A zkEVM (Zero-Knowledge Ethereum Virtual Machine) is not a proof type itself, but a critical application. It's a virtual machine that generates ZK-SNARK or ZK-STARK proofs for general Ethereum smart contract execution.

• EVM-equivalence: Aims to execute Ethereum bytecode identically.
• High complexity: Proving EVM opcodes is computationally intensive.
• Key for scaling: Enables ZK-rollups like zkSync Era, Scroll, and Polygon zkEVM.

Proof aggregation and recursion are techniques to combine multiple validity proofs into one.

• Recursive Proofs: A proof can verify the correctness of other proofs, creating a hierarchy.
• Aggregation: Many proofs are merged into a single, final proof for the root chain. This drastically reduces the on-chain verification cost and data footprint for rollups, enabling high throughput.

These are hybrid data availability models that use validity proofs. A Validium posts proofs on-chain but keeps data off-chain, while a Volition (like Starknet's) lets users choose per-transaction between rollup (data on-chain) and validium modes.

• Key Benefit: Extreme scalability and lower fees than pure rollups.
• Trade-off: Requires trusted data availability committees or proofs for data.
• Example: ImmutableX uses StarkEx in Validium mode for NFT trading.

Validity proofs are built on zero-knowledge proofs (ZKPs), specifically zk-SNARKs or zk-STARKs. These cryptographic primitives allow a prover (e.g., a sequencer) to generate a small proof that convinces a verifier (e.g., a smart contract on Ethereum) of the correctness of a computation without revealing the underlying data. The security reduces to the computational hardness of the underlying cryptographic assumptions (e.g., the discrete logarithm problem for SNARKs).

A critical security distinction is the requirement for a trusted setup ceremony. Some proof systems (e.g., early zk-SNARKs) require this one-time generation of public parameters, where if the ceremony's toxic waste is not destroyed, proofs can be forged. Modern systems like zk-STARKs and some zk-SNARKs (e.g., PLONK with universal setup) are designed to be transparent or have a universal setup, eliminating or reducing this trust assumption.

A validity proof alone does not guarantee data availability. While the proof verifies state transition correctness, users must be able to reconstruct the state. If transaction data is withheld (data withholding attack), users cannot prove ownership of assets or force exits. This is why validiums and volitions pair validity proofs with off-chain data availability solutions, creating a distinct trust model from zk-rollups which post all data to L1.

The entity generating the validity proof (the prover or sequencer) is typically a centralized service for performance reasons. This creates operational risks:

• Censorship: The prover can refuse to include transactions.
• Liveness Failure: If the prover halts, the chain may stall. Mitigations include prover decentralization initiatives, escape hatches (force-include mechanisms), and multi-prover systems.

Most validity-proof-based systems (zk-rollups, validiums) launch with upgradeable smart contracts controlled by a multi-sig or DAO. This allows for protocol improvements but introduces a trust assumption in the key holders, who could potentially upgrade the contract to malicious code. The security model evolves from purely cryptographic to social consensus as governance decentralizes. Timelocks and security councils are common risk-mitigation tools.

The security guarantee is finalized once the validity proof is verified on the base layer (L1). Key considerations:

• Verification Cost: The gas cost to verify the proof on L1, which impacts operational economics.
• Time to Finality: The delay between transaction execution and L1 proof verification, representing the window for potential reorganization or challenge (in optimistic models, this is much longer).
• Recursion: Using proofs to verify other proofs, enabling scalability of the verification step itself.

A smart contract deployed on a Layer 1 blockchain (like Ethereum) whose sole purpose is to verify the cryptographic validity proof submitted by a Layer 2 prover. It is the ultimate arbiter of state correctness.

• Function: Takes the proof and public inputs as parameters and executes a fixed verification algorithm. If it returns true, the proposed state transition is accepted.
• Critical Role: This on-chain contract is the security anchor, ensuring the L1 can trust the L2's execution without re-running it.

A cryptographic proof used in Optimistic Rollups and certain sidechains to demonstrate that an invalid state transition has occurred. It is the security mechanism that corrects faulty assumptions.

• Process: Requires at least one honest node to monitor the chain, detect fraud, and submit a proof to trigger a rollback.
• Contrast with Validity Proof: Fraud proofs are dispute-driven (only computed if needed), while validity proofs are always computed to prove correctness proactively.

A validity proof that verifies other proofs, enabling the aggregation of multiple proofs into a single, succinct proof. This is a powerful technique for scaling proof systems themselves.

• Application: Allows zk-Rollups to prove the validity of an entire day's batches with one final proof, drastically reducing the on-chain verification cost per transaction.
• Benefit: Enables incremental verifiability and is key to building hierarchical proof structures for massive scalability.