L2 Rollups: Optimistic and ZK, Data Availability

1) Why rollups?

• Cost and throughput: Many user transactions are executed off the base chain then compressed into a single post, amortizing gas.
• Security inheritance: If the base chain can verify the summary or allow credible dispute, users keep base layer security.
• Developer ergonomics: Most rollups expose familiar EVM tooling, keeping contracts and wallets unchanged or close to unchanged.

2) How rollups work (high level)

1. Users submit transactions to an L2 node called a sequencer.
2. The sequencer orders and executes them, producing a new L2 state root and a batch of data.
3. A commitment (state root and batch metadata) plus transaction data are posted to L1 for data availability.
4. A proof system (fraud or validity) connects L2 execution to L1 verification.

// Conceptual posting flow
for each batch:
  execute(tx...);    // off L1
  root' = stateRoot; // after execution
  postToL1({root', dataRef, proofOrClaim});

3) Optimistic rollups and fraud proofs

Optimistic rollups (for example, Arbitrum, Optimism, Base) assume batches are valid once posted. A challenge window
(minutes to days depending on chain and upgrade stage) lets anyone submit a fraud proof demonstrating misexecution.
If the challenger wins, the batch is rejected and the dishonest party’s bond is slashed.

• Interactive vs single step: Many systems use multi round bisection to isolate a single faulty step, keeping L1 costs low.
• Data access requirement: A challenger must reconstruct the disputed execution, which in turn requires the batch data to be available.
• Withdrawal delay: Native withdrawals wait for the challenge window to close to prevent releasing funds from a potentially invalid state.

// Optimistic exit (concept)
user.initiateWithdraw(l2Token, amt);
wait(CHALLENGE_WINDOW); // disputes can occur here
l1Bridge.finalizeWithdraw(proof);

Strengths: EVM parity is excellent today, costs are low, and developer tooling is mature.
Trade offs: delayed exits and reliance on at least one honest challenger with access to the data.

4) ZK rollups and validity proofs

ZK rollups (for example, zkSync, Starknet, Scroll, Polygon zkEVM) generate a validity proof that the batch obeyed the rules.
Ethereum verifies the proof in a short on chain check. Once accepted, the new state is final under the base chain’s finality assumptions; there is no separate
challenge window for withdrawals.

• Proof systems: SNARK based systems offer tiny proofs and fast verification; STARK based systems avoid trusted setup with larger proofs and different verification costs.
• Aggregation: Provers often aggregate many batches into one proof to amortize cost further.
• EVM equivalence: ZK EVMs vary: some compile Solidity to a ZK friendly IR, others target full bytecode equivalence. Check precompile support and edge cases.

// ZK exit (concept)
user.initiateWithdraw(l2Token, amt);
prover.submitProof(batch);
require(verify(proof), "invalid");
l1Bridge.finalizeWithdraw(proof);

Strengths: fast finality and withdrawals, powerful for payments, privacy friendly building blocks.
Trade offs: prover complexity and costs, and some feature gaps while EVM equivalence matures.

5) Data availability: L1, blobs, alt DA, validium

Verifying correctness is not enough; the community must be able to reconstruct L2 state to challenge or to run independent nodes. That requires the batch data to be
available somewhere reliable.

• L1 calldata: Highest assurance because bytes live on Ethereum forever. Most expensive.
• Blobspace (EIP 4844): Cheap, ephemeral data slots validated with KZG commitments.
  Blobs drastically reduce fees but are retained for a limited window. For long horizon auditability, many projects additionally replicate data to archival layers.
• Alt DA networks: Systems such as Celestia or EigenDA provide cheaper availability with their own security models
  (sampling, committees, or restaked operators). You gain scale and cost but accept the DA network’s failure modes.
• Validium and volition: Keep execution proofs on chain but store data off chain or give users a choice per transaction.
  You get even lower costs at the price of stronger availability assumptions.

6) Bridging and withdrawal times

• Canonical bridges: Native L2 to L1 bridges obey the rollup’s security model. Optimistic exits respect the challenge window; ZK exits can finalize when proofs verify.
• Fast liquidity bridges: Routers front funds on the destination chain and later settle with the canonical bridge. You trade time for extra smart contract and liquidity risk.
• Message vs asset bridges: Some bridges pass arbitrary messages that your app consumes. Keep message authentication separate from business logic and fail closed on verification errors.
• Force inclusion and forced withdrawals: Robust rollups offer ways to post a transaction directly to L1 if the sequencer censors you, and to exit even during outages.

7) Risks, decentralization, and escape hatches

• Sequencers: Most ecosystems still run a single sequencer. Roadmaps include shared sequencers, proposer builder separation like designs, and inclusion guarantees.
• Admin control: Early stage rollups rely on multisigs for upgrades and emergency pauses. Look for timelocks, public ceremonies, and published key rotation plans.
• Prover and verifier bugs: ZK circuits and on chain verifiers are complex. Audits, formal methods, and bug bounty programs matter.
• DA failures: If your DA layer halts or withholds, challengers cannot reconstruct state. Understand liveness assumptions and what “recovery” means in practice.
• Compatibility edges: Precompiles, gas costs, and trace semantics can differ. Test libraries that depend on opcodes or gas sensitive patterns.

8) Picking an L2 for your app

Quick check

1. Why does a challenger need data availability in an Optimistic rollup?
2. What is the user visible difference between Optimistic and ZK exits?
3. List two trade offs of using an alternative data availability layer.
4. Name one escape hatch that improves censorship resistance.

Further resources

• Ethereum.org — Rollups overview
• OP Stack and Arbitrum Nitro — architecture documentation
• zkSync, Starknet, Scroll, Polygon zkEVM — prover and zkEVM documentation
• EIP 4844 (Proto Danksharding) — blobspace for cheaper L2 data
• Celestia and EigenDA — alternative data availability networks
• Want structured training? Try Cyfrin Updraft for end to end smart contract courses.