Scaling & Layer 2 Solutions

Blockchain & Web3 Fundamentals
Course 1 · Chapter 9 · Scaling & Layer 2 Solutions

Chapter 8 closed on a real, concrete demonstration of a limit: CryptoKitties alone, at its peak, consumed up to 70% of Ethereum's entire network capacity. This chapter explains precisely why a base blockchain has so little headroom to spare in the first place, and covers the real, working approaches the industry has built to scale far beyond what a single base chain can process alone.

The Scalability Trilemma

Blockchain designers face a genuine, well-known tension often described as the scalability trilemma: a blockchain design tends to be able to strongly deliver on only two of these three properties at once, without real, significant compromise on the third:

Decentralization
many independent participants, no single point of control
Security
genuinely resistant to attack (Chapter 4's own 51%-attack economics)
Scalability
handling a large volume of transactions quickly and cheaply

Bitcoin and Ethereum's own base layers, as covered so far in this course, both deliberately prioritize decentralization and security. That choice comes with a real, direct scalability cost.

The Real Throughput Gap

Bitcoin (base layer)~7 transactions/second
Ethereum (base layer)a similarly low, commonly-cited figure in the tens of transactions/second
Visa's own data centers (reported capacity)up to 30,000 simultaneous transactions

Bitcoin's own real, documented base-layer throughput sits at roughly 7 transactions per second — a direct, structural consequence of Chapter 3's own fixed block size and Chapter 4's own roughly-10-minute block interval. Visa's own published figures describe its data centers as capable of handling up to 30,000 simultaneous transactions — a real, order-of-magnitude reminder of just how much headroom a base blockchain layer alone doesn't have if it needs to compete with existing centralized payment infrastructure at real-world scale.

Why the Network Can't Just "Make Blocks Bigger" It's tempting to assume the fix is simple — just allow bigger blocks, or shorter block times. But per the trilemma above, doing this at the base layer has real costs: bigger or more frequent blocks mean more data every single node has to download, store, and verify to fully participate, which tends to push out smaller, less-resourced participants over time — a genuine, direct erosion of decentralization, not a free lunch.

Layer 1 vs. Layer 2

Layer 1 refers to the base blockchain itself — Bitcoin's or Ethereum's own chain, with all the security properties this course has built up over the last eight chapters. Layer 2 refers to a separate system built on top of a Layer 1 chain, designed to handle the bulk of everyday transaction volume off the base chain, while still ultimately relying on the Layer 1 chain underneath for its own final security guarantees.

Payment Channels: Bitcoin's Lightning Network

Bitcoin's real, working Layer 2 solution is the Lightning Network, first described in a whitepaper by Joseph Poon and Thaddeus Dryja in February 2015, and actually launched on Bitcoin's mainnet in 2018. It works through payment channels: two parties lock up funds together in a shared, multi-signature on-chain transaction, then conduct any number of instant, effectively free transactions between themselves entirely off-chain, simply updating the private, agreed-upon split of the locked funds each time. Only when the channel is finally closed does one final, settled transaction get broadcast to the actual Bitcoin blockchain.

A network of many interconnected channels lets payments route between people who've never directly opened a channel with each other, hopping across a path of existing channels. This real network has grown substantially: as of recent measurements, it spans roughly 17,000 public nodes and around 40,000 public channels, with a total real capacity of roughly 4,900 BTC locked up across the network.

Rollups: Ethereum's Primary Scaling Approach

Ethereum's own dominant real scaling strategy is built around rollups, which execute a large batch of transactions off the main Ethereum chain, then post a compact summary of the results back to Layer 1, inheriting Ethereum's own base-layer security for that summary. Two real, genuinely different approaches exist:

  • Optimistic rollups — assume every batch of transactions is valid by default, and only actually run the underlying computation to verify it if someone specifically challenges the result during a set dispute window. This keeps everyday operation cheap, at the real cost of a withdrawal delay while that challenge window remains open.
  • Zero-knowledge (ZK) rollups — compute the results off-chain and submit a real cryptographic proof, verified mathematically on Layer 1, that the batch was processed correctly — without needing to reveal or re-execute every individual transaction on the base chain. This avoids the optimistic rollup's own withdrawal-delay trade-off, at the real cost of more complex cryptography to implement correctly.
Sidechains: A Related, but Distinct, Approach A sidechain is a separate blockchain, with its own independent consensus mechanism, connected to a Layer 1 chain via a bridge that lets assets move between the two. Unlike a rollup, a sidechain doesn't inherit Layer 1's own security directly — it has to secure itself independently, which is a genuine, real trade-off worth knowing rather than assuming every "Layer 2"-branded solution provides an identical security guarantee.
ApproachReal ExampleReal, Honest Trade-off
Payment channels Lightning Network (Bitcoin, 2018) Requires locking up capital in advance and actively managing channels
Optimistic rollups Ethereum ecosystem rollups Cheap, simple; withdrawals delayed by a dispute/challenge window
ZK rollups Ethereum ecosystem rollups Fast finality, no challenge window; more complex cryptography to build correctly
Sidechains Various bridged chains Own independent security model — doesn't inherit Layer 1 security automatically
Tying This Back to the Trilemma Layer 2 solutions are, at their core, a genuinely clever way to partially sidestep the trilemma rather than eliminate it: keep Layer 1 conservative, decentralized, and secure exactly as this course has described, while moving the bulk of everyday transaction volume to a separate layer specifically optimized for throughput — rather than compromising the base layer's own decentralization or security to get there directly.

Hands-On Exercises

Three exercises reinforcing the scalability trilemma and real Layer 2 mechanics, before Chapter 10's capstone traces one real transaction all the way through everything this course has covered.

Exercise 1
A colleague proposes: "Just increase Bitcoin's block size and shorten the block interval — problem solved." Using this chapter's own scalability trilemma, explain the real trade-off this proposal doesn't account for.
Exercise 2
Explain, in your own words, how two people who have never directly opened a Lightning Network channel with each other can still send a payment to one another through the network.
Exercise 3
Compare optimistic rollups and ZK rollups on exactly one dimension: how each one actually proves a batch of transactions was processed correctly, and what real cost each approach accepts in exchange for its own method.

Quick Reference

  • Scalability trilemma — decentralization, security, and scalability are genuinely hard to maximize all three at once.
  • Real throughput — Bitcoin's base layer processes roughly 7 transactions/second; Visa's own data centers report handling up to 30,000 simultaneously.
  • Layer 1 vs. Layer 2 — the base chain itself vs. a system built on top of it to offload everyday transaction volume.
  • Lightning Network — Bitcoin's real payment-channel Layer 2, launched 2018, letting parties transact off-chain and settle only occasionally on-chain.
  • Optimistic rollups — assume validity by default, verified only if challenged within a dispute window; cheap, but delayed withdrawals.
  • ZK rollups — submit a cryptographic proof of correct execution; fast finality, but more complex to build.
  • Sidechains — separate, independently-secured chains bridged to Layer 1, not automatically inheriting its security.