web3.path

PHASE 12 Scaling · ~3 hours

Layer 2 & Scaling

Ethereum L1 does ~15 tx/s. That's the global throughput. L2s are how we get to Visa-scale without abandoning L1 security.

Goal — know the difference between optimistic and zk rollups, sidechains, validiums, and deploy your existing contract to an L2.

1. The scaling problem in one sentence

Every full node must re-execute every tx. To scale, you either (a) move execution off L1 and post only results ("rollups"), or (b) run a separate chain ("sidechain") and hope it stays honest.

2. The scaling landscape

TypeWho verifies?SecurityExamples
Optimistic rollupL1 accepts unless fraud proof within 7d~L1 (assumes 1 honest watcher)Optimism, Arbitrum, Base
zk rollupL1 verifies a succinct proof per batchL1 (cryptographic)zkSync, Starknet, Polygon zkEVM
ValidiumLike zk but data off-chainDepends on DA committeeImmutable X
SidechainOwn validator setOwn security budgetPolygon PoS, BNB Chain
State channelPeer-to-peer, settle laterL1 for disputesLightning (BTC), (rare on ETH)
Analogy — L1 is mainnet Git. L2 is a git-svn clone that does fast local work, then batches "pushes" back. Optimistic = "assume my push is good unless someone cries fraud in a week". zk = "here's a mathematical proof the push is correct".

3. How a rollup works (big picture)

Users send txs to L2 sequencer (fast, cheap) │ ▼ Sequencer batches ~1000 txs, compresses, posts to L1 as calldata/blobs │ ▼ Optimistic: 7-day challenge window to submit fraud proof zk: Prover generates SNARK/STARK, verifier contract checks it on L1 │ ▼ L1 state root updates → withdrawals finalize

The security model is: "L1 is your settlement and data availability layer; the L2 is just an execution shortcut."

4. Costs & UX

5. Deploying to Base / Optimism / Polygon

// hardhat.config.js
networks: {
  base:    { url: "https://mainnet.base.org", accounts: [PK] },
  optimism:{ url: "https://mainnet.optimism.io", accounts: [PK] },
  polygon: { url: "https://polygon-rpc.com", accounts: [PK] },
}
npx hardhat run scripts/deploy.js --network base

That's it. Verify on the L2's block explorer (Basescan, Arbiscan, etc.) with the same plugin.

6. Nuances that bite in production

7. Data availability (DA)

"Where is the full tx data stored?" On L1 calldata (rollup) = max security. On a DA committee (validium) = cheaper, weaker. Modular chains (Celestia, EigenDA) provide cheap DA for L2s — this is 2025's hot infra category.

8. zk proofs, intuition-only (Phase 13 goes deeper)

A SNARK lets a prover convince a verifier that "I executed these 1,000 txs correctly starting from state S_0 and ending at state S_1" with a ~200-byte proof verifiable in milliseconds. The L1 verifier contract is just some elliptic-curve pairings.

9. Bridging pattern you'll actually build

// L1 deposit
Bridge.depositETH{value: 1 ether}()  → emits Deposit(user, 1 ether)
// L2 relayer / bridge watcher mints 1 L2-ETH to user on L2
// L2 withdraw
Bridge.withdrawETH(1 ether) on L2     → state posts to L1
// After finality window, user calls Bridge.finalize(user, 1 ether) on L1
Golden rule — never write your own bridge. Use the canonical one or a battle-tested protocol. Bridges are the #1 attack target ($2B+ lost historically).

10. Project

Deliverable — deploy your Phase 6 ERC-20 to Base Sepolia (testnet). Use the canonical bridge UI to move test ETH from Sepolia L1 to Base. Interact from your Phase 7 React app on both chains and handle wallet_switchEthereumChain.

Quiz

Q. On an optimistic rollup, you withdraw funds. Why does the canonical bridge take 7 days?
The whole optimistic-security model rests on the challenge window. Shortcut it via a liquidity bridge (3rd party lends you L1 ETH, charges ~0.1%, waits 7d for reimbursement).
← Phase 11Phase 13: Zero-Knowledge Proofs →