L2 "Recalibration": When L1 Becomes Its Own Rollup, What is Ethereum's Endgame?

"Are L2s cannibalizing L1 value?" "Is Ethereum losing its global composability?" During the peak of L2 hype, such anxieties pervaded the Ethereum community.

Within Ethereum's scaling framework at the time, L1 was the stable but expensive settlement layer, while L2s served as the cheap and efficient execution layer. While this did grant Ethereum more block space, it also gradually eroded the complete user experience of operating as "one chain."

Consequently, over the past two years, these questions have continuously pushed Ethereum to reassess the relationship between L1 and L2.

On one hand, Ethereum's L1 has been persistently increasing the Gas Limit, advancing statelessness and zkEVM verification, no longer content to be merely a low-throughput settlement base. On the other hand, community discussions have intensified. Early this year, Vitalik stated that as the Ethereum mainnet's own scaling capacity improves, some premises of the roadmap formulated five years ago, which positioned L2s as the primary scaling vehicle, have already changed (see Understanding Vitalik's L2 Reappraisal: Moving Beyond Fragmentation Towards Native Rollups in the New Phase).

More recently, Ethereum researcher Barnabé Monnot argued for a fundamental reassessment of the long-term relationship between L1 and L2s, including how L2s should create value in the future, why finality needs to be drastically shortened, and whether L1 could eventually become a form of "its own Rollup" as proving systems become integrated into the mainnet validation flow.

While these viewpoints don't yet constitute a finalized protocol roadmap, they offer a valuable lens for observation.

At its core, the challenge Ethereum faces today is no longer just about how to increase block space further, but how to redefine the division of labor between L1, L2, the execution layer, and the settlement layer when transactions, assets, and user states are dispersed across an increasing number of execution environments.

1. Ethereum Isn't Abandoning L2s, But Must Define a New Role

To be fair, at the inception of the Rollup-centric Ethereum scaling roadmap, the primary task for L2s was relatively singular: to provide more and cheaper transaction space for Ethereum.

This division of labor made perfect sense given the technical constraints of the time.

Since Ethereum validators must re-execute L1 transactions, drastically increasing mainnet throughput in the short term was not feasible. Rollups, by executing transactions off-chain in batches and submitting only compressed data or state commitments back to the mainnet, could significantly reduce per-transaction costs while retaining certain Ethereum security properties.

Thus, scaling evolved along two parallel paths: L1 remained restrained, prioritizing decentralization and security, while L2s absorbed new transactions, continuously lowering costs through Blobs, data compression, and proving technologies.

But now, the premises of this division have changed.

In 2026, the Ethereum Foundation restructured protocol work, merging the previously distinct "Scale L1" and "Scale Blob" efforts into a unified Scale roadmap. Increasing Gas Limit, expanding data availability, optimizing execution clients, and advancing statelessness and the zkEVM attester client are now all integrated within a single scaling framework.

In other words, Ethereum no longer treats scaling L1 and L2 as separate tasks but begins to reallocate execution, consensus, and data capacity from a holistic system perspective.

This shift does not mean Ethereum intends to abandon L2s or reabsorb all activity back to the mainnet. Instead, it implies that L2s can no longer prove their long-term value solely based on "faster transactions and lower Gas."

After all, if L1 itself can increase execution capacity by several orders of magnitude while maintaining security and decentralization, then generic EVM execution and low-cost block space are no longer unique L2 capabilities. What L2s will increasingly need to provide are differentiated requirements that L1 cannot easily satisfy uniformly, such as application-specific optimizations, privacy features, and more flexible governance and economic models.

The Ethereum Foundation's latest articulation of the L1/L2 relationship this year explicitly emphasizes this point. Previously, the primary goal of L2s was to scale Ethereum, with differentiation and customization as secondary values. Now, the goal is to provide differentiated functionality while continuing to contribute additional scaling capacity.

Correspondingly, L1 needs to become a sufficiently robust, permissionless, and highly resilient global hub, hosting settlement, shared state, liquidity, and DeFi.

This effectively moves L2s from a unified technical category towards a more complex continuous spectrum:

• At one end are Rollups that aim to inherit Ethereum's security properties as much as possible. They seek to minimize multi-sig security councils, open up permissionless proving mechanisms, and ensure users can still exit via L1 even if the operator stops functioning.
• In the middle are execution environments that inherit some Ethereum properties based on business needs. They might have stronger administrative controls, independent sequencers, or specific compliance designs, traded off for performance, privacy, and operational flexibility.
• At the other end could be chains that simply adopt the EVM, use Ethereum assets, or connect via some cross-chain infrastructure, but are relatively independent in terms of security and settlement.

This is why it's said Ethereum isn't abandoning L2s, but rather redefining the division of labor. Ultimately, in the past 3-5 years, L2 primarily represented a scaling technology. In the future, it will more likely represent a set of execution environments establishing different security, settlement, and liquidity relationships with Ethereum.

2. Interoperability Isn't Just Cross-Chain, It's About State Mutual Trust

However, as Ethereum expands into a system composed of numerous L2s, another familiar issue surfaces: more L2s inevitably fragment liquidity, account states, and application user experience.

This has been vividly demonstrated in practice over the past few years. Users might hold assets on one chain, use applications on another, and need to go to a third chain to complete a transaction. Consequently, the same stablecoin has different versions across different networks, and the same account has to deal with different Gas Tokens, bridges, and asset entry points.

Therefore, interoperability has become an increasingly important part of Ethereum's roadmap.

Ethereum's protocol teams have focused the 2026 Improve UX roadmap on two main directions: native account abstraction and interoperability. They believe the key to solving L2 fragmentation lies in making Ethereum "feel like a chain again," a vision that depends on the maturation of intent architecture. 

• The Open Intents Framework allows users to simply declare their desired outcome, e.g., "convert asset A on chain X into USDC on chain Y," letting backend solvers handle pathfinding, bridging, execution, and rebalancing (see When 'Intents' Become the Standard: How OIF Ends Cross-Chain Fragmentation and Returns Web3 to User Intuition).
• The more advanced Ethereum Interoperability Layer aims to build a trustless transport layer, targeting a user experience for cross-L2 transactions indistinguishable from single-chain transactions (see Ethereum Interop Roadmap: Unlocking the 'Last Mile' for Mass Adoption).

On the account side, EIP-7702 from the Pectra upgrade allows traditional EOAs to temporarily execute smart contract code, enabling transaction batching, gas sponsorship, and recovery mechanisms. Subsequent native account abstraction proposals like EIP-8141 aim to embed smart account logic deeper into the protocol, making smart contract wallets the default account type and reducing reliance on additional Bundlers, Relayers, and middleware services.

L1 fast confirmation rules aim to provide a stronger security signal within tens of seconds, before full finality, thus shortening application waiting times for most normal scenarios. This would directly benefit all cross-chain applications reliant on L1 finality, with significant implications for bridges, stablecoin settlements, and RWA asset trading.

Because the real bottleneck for many cross-chain interactions isn't whether a message can be sent, but when the destination chain can be sufficiently certain that the state on the source chain won't be reverted.

An often overlooked point is that a transaction being included in a block does not guarantee finality. From a user's perspective, a transaction might show as successful in seconds. But for bridges, exchanges, lending protocols, and cross-chain solvers, they must still assess the likelihood of a chain reorganization affecting that transaction and whether they can safely release assets or execute subsequent operations on another chain based on it.

This is why many services that seem like 'instant settlement' for cross-chain transfers don't truly wait for finality on the source chain. Instead, solvers or liquidity providers front the funds. This mechanism optimizes user experience but doesn't eliminate the underlying waiting time.

So, Ethereum's long-term goal is to progressively shorten finality itself from minutes to seconds. This isn't a single scheduled upgrade but a set of research tasks to be pursued in phases. These include decoupling finality voting from fork choice, optimizing the validator set, vote aggregation, and network propagation, followed by gradual changes to the consensus protocol.

Overall, a good interoperability experience is not about giving dozens of chains a single cross-chain button, but enabling different execution environments to trust each other's state faster and at lower cost.

3. When L1 Becomes a Rollup, Do Layered Boundaries Still Exist?

If the changing role of L2s and the shortening of finality are still about readjusting the existing layered architecture, another point raised by Barnabé further touches the very definition of L1 and L2: As proving systems enter the Ethereum mainnet, L1 might ultimately become a form of "its own Rollup."

This statement sounds somewhat counter-intuitive.

After all, a Rollup is typically understood as a scaling network built on top of L1. It executes transactions externally, and L1 verifies the resulting state. So how could Ethereum itself, being the underlying consensus and settlement network, become its own L2?

To understand this viewpoint, one must first decouple "Rollup" from the hierarchical relationship. In today's Ethereum, upon receiving a block, a node must re-execute all its transactions, independently compute the state changes, and determine if the block follows protocol rules.

This model ensures nodes can self-verify, but it also means the network's overall execution capacity is constrained by the hardware limitations of an average node. The more computation within a block, the more hardware and time required for validators to complete execution.

In the future, as real-time proving and L1 zkEVM mature, transactions can still be computed by high-performance execution nodes. However, regular validators may not need to re-execute every transaction themselves. For instance, after the execution node calculates the state change, it generates a validity proof. Other validators only need to verify this smaller, lower-cost proof to confirm the state transition is correct.

From the perspective of execution versus verification, this indeed shares similarities with Rollups. A subset of participants handles high-performance execution, the execution result is compressed into a cryptographic proof, and the broader set of consensus participants no longer repeats all computation but verifies the proof and confirms the final state.

Therefore, what Barnabé describes as "L1 becoming its own Rollup" is better understood as a characterization of this verification model, rather than suggesting the Ethereum mainnet would be placed on top of another base layer or "downgraded" to its own L2.

His key point is that as proofs gradually replace the redundant execution by all nodes, 'Rollup' may no longer just be a layer name residing above L1, but could become a more general architecture for execution and verification.

This would further blur the traditional boundaries between L1 and L2.

On one hand, L1 can leverage zkEVM proofs to expand its own execution capacity. On the other hand, Native Rollups aim to allow L2s to more directly call upon Ethereum's in-protocol verification capabilities, enabling L1 to validate L2 state transitions in a more native and unified manner.

Today, different Rollups typically need to build their own proving systems, verification contracts, upgrade mechanisms, and security councils. If a proving system fails, a protocol needs an emergency upgrade, or the operator goes offline, users often rely on additional governance and trust structures. The long-term direction for Native Rollups is to embed some of these Rollup verification logics as native Ethereum capabilities. This would allow L2s to reduce their self-built security infrastructure, inherit L1's state transition rules more completely, and potentially move away from needing security councils.

Taking a step further, when multiple L2s can access each other's state via faster L1 confirmations, unified proving mechanisms, and synchronous composability, their relationship with the mainnet might no longer resemble today's network of bridges.

They would look more like multiple execution domains under the same Ethereum consensus. Some would handle general financial activity, others cater to gaming, social, or payments, and some provide privacy or specific compliance capabilities. They would have different execution logics and product forms but would all rely on a common framework of verifiable state, security foundation, and asset settlement.

Of course, this remains a long-term direction.

But regardless of the exact form these technologies eventually take, they are already transforming the boundary between L1 and L2 from a clear architectural line into a spectrum of varying degrees of security inheritance.

Final Thoughts

As the saying goes, the grand trends under heaven: long divided, must unite; long united, must divide.

Ethereum once achieved global composability through shared state. Later, it split execution via Rollups to gain greater capacity. Now, the task at hand is to reconnect the fragmented assets, accounts, and applications, without revoking the scaling achievements.

For the average user, the ideal Ethereum should never be a map of dozens of chains, different Gas tokens, and bridges. Where a transaction executes, which chain provides liquidity, and who ultimately settles it can gradually be handled by wallets, applications, and underlying protocols. However, the trust assumptions, security boundaries, and exit paths involved cannot be hidden along with the operational ease.

Therefore, the endgame for L2s might be neither to replace L1 nor to be phased out by an ever-scaling L1. Instead, they could become a set of execution environments with varying functions and performance characteristics, yet capable of sharing security, liquidity, and state relationships.

In the past, Ethereum gained greater capacity by splitting execution.

In the next phase, let's see if, after splitting, it can still be reassembled into a single Ethereum.