Abstract
This article examines the architectural differences between optimistic rollups and zk-rollups, analyzing their respective security assumptions, latency, and gas cost implications. It provides benchmark data on transaction throughput and finality times for leading implementations, offering guidance for choosing the appropriate layer-2 solution based on application requirements.

Introduction

As Ethereum and other smart-contract platforms face scalability challenges, layer-2 rollup solutions have emerged to increase throughput while maintaining security guarantees rooted in layer-1. Two dominant paradigms have crystallized: Optimistic Rollups, which assume transactions are valid by default and rely on fraud proofs to challenge invalid ones; and zk-Rollups, which generate succinct zero-knowledge proofs (ZKPs) attesting to transaction correctness. Both approaches batch multiple transactions off-chain, post data or proofs on-chain, and settle state changes periodically. However, they differ in security models, latency-to-finality, gas costs, and implementation complexity. This article compares optimistic and zk-rollup architectures across key dimensions and presents benchmark data for leading implementations as of late 2021.

1. Optimistic Rollups

Optimistic rollups (ORUs) function under the assumption that most batch submissions are honest. Instead of verifying every transaction on-chain, they post only the rollup’s state root and transaction calldata, trusting its correctness unless a participant submits a fraud proof during a designated challenge window (typically 1–7 days).

1.1 Security Assumptions

1. Honest Majority of Sequencers/Operators: ORUs rely on at least one honest observer (watcher) to monitor batched state transitions. If the sequencer submits an invalid state root, watchers can publish a fraud proof before the challenge window expires.
2. Fraud-Proof Mechanism: Fraud proofs are generated by executing disputed transactions on-chain or in a verifier contract to demonstrate a disagreement with the posted state root.
3. Economic Incentives: Watchers are economically motivated to post fraud proofs (bounties/slashable bonds), and sequencers risk losing bonds or deposits if proven dishonest.

1.1.1 Example: Optimism

• State Commitment: Each rollup batch includes a Merkle root of all transactions (calldata) and the new state root.
• Challenge Window: Seven-day challenge period during which anyone can submit a fraud proof.
• Fraud Proof Execution: On detection of a mismatch between posted state and replayed state, the sequencer’s stake (or a bond) is slashed, and the invalid batch is rolled back.

1.2 Latency and Finality

• Submission Latency: Sequencers can post batches every few seconds or minutes, aggregating hundreds of transactions per batch.
• Challenge Window Latency: Funds and state changes only become final after the challenge window passes. For a 7-day window, finality is effectively 7 days + propagation delay.
• Circuitous Withdrawals: If a user withdraws funds from the rollup back to layer-1, they must wait until the challenge period ends before the withdrawal is claimable, adding significant sorting time.

1.3 Gas Cost Implications

• On-Chain Data Posting: ORUs post full calldata (transaction data) on-chain for each batch. Gas cost per batch scales roughly linearly with the number and size of transactions.
• Minimal Verification Costs: Since on-chain verification is limited to state root updates and fraud-proof verification only in exceptional cases, per-transaction gas costs are low relative to layer-1.
• Typical Gas Metrics (Optimism Mainnet, Late 2021):
  • Batch Posting Cost: ~500,000–1,000,000 gas per batch (1,000–2,000 transactions).
  • Gas per Transaction (amortized): ~500–1,000 gas.

1.4 Throughput

• Transactions per Second (TPS):
  • Optimism achieves ≈500–2,000 TPS under typical conditions, depending on block times and batch sizes.
• Bottlenecks:
  • Sequencer processing time, transaction propagation, and on-chain posting throughput (constrained by L1 gas limits).

2. zk-Rollups

zk-Rollups utilize zero-knowledge proofs to cryptographically prove the correctness of batched state transitions. Each batch submission includes a succinct ZKP (e.g., SNARK) that attests to the validity of all transactions in the batch. The layer-1 contract verifies the proof and accepts the state root update unconditionally—no challenge window is required.

2.1 Security Assumptions

1. Soundness of ZKP Schemes: The integrity of zk-rollups hinges on the cryptographic assumptions underpinning the proof system (e.g., knowledge-of-exponent, discrete-log hardness, etc.).
2. Trusted Setup (Optional): Some ZKP frameworks (e.g., Groth16) require a trusted setup; others (e.g., PLONK, Sonic) use universal setups. The security model depends on whether the setup remains uncontested.
3. Verifier Contract: On-chain verifier executes constant-time pairing checks (or equivalent) to validate proofs, eliminating reliance on watchers or challenge windows.

