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
- Define clear workload profiles: transfers, swaps, NFT mints.
- Use multiple nodes in a distributed setup to avoid single-node bottlenecks.
- Vary RPC parallelism and batch sizes to find optimal configurations.
- Measure both peak and sustained TPS under realistic stake and calldata costs.
- 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.
Leave a Reply