Zero-Knowledge Proofs in L2 Rollups: zk-SNARKs vs zk-STARKs Mathematical Architecture

1. Arithmetization: Translating Computation to Polynomial Equations

Zero-Knowledge Proofs allow a Prover to convince a Verifier that a specific computational statement is mathematically valid without revealing private inputs (witness). In Layer-2 zk-Rollups (such as zkSync Era, Scroll, Starknet, and Polygon zkEVM), every state transition executed by smart contracts is compiled into arithmetic circuits.

The process begins with Arithmetization: converting execution traces into constraint systems such as R1CS (Rank-1 Constraint Systems) or AIR (Algebraic Intermediate Representation). The prover constructs low-degree polynomials that evaluate to zero across constraint evaluation domains if and only if every execution step followed EVM opcode semantics.

By evaluating these polynomials at randomized challenge points using the Schwartz-Zippel Lemma, the verifier can verify millions of computation steps in sub-second verification times.

// Rust: Simple R1CS Constraint Enforcement Example (Arkworks)
use ark_relations::r1cs::{ConstraintSynthesizer, ConstraintSystemRef, SynthesisError};
use ark_ff::PrimeField;

struct MultiplierCircuit {
    a: Option,
    b: Option,
}

impl ConstraintSynthesizer for MultiplierCircuit {
    fn generate_constraints(self, cs: ConstraintSystemRef) -> Result<(), SynthesisError> {
        let a_var = cs.new_witness_variable(|| self.a.ok_or(SynthesisError::AssignmentMissing))?;
        let b_var = cs.new_witness_variable(|| self.b.ok_or(SynthesisError::AssignmentMissing))?;
        let c_var = cs.new_input_variable(|| {
            let mut res = self.a.ok_or(SynthesisError::AssignmentMissing)?;
            res.mul_assign(&self.b.ok_or(SynthesisError::AssignmentMissing)?);
            Ok(res)
        })?;
        
        // Enforce: a * b = c
        cs.enforce_constraint(a_var.into(), b_var.into(), c_var.into())?;
        Ok(())
    }
}

2. Polynomial Commitment Schemes: KZG (SNARKs) vs FRI (STARKs)

The core architectural distinction between zk-SNARKs and zk-STARKs lies in their Polynomial Commitment Schemes (PCS), which determine proof size, verification complexity, and cryptographic security foundations.

zk-SNARKs (e.g. Groth16, PlonK, Halo2) predominantly utilize KZG (Kate-Zaverucha-Goldberg) commitments based on bilinear pairings over elliptic curves (such as BN254 / BLS12-381). KZG produces constant-size proofs (~200 bytes) and constant-time pairing checks, making them extremely cost-effective for Ethereum L1 on-chain verification (~200,000 gas). However, KZG requires a trusted setup ceremony and is vulnerable to future quantum computing attacks.

zk-STARKs utilize FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity) based entirely on collision-resistant cryptographic hash functions (such as Poseidon, Rescue, or Keccak-256). STARKs require zero trusted setups (fully transparent) and provide post-quantum security guarantees, though raw proof sizes are larger (50KB-100KB).

// Mathematical Comparison: Proof Size & Gas Complexity
// -------------------------------------------------------------
// Property               zk-SNARK (PlonK/KZG)    zk-STARK (FRI/AIR)
// -------------------------------------------------------------
// Proof Size             ~200 - 400 bytes        ~50 - 100 KB
// L1 Verification Cost   ~200k - 300k gas        ~1.5M - 3M gas
// Trusted Setup          Required (Ceremony)     Transparent (No Setup)
// Quantum Resistance     No (Elliptic Curves)    Yes (Hash-Based)
// Prover Memory Scaling  O(N log N) Elliptic     O(N log^2 N) Hash Fast

3. Recursive Proof Composition & zkEVM Scaling

Directly verifying individual transaction proofs on Ethereum L1 remains too expensive for high-frequency trading applications. Modern rollups solve this through Recursive Proof Composition: a zero-knowledge circuit that takes multiple child proofs as inputs and outputs a single aggregated proof verifying the validity of all children.

In systems like STARK-to-SNARK wrappers (used in Starknet and Polygon zkEVM), massive computation is initially proven using ultra-fast STARK provers off-chain, and the resulting STARK proof is recursively proven inside a final compact PlonK/KZG SNARK circuit to minimize L1 verification gas costs.

// Rust: Recursive Proof Verification Circuit Outline
fn verify_and_aggregate_proofs(
    proofs: &[Proof],
    public_inputs: &[Vec],
    vk: &VerifyingKey
) -> Result, SynthesisError> {
    println!("[ZK PROVER] Aggregating {} sub-proofs recursively...", proofs.len());
    // Verify pairing equations inside recursive circuit
    let aggregated = synthesize_recursive_snark_tree(proofs, public_inputs, vk)?;
    Ok(aggregated)
}

4. L1 Solidity Verifier Contract Deployment & Benchmarks

On Ethereum Layer 1, the rollup state is finalized by invoking a Verifier contract that checks the validity proof against the previous state root and new state root.

Utilizing Ethereum precompiled contracts for elliptic curve addition (alt_bn128 ecAdd at 0x06), scalar multiplication (ecMul at 0x07), and pairing checks (ecPairing at 0x08), Solidity verifiers achieve cryptographic finality within a single transaction call.

// Solidity: BN254 Pairing Precompile Invocation
pragma solidity ^0.8.24;

contract ZkSnarkVerifier {
    function verifyPairing(
        uint256[2] memory a,
        uint256[2][2] memory b,
        uint256[2] memory c,
        uint256[2][2] memory gamma
    ) public view returns (bool) {
        bytes memory input = abi.encodePacked(a[0], a[1], b[0][1], b[0][0], b[1][1], b[1][0], c[0], c[1], gamma[0][1], gamma[0][0], gamma[1][1], gamma[1][0]);
        uint256[1] memory out;
        bool success;
        assembly {
            success := staticcall(gas(), 0x08, add(input, 0x20), mload(input), out, 0x20)
        }
        return success && out[0] == 1;
    }
}

Written by Zyekh Abdul Qadir Jailani

Digital Forensics & Incident Response (DFIR) Specialist & Security Researcher specializing in Linux kernel hardening, threat hunting, and system security research.

LinkedIn • GitHub • Discord • Security Policy • PGP Key