Why L2s were a success

Overview

The early ETH2 vision placed scaling primarily on the L1 via execution sharding, a technically elegant solution where the network would split into 64 parallel chains (shards) that could process transactions simultaneously while remaining part of one unified Ethereum. Each shard would have its own validators, state, and transaction history, but they would all settle to a single Beacon Chain that coordinated consensus. This approach would have kept Ethereum vertically integrated: one protocol, one security model, one set of rules, and one economic system.

However, it proved to be too complex (cross-shard messaging, preserving atomicity, keeping hardware requirements low) to achieve in a reasonable timeframe (hence the pivot to the rollup-centric roadmap in 2020-2021). The rollup-centric roadmap reframed Ethereum as a layer for settlement, data availability, and consensus, while L2s became its execution environments. Rollups would keep decentralization intact, security robust, and scale Ethereum — the trilemma was, supposedly, solved. 

This pivot also reflects Ethereum’s cultural preference: maximize optionality and credible neutrality by letting many teams experiment rather than forcing one canonical execution design. Rather than Ethereum Foundation engineers solving scaling themselves, the protocol created the conditions for others to experiment. L2 teams competed to build the best scaling solutions, taking on execution while Ethereum focused on being an excellent settlement and data availability layer. This was Ethereum choosing exploration, betting that decentralized innovation would outpace centralized planning. We discuss why critics consider this route a failure. 

Failures

Interoperability