Throughput Benchmarking Across Various L2s

Throughput Benchmarking Across Various L2s

Introduction

With Ethereum’s mainnet facing scalability constraints, Layer-2 (L2) solutions have emerged to boost transaction
throughput while preserving security. Throughput benchmarking measures how many transactions per second (TPS)
these solutions can sustain under diverse conditions. This article provides a comprehensive analysis of L2 throughput
benchmarking methodologies, key performance metrics, and comparative results across leading rollups and zk-rollups.

Key Performance Metrics

  • Transactions Per Second (TPS): Peak vs sustained throughput under load.
  • Latency: Time from transaction submission to inclusion in a batch.
  • Finality Time: Time until transaction is irreversible on L1.
  • Gas Efficiency: Cost per transaction or per batch on L1.
  • Batch Size Frequency: Impact on throughput and state commitment cadence.

Benchmarking Methodologies

1. Synthetic Stress Tests

Simulate high concurrent loads using tools like ethload or custom
RPC scripts. Ideal for pushing TPS to limits but may not reflect real-world contract complexity.

2. Real-World Scenarios

Replay historical dApp patterns (DEX trades, NFT minting). Captures complex state transitions, varying payloads, and gas profiles.

3. Hybrid Approaches

Combine synthetic transfers with contract interactions to emulate a mixed workload. Provides more balanced insights.

Infrastructure Environment Considerations

  • Node Specifications: CPU cores, RAM, disk I/O. Many rollup nodes benefit from NVMe SSDs.
  • Network Conditions: Bandwidth, latency between sequencers and validators, and L1 RPC latency.
  • Client Implementations: Differences between standard clients (Geth, OpenEthereum) and bespoke rollup clients.
  • Configuration Tuning: Batch time intervals, max batch size, gas limits.

Comparative Performance Table

L2 Solution Avg TPS Peak TPS Finality Model
Arbitrum One 300–400 800 ~10 min Optimistic Rollup
Optimism 200–300 600 ~7 min Optimistic Rollup
zkSync Era 1,000–2,000 3,000 <2 min ZK-Rollup
Polygon zkEVM 2,000–4,000 6,000 <3 min ZK-Rollup
StarkNet 500–700 1,200 <5 min ZK-Rollup
Loopring 2,900–3,500 5,000 <1 min ZK-Rollup

Detailed Solution Profiles

Arbitrum One

Developed by Offchain Labs, Arbitrum relies on optimistic rollups with fraud proofs. Its sequencer batches transactions
every 1–3 seconds, posting calldata on Ethereum. Fraud window of ~1 week can delay L1 finality, but offers robust security.
Whitepaper.

Optimism

Backed by Optimism Collective, this L2 uses OVM (Optimistic Virtual Machine). Batches occur every 6 seconds, with a 7-day
fraud proof window. Optimism recently introduced Bedrock upgrade for performance and modularity.
Technical Roadmap.

zkSync Era

zkSync Era by Matter Labs offers ZK-EVM compatibility. Uses PLONK-based proofs aggregated off-chain, with periodic on-chain
verification. Fast finality (~1–2 minutes), minimal L1 calldata. Excellent gas efficiency.
Whitepaper.

Polygon zkEVM

Polygon’s zkEVM implements EVM-equivalent ZK-rollup using zkEVM circuits. Supports existing Ethereum tooling and
smart contracts without modification. Finality under 3 minutes and competitive fees.
Documentation.

StarkNet

StarkWare’s ZK-rollup uses STARK proofs for large batch sizes. Emphasizes prover efficiency and scalability for DeFi. Offers
Cairo language for smart contracts.
Whitepaper.

Loopring

Loopring focuses on order-book DEX throughput, achieving >3,000 TPS using ZK proofs. Its design optimizes high-frequency
trades and AMM interactions within rollup batches.
Whitepaper.

Factors Influencing Throughput

  • Batch Interval: Longer intervals yield larger batches but increase latency.
  • Gas Limit Per Batch: Caps on L1 calldata size impose hard throughput ceilings.
  • Proof Generation: ZK-rollup prover speed vs optimistic fraud-proof challenge.
  • State Size: Larger state diffs require more calldata, affecting gas usage.
  • Network Topology: Sequencer→aggregator→validator hops add overhead.

Best Practices for Benchmarking

  1. Define clear workload profiles: transfers, swaps, NFT mints.
  2. Use multiple nodes in a distributed setup to avoid single-node bottlenecks.
  3. Vary RPC parallelism and batch sizes to find optimal configurations.
  4. Measure both peak and sustained TPS under realistic stake and calldata costs.
  5. Document environmental variables: hardware specs, network latency, client versions.

Conclusion

Throughput benchmarking across L2s reveals a spectrum of performance trade-offs. Optimistic rollups currently sustain
hundreds of TPS with moderate finality, while ZK-rollups push into the thousands of TPS with faster finality at higher
prover complexity. Careful benchmarking—tailored to specific workloads and infrastructure—remains essential for selecting
the right L2 for your dApp’s performance and security needs.

For up-to-date statistics and deeper insights, visit L2Beat and
the official Ethereum L2 Documentation.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *