ZK-Rollup

Matter Labs' production ZK-Rollup utilizing a custom SNARK-based proof system called Boojum. It achieves EVM compatibility through a compiler that translates Solidity bytecode into zkEVM circuits, rather than native bytecode execution.

• Proof System: PLONK-based with recursive aggregation
• Data Availability: On-chain (Ethereum L1)
• Finality: Near-instant with proof generation taking ~1-3 minutes
• Key Differentiator: Native account abstraction at the protocol level

StarkWare's permissionless ZK-Rollup built on the Cairo VM and STARK-based proofs. Unlike zkEVM approaches, StarkNet uses a custom Cairo language that compiles to an algebraic intermediate representation optimized for STARK proving.

• Proof System: STARK with FRI protocol
• Post-Quantum Security: Inherent from hash-based STARK construction
• Execution Model: Cairo VM with Sierra intermediate representation
• Key Differentiator: No trusted setup required; recursive proof composition for L3 fractal scaling

A Type 2 zkEVM that achieves bytecode-level equivalence with Ethereum by proving execution of actual EVM opcodes. Uses a custom zero-knowledge assembly language (zkASM) to map EVM instructions to polynomial constraints.

• Proof System: Plonky2 (recursive STARK with SNARK final proof)
• Equivalence Level: Full opcode compatibility
• Proving Time: ~2 minutes per batch
• Key Differentiator: Open-source zkProver implementation with PIL (Polynomial Identity Language) for circuit definition

A Type 1 zkEVM pursuing full Ethereum equivalence at the bytecode level, proving native EVM execution traces directly. Uses a two-layer architecture with a proving layer generating validity proofs and a sequencing layer ordering transactions.

• Proof System: Halo2 with KZG commitments
• Equivalence Level: Full bytecode and state root compatibility
• Architecture: Decentralized prover network with GPU acceleration
• Key Differentiator: Minimal code changes required for existing Ethereum tooling and clients

Consensys' ZK-Rollup implementing a Type 2 zkEVM with a lattice-based prover called Vortex. Integrates directly with MetaMask and Infura infrastructure for developer onboarding.

• Proof System: Custom Vortex prover with PLONK arithmetization
• Execution Client: Besu-based with zkEVM modifications
• Finality: ~12 minutes to L1 finality
• Key Differentiator: Native integration with Consensys developer tooling ecosystem including Truffle and Diligence

A privacy-preserving ZK-Rollup that extends beyond scaling to provide programmable confidentiality. Uses a UTXO-based architecture with Noir, a Rust-like DSL for writing private smart contracts where both function logic and state remain encrypted.

• Proof System: Honk (UltraPlonk variant with lookup tables)
• Privacy Model: Default-private with selective disclosure
• Execution: Private execution on user device, public verification on network
• Key Differentiator: Combines ZK-Rollup scaling with programmable privacy, enabling confidential DeFi and identity applications

The foundational cryptographic primitive enabling ZK-Rollups. A ZKP allows a prover to convince a verifier that a batch of transactions was executed correctly without revealing the transaction data itself. In a rollup context, the proof attests to the validity of the state transition, and the Layer 1 contract only needs to verify this succinct proof rather than re-executing every transaction. This is the mechanism that achieves computational compression.

A Zero-Knowledge Succinct Non-Interactive Argument of Knowledge is the most widely deployed proof system in production ZK-Rollups. Key properties:

• Succinctness: Proof size is constant (often < 1KB) regardless of the number of transactions batched
• Non-interactive: The prover generates a single proof without back-and-forth communication
• Trusted Setup: Requires a one-time ceremony to generate a common reference string; if compromised, false proofs could be forged

Used by zkSync Era, Polygon zkEVM, and Scroll.

A Zero-Knowledge Scalable Transparent Argument of Knowledge offers an alternative to SNARKs with distinct trade-offs. STARKs rely on collision-resistant hash functions rather than bilinear pairings, eliminating the need for a trusted setup ceremony. Advantages include post-quantum security and faster proving times for large computations. The trade-off is larger proof sizes (typically 40-200KB vs. SNARKs' <1KB). StarkNet and StarkEx are the primary production deployments of STARK-based rollup technology.

A scaling architecture closely related to ZK-Rollups that makes a critical trade-off: transaction data is stored off-chain with a Data Availability Committee (DAC) rather than posted to Layer 1. This dramatically reduces costs but introduces a trust assumption—the DAC must remain honest and available. If the DAC withholds data, users cannot reconstruct the state to withdraw funds. Validium is best suited for high-throughput applications like gaming and social platforms where minimal fees are prioritized over full Layer 1 security guarantees.

A technique that allows light nodes to probabilistically verify that rollup transaction data has been published without downloading the entire data blob. The node randomly samples small chunks of the data; if enough samples are successfully retrieved, the node gains high statistical confidence that the full data is available. This is the core mechanism behind EIP-4844 (Proto-Danksharding) and the eventual full Danksharding roadmap, which aims to dramatically reduce the cost of posting ZK-Rollup data to Ethereum.

A technique where a ZK proof attests to the validity of one or more previous proofs, enabling proof aggregation. Instead of verifying N separate proofs on Layer 1, a rollup can recursively compose them into a single constant-size proof. This is critical for horizontal scaling: multiple parallel provers can generate proofs independently, and a final aggregator compresses them into one verification step. Recursive composition is the architectural backbone enabling ZK-Rollups to scale to millions of transactions per batch.