Episode Summary
Executive Summary: Martin Koppelman argues Ethereum should create 128 "native" ZK rollups—L2s built, governed, and upgraded by Ethereum’s own developer community—to reduce liquidity, security, and UX fragmentation. He says these rollups would feel like one interoperable chain with faster finality, shared liquidity, and stronger trust than today’s externally run L2s, though the idea has only mixed traction so far.
Main Topics: Ethereum’s scaling problem and fragmentation (Priority: 5/5): Koppelman says the current rollup-centric roadmap scales Ethereum only partially because L2s remain loosely connected, forcing apps and liquidity to be replicated across chains. Native rollups as Ethereum-developed L2s (Priority: 5/5): He proposes rollups created, maintained, and upgraded by Ethereum’s own open-source developer process rather than by separate teams or multisigs. Why ZK rollups over optimistic rollups (Priority: 4/5): ZK rollups can prove state correctness much faster, enabling near-immediate L2-to-L1 settlement compared with the challenge windows required by optimistic rollups. Why 128 rollups (Priority: 4/5): The number is intended to maximize usable Ethereum-like blockspace while staying within current data availability constraints; more blobs would be needed to support it. Composability and unified liquidity (Priority: 5/5): The proposal aims to make assets, DeFi protocols, and state read/write access feel closer to one chain, including shared liquidity and more consistent rates across instances. Chain abstraction versus risk abstraction (Priority: 4/5): He warns that hiding chain choice from users is dangerous when L2 security varies widely; abstraction only makes sense if rollups share Ethereum-level trust and standards. Implications for existing L2s and Ethereum’s identity (Priority: 4/5): He argues current L2s would need to innovate beyond plain EVM blockspace, and frames the proposal as part of a broader debate over whether Ethereum is a money layer or a developer platform.
Key Arguments: Current Ethereum scaling is fragmented: rollups exist, but they are still separate chains with inconsistent security, liquidity, and UX. Native rollups would inherit Ethereum’s brand and trust because they are built and maintained by the same open-source community and upgrade process. Based rollups improve synchronization by making L2 blocks follow Ethereum blocks, reducing delay and improving perceived unity. ZK rollups are preferable because correctness can be proved in minutes or potentially seconds, enabling much faster settlement back to L1. The 128-rollup target is bounded by blob/data-availability limits, not by the conceptual design; more blob space would make the model more feasible. Chain abstraction is unsafe if users can be routed across rollups with very different security assumptions; abstraction should come only after standardization. A native-rollup ecosystem could improve composability by letting L2 apps directly leverage L1 liquidity and state, reducing the need to replicate infrastructure on every chain. Existing L2s would still have room to differentiate, but they would need to offer more than generic EVM blockspace to justify platform risk.
Data Points: Proposed native rollups: 128 - Koppelman says this is the target number of Ethereum-native rollups, constrained by blob/data availability. Current blobs per Ethereum block: 3 - He says today’s blob space is too limited to support 128 rollups. Optimistic rollup challenge window: 7 days - He cites current large withdrawal/finality windows used by major optimistic rollups like Optimism, Arbitrum, and Base. Alternative challenge window examples: at least an hour; probably a day - He says optimistic rollups need a substantial delay for fraud challenges. ZK proof generation time: minutes - He says current ZK systems can often produce proofs in minutes, enabling much faster settlement. Potential ZK proof generation time: seconds - He says ASIC-optimized proof systems could eventually reduce proof time to seconds. Ethereum block time: 12 seconds - He says proof generation could eventually fit within a single Ethereum block interval. Ethereum developer ecosystem: over 2,000 plus developers - This figure appears in sponsor copy discussing Polkadot, not the Ethereum proposal itself. Rollups listed on L2Beat: over 100 - He uses this as evidence that the term "rollup" now covers widely varying security models.
Pivotal Quotes: "Native roll-ups means that Ethereum just deploys a bunch of roll-ups themselves." — Martin Koppelman: Defines the core proposal: rollups built and operated by Ethereum’s own community. "I think chain abstraction turns into risk abstraction." — Martin Koppelman: Explains why hiding chain choice from users is dangerous when security standards vary widely across L2s. "Ethereum should be a platform for developers, where developers know this is a credible neutral platform." — Martin Koppelman: Frames Ethereum’s main purpose as a long-lived development platform rather than primarily a store-of-value asset.
Implications: If adopted, native rollups could make Ethereum feel like one coherent, high-capacity ecosystem with better UX and liquidity. But it would require stronger blob space and political consensus, and it could pressure existing L2s to differentiate beyond generic scaling.