+ Layer 1 blockchains are intentionally slow. They cap throughput to keep every node in + sync and preserve decentralization. Layer 2 solutions run on top, processing transactions + off-chain and anchoring trust back to the base chain. +
+ ++ Every node on a blockchain processes every transaction. This is what makes it trustless: + you don't have to trust any single operator because you can verify the chain yourself. But + it also means throughput is bounded by what the slowest full node can handle. +
++ Blockspace is capped to keep block production predictable. + When demand exceeds capacity, fees rise and transactions queue up. You can't simply raise + the block limit without making it harder to run a node, which weakens decentralization. +
+ ++ Blockchains face a tradeoff between three properties:{' '} + decentralization, security, and{' '} + scalability. Optimizing for any two typically degrades the third. A + network with very high throughput either relies on powerful hardware (centralizing who + can run a node) or weakens its security guarantees. +
++ Layer 2 approaches this differently: offload execution to a separate system, but inherit + the security of Layer 1 for the final settlement. The L2 can be faster and cheaper because + it doesn't require global consensus for every transaction; only the final result needs to + be verifiable on-chain. +
+ +There are two broad families of Layer 2 solutions:
++ State Channels + {' · '} + Rollups + {' · '} + Blockspace +
++ {mode === 'optimistic' + ? 'Optimistic: batches are assumed valid. A 7-day challenge window allows fraud proofs before finality.' + : 'ZK: a validity proof is generated for each batch. The L1 verifies it instantly, with no waiting period needed.'} +
++ A rollup executes transactions off-chain in bulk, then posts compressed data and a + correctness proof to Layer 1. One on-chain post covers thousands of transactions. +
+ ++ On a plain Layer 1, every node re-executes every transaction. Rollups flip this: a{' '} + sequencer batches many transactions and executes them off-chain. It then + posts to L1 only what's needed to verify the result: +
++ The L1 doesn't re-execute the transactions. It only verifies the proof and stores the + data. This is dramatically cheaper per transaction than running everything on L1. +
+ ++ Optimistic rollups assume every batch is valid and don't require an upfront proof. Instead, + they open a challenge window (typically seven days) during which anyone + watching the chain can submit a fraud proof if they detect an invalid + state transition. +
++ If no fraud proof is submitted within the window, the batch is finalized. If a valid fraud + proof is accepted, the invalid batch is reverted and the sequencer is penalized. The system + relies on at least one honest party monitoring the chain. +
++ The tradeoff: batches are cheap to produce, but users must wait for the challenge period to + expire before they can withdraw funds to L1. Liquidity providers often abstract this away + by advancing funds immediately and collecting the bridged funds later. +
+ ++ ZK rollups generate a cryptographic validity proof alongside every batch. + The L1 verifies this proof, which takes milliseconds, and rejects any batch where the + proof fails. There is no challenge window: if the proof verifies, the state transition + is guaranteed correct. +
++ Because correctness is proved upfront, withdrawals can be finalized as soon as the proof + is verified on L1, often within minutes. The tradeoff: generating a validity proof is + computationally expensive, which increases the hardware requirements for sequencers and + can create centralization pressure. +
+ +| + | Optimistic rollup | +ZK rollup | +
|---|---|---|
| Withdrawal finality | +~7 days (challenge window) | +Minutes (after proof verification) | +
| Security model | +Fraud proofs (requires at least one honest watcher) | +Validity proofs (cryptographic guarantee) | +
| Sequencer compute | +Low | +High (proof generation) | +
| EVM compatibility | +Easier (run the EVM directly) | +Harder (must prove EVM execution in a circuit) | +
+ Back to Layer 2 Scaling + {' · '} + State Channels +
++ {isClosed && 'Open a channel to start exchanging off-chain payments.'} + {isOpen && 'Payments between Alice and Bob happen instantly, off-chain.'} + {isSettled && + `${offChainTxCount} payment${offChainTxCount !== 1 ? 's' : ''} settled with only 2 on-chain transactions.`} +
++ Two parties can exchange thousands of signed state updates off-chain, then settle the final + result with only two on-chain transactions: one to open the channel, one to close it. +
+ ++ To open a channel, both parties submit an on-chain transaction that locks their funds into + a shared contract. This is the funding transaction. From this point, the + blockchain holds the funds as collateral, but the parties interact directly with each + other, not through the chain. +
+ ++ Each payment is a signed message: a new state update reflecting who owns what. Both parties + sign each update. The latest co-signed state is always the valid one; older states are + superseded and can be rejected. None of these messages touch the chain; they are instant + and cost nothing to exchange. +
++ The parties don't need a miner, validator, or any third party to process their payments. + They only need each other, and the chain as a backstop if something goes wrong. +
+ ++ Either party can submit the latest co-signed state to the chain at any time to close the + channel cooperatively. The contract verifies the signatures and distributes the locked funds + according to the final balances. This is the second and last on-chain transaction. +
+ ++ If one party goes offline or tries to close the channel using an outdated state (to reclaim + funds they already spent), the other party has a challenge period to + submit a newer co-signed state as evidence. The contract accepts the most recent valid state + and penalizes the dishonest party. +
++ This means both parties must remain able to respond within the challenge window. If you go + offline for too long, a dishonest counterparty could finalize an old state unchallenged. +
+ ++ State channels excel at repeated bilateral interactions, like a streaming payment between + two known parties. They are not well suited for: +
++ For general-purpose scaling, where any user can interact with any contract,{' '} + rollups are the more practical solution. +
+ ++ Back to Layer 2 Scaling + {' · '} + Rollups +
+