L09: Layer 2 & Scaling
The Bottleneck: Why Ethereum Cannot Scale on Its Own
01Ethereum Layer 1 processes approximately 15 transactions per second. Visa’s payment network handles around 65,000 TPS at peak capacity. That gap — more than four orders of magnitude — is the central engineering problem that Layer 2 solutions are designed to close. But the gap is not simply an implementation oversight that can be patched; it is a direct consequence of Ethereum’s foundational design choices.
Every full node on the Ethereum network must independently re-execute every transaction to verify correctness. This redundancy is what makes the chain trustless — no single node’s computation is taken on faith. But it creates a hard ceiling on throughput: the network can only process as many transactions as every node can verify in parallel. Increasing TPS at Layer 1 forces one of three painful trade-offs: larger blocks (which require expensive hardware and push out small operators, reducing decentralization), fewer validators (which shrinks the attack surface, reducing security), or keeping the status quo (which caps throughput at ~15 TPS, sacrificing scalability).
The consequences are tangible for users. During the 2021 NFT boom, gas fees on Ethereum reached $200 per transaction for minting. During the DeFi summer of 2020, a simple token swap could cost more in fees than the swap itself was worth for small portfolios. These fee spikes are not malfunctions — they are the market-clearing mechanism for a fundamentally constrained resource.
| Metric | Ethereum L1 | Visa | Arbitrum (L2) | zkSync Era (L2) |
|---|---|---|---|---|
| Transactions per second | ~15 TPS | ~65,000 TPS | ~4,000 TPS | ~2,000 TPS |
| Block/confirmation time | 12 seconds | Instant (settlement 1-3 days) | <2 seconds | <2 seconds |
| Average fee (2024) | $1–$15 | ~2% merchant fee | $0.01–$0.10 | $0.01–$0.05 |
| Censorship resistance | Yes | No | Yes (via L1) | Yes (via L1) |
| Permissionless access | Yes | No | Yes | Yes |
| Trust model | Algorithmic | Centralized | L1-anchored | L1-anchored |
Rollup Architecture: Execute Off-Chain, Verify On-Chain
02A rollup is a Layer 2 scaling solution that executes transactions off-chain while posting transaction data — or cryptographic proofs of those transactions — to Ethereum Layer 1. The name comes from the operation of “rolling up” hundreds of individual transactions into a single compressed batch, much like bundling 500 letters into one package for postal delivery.
The critical distinction between rollups and earlier L2 approaches (sidechains, payment channels) is the data availability guarantee: rollups post enough data to L1 that anyone, at any time, can reconstruct the L2 state from L1 alone. This means the rollup inherits Ethereum’s security properties. If the L2 operator disappears tomorrow, users can prove their balances and withdraw to L1 using only publicly available data.
The transaction lifecycle inside a rollup has five distinct phases. First, the user signs a transaction in their wallet and submits it to the rollup’s sequencer — a server (or set of servers) that orders and executes L2 transactions. The user receives a “soft confirmation” within seconds, comparable to a bank’s acknowledgment that a payment has been received. Second, the sequencer batches hundreds of transactions, compresses the resulting state changes, and posts the batch to Ethereum L1 as calldata or (after EIP-4844) as blob data. Third, either a fraud proof or a validity proof is used to verify correctness on L1. Once verified, the transactions receive “hard confirmation” with the full security of Ethereum finality.
Sequencer — Orders and executes transactions on the L2. Currently centralized on most rollups, creating a temporary trust assumption.
Prover — Generates fraud proofs (optimistic) or validity proofs (ZK) for L1 verification.
Bridge — Locks assets on L1 and mints equivalent tokens on L2; holds billions in locked value and is a prime attack target.
Optimistic vs ZK Rollups: Two Paths to Off-Chain Verification
03All rollups share the same fundamental architecture: execute off-chain, post data to L1, verify on L1. The critical design choice is how they prove that off-chain execution was correct. Two families have emerged, built on fundamentally different cryptographic assumptions — each with distinct trade-offs in cost, withdrawal time, and engineering complexity.
Optimistic rollups take the simpler approach: they assume all transactions are valid by default and submit batches without a proof. A challenge period — currently seven days on Arbitrum and Optimism — gives any observer time to submit a fraud proof if they detect an invalid state transition. If a fraud proof is submitted and verified, the malicious batch is rejected and the submitter is slashed. If no challenge arrives within seven days, the batch is finalized. The optimistic approach is called “innocent until proven guilty.”
ZK rollups take the opposite approach: they generate a cryptographic validity proof — a zero-knowledge proof (SNARK or STARK) — that mathematically certifies the entire batch was executed correctly. The L1 contract verifies the proof in a single on-chain call. No challenge period is needed. Withdrawals can be processed in minutes rather than days. The trade-off is engineering complexity: generating ZK proofs for general-purpose EVM computation requires specialized compilers and sophisticated cryptographic infrastructure that took years to build.
• Arbitrum Nitro: ~4,000 TPS, EVM-equivalent
• Optimism OP Stack: powers Base, Mode, Zora
• Base (Coinbase): ~2,000 TPS, institutional backing
Withdrawal time: 7 days via canonical bridge
Proof type: Fraud proofs (interactive bisection)
• zkSync Era: ~2,000 TPS, zkEVM compatible
• StarkNet: ~1,000 TPS, Cairo VM
• Polygon zkEVM: EVM-equivalent
Withdrawal time: Minutes (after proof generation)
Proof type: Validity proofs (SNARK/STARK)
| Property | Optimistic Rollup | ZK Rollup |
|---|---|---|
| Proof type | Fraud proof (post-hoc) | Validity proof (pre-hoc) |
| Challenge period | 7 days | None |
| Withdrawal time | 7 days (canonical bridge) | Minutes |
| EVM compatibility | Full (EVM-equivalent) | Partial (improving rapidly) |
| Proof generation cost | Low (no proof needed) | Higher (GPU/FPGA intensive) |
| On-chain verification cost | Higher (re-execution on fraud) | Fixed (proof verification) |
| Engineering complexity | Moderate | Very high |
| Security assumption | At least 1 honest observer online | Soundness of ZK proof system |
| Leading examples | Arbitrum, Optimism, Base | zkSync Era, StarkNet, Polygon zkEVM |
Sequencers, Data Availability, and EIP-4844
04Two infrastructure components determine whether a rollup achieves its security and cost promises in practice: the sequencer that orders transactions and the data availability layer that stores batch data. Getting either wrong leads to censorship, insolvency, or complete security failure.
The sequencer is the off-chain server that receives user transactions, orders them, and executes them against the L2 state before batching and posting to L1. Today, every major rollup runs a single centralized sequencer operated by the team — Offchain Labs for Arbitrum, OP Labs for Optimism, Coinbase for Base. Centralized sequencers create three risks: censorship (the operator can refuse to include certain transactions), MEV extraction (the operator can reorder transactions for profit at users’ expense), and single point of failure (if the sequencer goes down, users must fall back to costly L1 transactions). All major rollup teams are working on decentralized sequencer designs, but none have fully shipped at scale as of 2024.
Data availability (DA) is perhaps the most underappreciated concept in rollup security. For a rollup to be trustless, the transaction data that the sequencer posts to L1 must be publicly accessible for long enough that any observer can reconstruct the L2 state and compute fraud proofs or verify ZK proofs. If the data disappears — even briefly — a malicious sequencer could post an invalid state root and no one could prove it was wrong.
Before March 2024, rollups posted their data as Ethereum calldata — data permanently stored on-chain. Calldata is the most secure DA option (it lives on L1 forever) but also the most expensive, because it competes with smart contract execution for the same block space.
EIP-4844, activated on Ethereum in March 2024 as part of the Dencun upgrade, introduced blob-carrying transactions. Blobs are a new data type that attaches up to 128 KB of data per blob to a block, with separate pricing from calldata. Blobs are designed to be stored by nodes for only ~18 days before being pruned — long enough for fraud proof windows but cheap enough to reduce L2 data costs by 80–90%.
State channels represent an alternative scaling approach for specific use cases. Rather than posting data to L1 for every batch, two parties lock funds in an L1 smart contract, conduct unlimited off-chain transactions by exchanging signed state updates, and only settle the final state on L1 when they close the channel. The Lightning Network for Bitcoin is the most prominent example. State channels achieve near-zero fees and instant finality for the parties involved, but require participants to be online to dispute fraudulent channel closures and only work well for repeated interactions between known parties — they cannot support the general-purpose DeFi composability that rollups enable.
Bridges and the Security Risks of Cross-Chain Infrastructure
05Bridges are the connective tissue of the multi-chain ecosystem: they allow assets to move between Layer 1, Layer 2 rollups, and alternative blockchains. They are also, by a large margin, the most exploited infrastructure in crypto history. Between 2021 and 2023, bridge hacks resulted in over $2.5 billion in losses — including the Ronin bridge hack ($625M), Wormhole ($320M), Nomad ($190M), and the Harmony Horizon bridge ($100M). Understanding why bridges are dangerous requires understanding how they work.
Bridge security exists on a spectrum. At the most trustless end sit native canonical bridges — the official bridge contracts deployed by rollup teams themselves. The Arbitrum canonical bridge is secured by the rollup’s fraud proof mechanism: assets are only unlocked on L1 after the 7-day challenge period. The zkSync canonical bridge verifies validity proofs on L1 before releasing funds. These bridges inherit the rollup’s security guarantees. The trade-off is the withdrawal delay (seven days for optimistic rollups) and a lack of general cross-chain routing.
Third-party cross-chain bridges — Wormhole, LayerZero, Stargate, Across — offer faster withdrawals and routing between arbitrary chains by introducing their own security model: a set of validators or relayers that attest to the state of the source chain on the destination chain. The security reduces to the honesty and competence of this validator set. If validators collude or a private key is compromised, all locked assets are at risk. The Wormhole hack exploited a signature verification bug; the Ronin hack compromised five of nine validator keys through a social engineering attack on Axie Infinity team members.
| Bridge Type | Security Model | Withdrawal Time | Historical Losses | Best Use Case |
|---|---|---|---|---|
| Native rollup bridge | L1 fraud/validity proofs | 7 days / minutes | Near zero | L1 ↔ single L2 |
| Liquidity network | LP slippage + rebalancing | Minutes | Low | Fast withdrawals |
| External validator bridge | Multisig validator set | Minutes | High ($2.5B+ losses) | Multi-chain routing |
| Light client bridge | On-chain proof verification | Hours | Very low | Trust-minimized cross-chain |
The L2 Ecosystem: TVL, Adoption, and Market Structure
06The Layer 2 ecosystem grew from a technical prototype to a multi-billion-dollar production environment between 2021 and 2024. Total Value Locked (TVL) across all L2 rollups exceeded $40 billion by mid-2024. Arbitrum consistently holds the largest share (~40%), followed by Base (~20%), Optimism (~15%), and a rapidly growing cluster of ZK rollups. This distribution reflects both technical maturity and ecosystem effects: Arbitrum was the first major general-purpose optimistic rollup to launch with significant liquidity, and that early mover advantage compounded through DeFi integrations.
The “superchain” paradigm is reshaping the competitive landscape. Coinbase’s Base and Zora both run on the OP Stack, making them compatible with Optimism through shared infrastructure. OP Labs is building a framework for chains to share sequencing, bridging, and governance while maintaining their own application focus. This creates an ecosystem of chains rather than a single monolithic rollup — analogous to AWS regions that share global infrastructure but serve local traffic.
The ZK rollup ecosystem is maturing rapidly but remains more fragmented. zkSync Era and StarkNet use custom virtual machines (zkEVM and Cairo VM respectively) that improve proof generation efficiency but require developers to adapt their tooling. Polygon zkEVM and Scroll aim for full EVM bytecode equivalence, accepting slower proof generation in exchange for seamless compatibility with existing Ethereum smart contracts. The practical developer experience gap between optimistic and ZK rollups has narrowed substantially — most major Ethereum dev tools now support both families.
Application-specific rollups (“app-chains”) are an emerging category: dedicated L2 environments built for single applications. Immutable X is an L2 for NFT gaming using StarkWare technology; dYdX migrated from Ethereum to its own Cosmos application chain for perpetual trading; Aevo runs a dedicated options trading rollup. The rationale is that application-specific rollups can optimize their execution environment, fee mechanisms, and governance for one use case — at the cost of reduced composability with the broader DeFi ecosystem.
Ethereum’s Modular Scaling Roadmap and the Path Forward
07Ethereum’s scaling strategy is often described as “modular”: rather than trying to make the base layer do everything, different functions are separated into specialized layers. Layer 1 becomes the settlement and data availability layer — the supreme court that provides final security guarantees. Layer 2 rollups become the execution layer where most user activity happens. Alternative DA layers (Celestia, EigenDA) may handle data for chains that accept weaker security in exchange for lower cost. This modular design allows each layer to optimize for its function rather than serving all purposes simultaneously.
EIP-4844 (March 2024) was the first major milestone, adding blob transactions that reduced L2 data costs by 80–90%. The next step, full danksharding, will expand blob capacity from 3–6 blobs per block (current) to potentially 64+ blobs per block using data availability sampling (DAS). DAS allows light clients to verify data availability without downloading entire blobs, by randomly sampling small pieces and using erasure coding to reconstruct missing data with high statistical confidence. Full danksharding is expected to support 100,000+ TPS across the L2 ecosystem.
Today (2024)
EIP-4844 blobs live. L2 fees at $0.01–$0.10. Arbitrum, Base, zkSync in production. ~40B TVL on L2s.
Near-term (2025–26)
Decentralized sequencers launching. More blob capacity. ZK proof times <1 second. Full EVM-equivalent ZK rollups.
Endgame (2027+)
Full danksharding. 100,000+ TPS. Data availability sampling. Most activity on L2; L1 is pure settlement.
1. What is the proof type? Fraud proofs (optimistic) vs validity proofs (ZK) — affects withdrawal time and security assumptions.
2. Who controls the sequencer? Centralized sequencers create censorship and MEV risk; check decentralization roadmap.
3. Where is data availability? On Ethereum L1 (most secure) or alternative DA layer (cheaper, weaker guarantees)?
4. What is the bridge security model? Native canonical bridge or third-party bridge with additional trust assumptions?
5. Is the ecosystem liquid? TVL, protocol deployments, and DEX volume indicate whether the L2 has genuine economic activity.
The rollup-centric roadmap represents a philosophical commitment: Ethereum will remain maximally decentralized and secure at Layer 1, even if that means accepting 15 TPS at the base layer forever. The throughput problem is delegated upward to L2s, which can innovate aggressively without altering the social contract of the base layer. This is the same architectural principle used in internet protocol design — the TCP/IP base layer has not fundamentally changed in decades, while applications built on top have scaled from email to video streaming to AI.
For the developer, the practical implication is clear: by 2024, Ethereum L1 is the settlement layer; the application layer is on L2. Building a new DeFi protocol, NFT platform, or payment application on L1 mainnet rather than an L2 is equivalent to building a web app on dial-up when broadband is available. The gas cost alone makes L1-only applications inaccessible to the majority of global users. Understanding rollup architecture, sequencer trust assumptions, and bridge security is no longer a specialist skill — it is foundational knowledge for any Ethereum developer.