2.1.1 Example: zkSync

• zkSNARK-Based: zkSync (v1) uses PLONKish SNARK with a universal trusted setup.
• On-Chain Verification: Each batch proof is verified through ~3–4 pairing operations (~2 million gas).
• No Challenge Window: State root updates are final immediately upon proof verification.

2.2 Latency and Finality

• Submission Latency: Prover must generate a ZKP for each batch. Depending on circuit complexity and proving technology, generating a proof for 1,000–5,000 transactions can take 10–60 seconds on optimized hardware.
• Immediate Finality: Upon on-chain verification (∼2 million gas cost), the new state is final. There is no waiting period.
• Withdrawals: Users can withdraw funds instantly (with on-chain proof verification), reducing settlement time to minutes rather than days.

2.3 Gas Cost Implications

• Proof Verification Cost:
  • zkSNARK verification typically costs ~2 million gas per batch (3–4 pairings at ~0.5M gas each).
• Calldata Compression:
  • zk-rollups post compressed calldata (only essential state diff data), often using sparse Merkle proofs to show which accounts changed. Calldata per transaction is minimized (∼100–200 bytes), reducing gas costs.
• Typical Gas Metrics (zkSync, Late 2021):
  • Batch Verification Cost: ~2,000,000 gas per batch (1,000–2,000 transactions).
  • Gas per Transaction (amortized): ~1,000–2,000 gas, depending on transaction type and calldata size.

2.4 Throughput

• TPS Constraints:
  • Limited by prover throughput: generating ZK proofs for large batches is computationally intensive.
  • Hardware acceleration (GPUs, dedicated ASICs) can boost prover speed, achieving 1,000–2,000 TPS.
• Scaling Approaches:
  • Parallel Provers: Using multiple independent proving nodes generating proofs concurrently.
  • Recursive SNARKs: Nesting proofs for incremental updates to reduce proving time. Still an emerging optimization in 2021.

3. Comparative Benchmark Data

Below is a summary of benchmark data for representative optimistic and zk-rollup implementations as of November 2021. Note that actual performance depends on hardware, network conditions, and implementation optimizations.

Metric	Optimistic (Optimism Mainnet)	zk-Rollup (zkSync v1)
Batch Size	1,000–2,000 txns	1,000–1,500 txns
Batch Posting Gas (on-chain calldata)	500,000–1,000,000 gas	150,000–300,000 gas (compressed)
Proof Verification Gas	N/A (only fraud proofs rare)	~2,000,000 gas per batch
Gas per Transaction (amortized)	~500–1,000 gas	~1,000–2,000 gas
Verifier Latency to Finality	7-day challenge window	~1–2 minutes (block confirmation + proof)
Prover Throughput (batch proving time)	N/A	~30–60 seconds per batch
Transactions Per Second (achievable TPS)	500–1,500 TPS	500–1,000 TPS
Withdrawal Settlement Time	~7 days	~5–10 minutes

Note: Fraud-proof-related gas costs on optimistic rollups are incurred only when invalid batches are challenged—rare under normal operation.

4. Trade-Off Analysis

4.1 Security vs. Liveness

• Optimistic Rollups:
  • Security Model: Security ultimately depends on the correct submission of fraud proofs during the challenge window. If all watchers are offline or censored, malicious batches may finalize undetected for the period.
  • Liveness Model: Users can continue transacting even if a dishonest sequencer attempts invalid batches, as challengers (watchers) can correct invalid state. However, funds are locked until the challenge window passes.
• zk-Rollups:
  • Security Model: Relies on cryptographic soundness of ZKP scheme. No human intervention is needed to detect invalid state—on-chain verification ensures correctness.
  • Liveness Model: Proof generation must complete for batch finality. If proof generation lags or fails, batch submission stalls. However, once proof is verified, state is final.

4.2 Latency vs. Cost

• Optimistic Rollups:
  • Low On-Chain Gas Cost: Posting full calldata is cheaper than verifying ZK proofs.
  • High Finality Latency: Long challenge windows increase settlement delays.
