Vitalik on L2s and Execution Sharding: What's the Difference and Challenges?
TechFlow Selected TechFlow Selected
Vitalik on L2s and Execution Sharding: What's the Difference and Challenges?
An L2-centric ecosystem is, in true technical terms, sharding.
Navigating Web3 tides with focused insightsAuthor: Vitalik Buterin
Translation: Peng Sun, Foresight News
Two and a half years ago, in my "Endgame" article, I argued that the different paths forward for blockchains look very similar at least technically. In both cases, there are large volumes of transactions on-chain, requiring (1) massive computation and (2) massive data bandwidth to process. Ordinary Ethereum nodes—like the 2 TB reth archive node currently running on my laptop—even with strong software engineering performance and Verkle trees, are insufficient to directly verify such enormous amounts of data and computation. Instead, in both the "L1 sharding" and rollup-centric approaches, ZK-SNARKs are used to verify computation and DAS is used to verify data availability. Whether it’s L2 shards or rollups, DAS works the same way, and ZK-SNARK technology is identical. They function both as smart contract code and as protocol features. In a real technical sense, Ethereum is already sharded, and rollups are shards.
This naturally raises the question: what's the difference? One key distinction lies in the consequences of code bugs: in a rollup, tokens can be stolen; in sharding, consensus itself breaks down. However, I expect that as protocols mature and formal verification techniques improve, the impact of code bugs will diminish over time. So what other differences remain between these two potentially coexisting approaches?
Diversity of Execution Environments
Back in 2019, one idea we briefly discussed within Ethereum was execution environments. Essentially, Ethereum would host different “zones” with distinct rules governing accounts (including entirely different models like UTXO), virtual machine behavior, and other functionalities. This would allow methodological diversity across different layers of the stack—something difficult to achieve if Ethereum tries to do everything within a single monolithic framework.
Ultimately, we abandoned some of the more ambitious plans and stuck with just the EVM. However, Ethereum L2s—including rollups, validiums, and plasmas—can arguably fulfill the role of execution environments. Currently, we tend to focus on EVM-equivalent L2s, but this overlooks the diversity offered by many alternative approaches:
-
Arbitrum Stylus, which adds a second oracle based on WASM alongside the EVM;
-
Fuel, which uses a Bitcoin-like (but more feature-rich) UTXO-based architecture;
-
Aztec, which introduces a new language and programming paradigm designed around privacy-preserving ZK-SNARK-based smart contracts.
UTXO-based architecture, source: Fuel documentation
We could try turning the EVM into a super-virtual-machine covering all possible paradigms, but doing so would make each functionality significantly less efficient than letting platforms specialize in what they do best.
Security Trade-offs: Scaling vs Transaction Speed
Ethereum L1 provides extremely strong security guarantees. If certain data is included in an L1 block that has achieved finality, then the entire consensus (including social consensus even in extreme cases) works to ensure that this data cannot be altered, that any execution triggered by it cannot be reverted, and that the data remains accessible. To provide this level of security, Ethereum L1 accepts high costs. At the time of writing, transaction fees are relatively low: Layer 2 charges less than one cent per transaction, and even basic ETH transfers on L1 cost less than one dollar. If technological progress continues rapidly enough, growing available block space may keep pace with demand, keeping fees low indefinitely—but not necessarily. For many non-financial applications—such as social media or gaming—even $0.01 per transaction may still be too expensive.
However, social media and gaming don’t require the same security model as L1. It doesn't matter much if someone spends a million dollars to reverse the record of losing a chess game, or make your tweet appear three days after it was actually posted. Therefore, these applications shouldn't pay the same security costs. L2 solutions address this by supporting a spectrum of data availability methods—from rollups, plasma, to validiums.
Different types of L2 suit different use cases. Read more here.
Another trade-off arises around asset transfers between L2s. I anticipate that over the next 5–10 years, all rollups will become ZK rollups, and ultra-efficient proof systems such as Binius and Circle STARKs with lookups, combined with proof aggregation layers, will enable L2s to provide final state roots every slot. But currently, we’re stuck combining Optimistic and ZK rollups in complex hybrid arrangements using varying proof time windows. Had we implemented execution sharding back in 2021, the security model ensuring shard honesty would have been optimistic rollup-style rather than ZK, meaning L1 would need to manage complex on-chain fraud-proof logic, and withdrawals would take up to a week when moving assets between shards. But as with code vulnerabilities, I believe this issue is ultimately temporary.
Transaction speed represents a third—and more enduring—aspect of security trade-offs. Ethereum produces blocks every 12 seconds and won’t go faster, as doing so risks excessive centralization. However, many L2s are exploring sub-second block times—compressing them down to hundreds of milliseconds. A 12-second interval isn’t terrible: users typically wait about 6–7 seconds on average after submitting a transaction before it gets included in a block (not just 6 seconds, because the next block might not include their transaction). This is comparable to how long I wait when paying with a credit card. Still, many applications require faster confirmation, and L2s can deliver that.
To achieve faster speeds, L2s employ a preconfirmation mechanism: validators on the L2 digitally sign commitments to include a transaction at a specific time, and face penalties if they fail to do so. The StakeSure mechanism generalizes this idea further.
L2 preconfirmations
Now, we could attempt to implement all these features directly at L1. L1 could include both "fast pre-confirmations" and "slow final confirmations." It could support shards with varying security levels. But this increases protocol complexity. Moreover, implementing everything at L1 risks overloading consensus, since higher-throughput or larger-scale approaches often carry higher centralization risks or require stronger forms of "governance," whose effects could spill over into other parts of the protocol if handled at L1. By offering trade-offs through L2s, Ethereum largely avoids these risks.
Organizational and Cultural Benefits of Layer 2
Imagine a country split in two—one half becoming capitalist, the other half highly government-directed (unlike the real-world division seen in Germany, suppose in this thought experiment that this split occurs naturally overnight, without any traumatic war). In the capitalist half, restaurants are run by decentralized owners, blockchain systems, and elections. In the government-controlled half, they’re branches of the state, like police stations. On day one, little changes—people mostly follow existing habits, and success depends on technical realities like labor skills and infrastructure. But after a year, you’d see massive divergence, as different incentive and control structures reshape behavior, influencing who stays, who leaves, what gets built, maintained, or abandoned.
Industrial organization theory discusses such distinctions—not only between state-managed and capitalist economies, but also between economies dominated by large franchise corporations versus those where every grocery store is independently owned. I believe the difference between L1-centric and L2-centric ecosystems is similarly profound.
The "core developers control everything" architecture has serious flaws
As an L2-centric ecosystem, I believe Ethereum’s main advantage is this:
Because Ethereum is an L2-centric ecosystem, you're free to independently build a sub-ecosystem with unique features while still being part of the broader Ethereum network.
If you're building just an Ethereum client, you're part of Ethereum, but your room for innovation is limited compared to building an L2. If instead you're launching a fully independent chain, you gain maximum creative freedom—but lose benefits like shared security and shared network effects. L2s strike a powerful balance.
It offers not only technical opportunities to experiment with new execution environments and security trade-offs—achieving scalability, flexibility, and speed—but also creates incentives that motivate developers to build and maintain systems, and communities to support them.
Indeed, the isolation of each L2 means that deploying new methods is permissionless—you don’t need to convince all core developers that your new approach is “safe” for the rest of the chain. If your L2 fails, the responsibility is yours. Anyone can pursue bold ideas (e.g., Intmax’s Plasma approach) and continue building and eventually deploy, even if Ethereum core developers pay no attention. L1 features and precompiles don’t work this way. Even in Ethereum, the success or failure of L1 development often hinges more on politics than we’d prefer. Regardless of what could theoretically be built, the differing incentive structures between L1-centric and L2-centric ecosystems profoundly affect what actually gets built, its quality, and its timeline.
What challenges does Ethereum’s L2-centric ecosystem face?
The L1 + L2 architecture has serious problems.
Image source: Reddit
This L2-centric approach faces one critical challenge that L1-centric ecosystems rarely encounter: coordination. In short, while Ethereum hosts many L2s, the real challenge is making them feel collectively like “Ethereum,” preserving Ethereum’s network effects rather than fragmenting into N isolated chains. Today, this falls short in several ways:
-
Cross-L2 transfers usually rely on centralized bridges, which are complex for ordinary users. You can’t simply copy someone else’s Arbitrum address and send funds from Optimism.
-
Cross-L2 support for smart contract wallets—both individual and organizational (including DAOs)—is poor. If you rotate keys on one L2, you must manually update keys on every other L2.
-
Decentralized validation infrastructure is often lacking. Ethereum has finally gained decent light clients, such as Helios. But if all activity moves to L2s, each requiring its own centralized RPC endpoint, the point is lost. In principle, once you have Ethereum block headers, building light clients for L2s isn’t hard—but in practice, this receives far too little attention.
The community is actively working to improve these three areas. For cross-L2 token transfers, ERC-7683 is a new standard that differs from existing “centralized bridges” by having no fixed centralized nodes, tokens, or governance. For cross-L2 accounts, most wallets plan to use short-term replayable cross-chain messages to update keys, and long-term keystore rollups. Light clients for L2s are emerging—for example, Beerus for Starknet. Additionally, recent improvements in next-generation wallets have addressed more fundamental UX issues, such as allowing users to access DApps without manually switching networks.
Rabby’s unified multi-chain asset balance view—a capability previous wallets lacked!
But we must recognize that coordination in an L2-centric ecosystem is inherently challenging. No single L2 has a natural economic incentive to build coordination infrastructure: small L2s won’t bother because the benefit is too small; large L2s won’t either, because they gain equal or greater value from strengthening their local network effects. If every L2 acts solely in self-interest, with no one considering alignment with the broader Ethereum system, we risk failing—just like the urban dystopia depicted in the images above.
There’s no perfect solution to this problem. All I can say is that the ecosystem needs to better recognize that cross-L2 infrastructure—like L1 clients, developer tools, and programming languages—is a core type of Ethereum infrastructure and thus deserves proper attention and funding. We have the Protocol Guild; perhaps we also need a Basic Infrastructure Guild.
Conclusion
In public discussions, “L2” and “sharding” are often framed as opposing strategies for blockchain scaling. Yet, when examining the underlying technologies, a paradox emerges: the actual scaling mechanisms are nearly identical. Whether it’s data sharding, fraud proofs or ZK-SNARK verifiers, or solutions for communication across “rollups, shards”—the primary differences lie in: who builds and maintains these components, and how much autonomy they have?
An L2-centric ecosystem is, in genuine technical terms, sharding—but with the ability to build your own shard under your own rules. This is immensely powerful, enabling boundless creativity and widespread innovation. Yet it also presents key challenges, especially around coordination. For an L2-centric ecosystem like Ethereum to succeed, it must understand these challenges and proactively address them—to capture as many benefits of L1-centric systems as possible, and move closer to the best of both worlds.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@VitalikButerin