• zk-Rollups:
  • High On-Chain Gas Cost (Proof Verification): Verifying ZK proofs consumes millions of gas.
  • Low Finality Latency: Immediate finality once proof is verified, enabling rapid cross-chain transfers and withdrawals.

4.3 Prover Complexity vs. User Experience

• Optimistic Rollups:
  • Prover (Sequencer) Simplicity: Doesn’t require ZKP generation; simply executes transactions and posts calldata.
  • User Experience: Funds locked for challenge window—users must wait days to withdraw.
• zk-Rollups:
  • Prover (Sequencer) Complexity: Requires significant computational resources to generate ZK proofs, often needing dedicated hardware.
  • User Experience: Near-instant withdrawals once proof is verified, improving usability for live applications.

5. Use Case Guidance

Choosing between optimistic and zk-rollups depends on application requirements:

1. High-Frequency Trading / DeFi Protocols:
   • Priority: Fast finality, minimal withdrawal delay.
   • Recommendation: zk-Rollups (e.g., zkSync, StarkNet) provide immediate settlement, critical for instant arbitrage or liquidations.
2. NFT Marketplaces / Game Items:
   • Priority: Low transaction cost, moderate finality tolerance (hours to days acceptable).
   • Recommendation: Optimistic Rollups (e.g., Optimism, Arbitrum) reduce gas expenses and leverage simpler infrastructure.
3. Privacy-Preserving Payments:
   • Priority: Confidentiality, fast withdrawals.
   • Recommendation: zk-Rollups readily integrate privacy layers (e.g., zk-SNARK circuits) and finalize instantly.
4. Cross-Chain Bridges:
   • Priority: Security against fraud, no long periods of locked funds.
   • Recommendation: zk-rollup-based bridges ensure validity proofs; optimistic bridges may introduce multi-day delays for dispute resolution.

6. Future Directions

Both optimistic and zk-rollup technologies continue evolving:

• Hybrid Rollups: Combining optimistic batching with periodic ZKP verification to shorten challenge windows or enable faster dispute resolution.
• Recursive ZK Proofs: Reducing prover overhead by aggregating proofs recursively, enabling larger batch sizes with faster proof times.
• Optimized Fraud-Proofs: Research on succinct fraud proofs (e.g., “fraud-SNARKs”) to minimize on-chain cost and expedite invalid-batch challenges.
• Layer-2 Interoperability: Standards for cross-rollup communication to allow seamless asset transfers and composability between different rollup types.

7. Conclusion

Optimistic rollups and zk-rollups offer complementary trade-offs in scaling Ethereum and similar blockchains. Optimistic rollups excel in low on-chain costs and simpler prover infrastructure but incur multi-day finality delays. zk-Rollups provide immediate security via cryptographic proofs at the expense of higher gas costs and complex proving. Application requirements—such as latency tolerance, security guarantees, and user experience—should guide developers in selecting the appropriate layer-2 architecture. As both paradigms advance, hybrid approaches and improved proof systems will further close gaps, driving widespread adoption of scalable, secure layer-2 solutions.

References

1. Buterin, V. (2021). “On Layer 2 Scalability.” Ethereum Research.
2. Carroll, M., et al. (2019). “Optimistic Rollup: Scaling Ethereum with Fraud Proofs.” Offchain Labs Whitepaper.
3. Ben-Sasson, E., Bentov, I., Horesh, Y., & Riabzev, M. (2019). “Scalable, Transparent, and Post-Quantum Secure Computational Integrity.” Cryptology ePrint Archive, Report 2018/046.
4. “zkSync: Scalable Lightning-Fast Ethereum Payments.” (2021). Matter Labs Whitepaper.
5. “StarkWare: Validity Rollups (Vol. 1).” (2021). StarkWare Industries Whitepaper.
6. “Arbitrum Rollup.” (2021). Offchain Labs Documentation.
7. “Optimism: Optimistic Ethereum.” (2021). Optimism PBC Technical Documentation.
8. Goldfeder, S., Kalodner, H., Reisman, D., & Narayanan, A. (2018). “When the Levee Breaks: Quantifying the Practical Decentralization of Bitcoin Core.” IEEE Symposium on Security and Privacy.