"Are L2s cannibalizing L1's value?" "Is Ethereum losing its global composability?" During the years when L2s were at the peak of their popularity, such anxieties almost permeated the entire Ethereum community.
In Ethereum's scaling framework at that time, L1 was the stable but expensive settlement layer, while L2s, as cheap and efficient execution layers, indeed granted Ethereum more block space, but also gradually eroded the experience of a "unified chain."
Therefore, over the past two years, these questions have continuously driven Ethereum to re-examine the relationship between L1 and L2.
On one hand, Ethereum L1 persistently increased the Gas Limit, advanced statelessness and zkEVM verification, no longer content with merely being a low-throughput settlement base; on the other hand, community discussions intensified. Early this year, Vitalik explicitly stated that as Ethereum's own scaling capabilities improve, some premises of the roadmap established five years ago—which viewed L2s as the primary scaling solution—had already changed.
More recently, Ethereum researcher Barnabé Monnot further expressed the need to re-evaluate the long-term relationship between L1 and L2, including how L2s should create value in the future, why finality needs to be dramatically shortened, and whether L1 could also become a sort of "rollup of itself" as proof systems gradually enter the mainnet validation process.
While these viewpoints do not yet equate to a confirmed protocol roadmap, they provide a valuable lens for observation.
Ultimately, the problem Ethereum faces today is not just about continuing to increase block space, but rather how to re-divide labor among L1, L2, execution layers, and settlement layers as transactions, assets, and user states are dispersed across an increasing number of execution environments.
1. Ethereum Hasn't "Abandoned" L2, But Must Find a New Positioning
To be realistic, when the Ethereum scaling roadmap centered around Rollups was initially formed, L2's most important task was relatively singular: to provide Ethereum with more and cheaper transaction space.
Under the technological conditions of that time, this division of labor was quite reasonable.
Because Ethereum validators all needed to re-execute L1 transactions, mainnet throughput couldn't be aggressively increased in the short term. Rollups, however, could execute transactions in batches off-chain, submitting only compressed data or state commitments back to the mainnet, retaining a degree of Ethereum's security properties while significantly reducing unit transaction costs.
Thus, scaling gradually formed two parallel paths: L1 remained restrained, prioritizing decentralization and security, while L2s accommodated new transactions, continuously reducing costs through Blobs, data compression, and proof technologies.
But now, the premises of this division have changed.
In 2026, the Ethereum Foundation consolidated its protocol work, merging the previously separate "Scaling L1" and "Scaling Blobs" into a unified Scale roadmap. Increasing the Gas Limit, expanding data availability, optimizing execution clients, advancing statelessness, and zkEVM attester clients were all placed within the same scaling framework.
In other words, Ethereum no longer views L1 and L2 scaling as two separate tasks but has begun to reallocate execution, consensus, and data capacity from a system-wide perspective.
This change does not mean Ethereum is preparing to abandon L2s or pull all activity back to the mainnet. On the contrary, it means L2s can no longer easily justify their long-term value merely by being "faster and cheaper."
After all, if L1 itself can increase execution capacity by several orders of magnitude while maintaining security and decentralization, then ordinary EVM execution and low-cost block space will no longer be capabilities unique to L2s; L2s will need to shift focus towards providing differentiated needs that L1 cannot uniformly satisfy, such as application-specific optimizations, privacy features, and more flexible governance and economic models.
The Ethereum Foundation's latest statement this year on the L1-L2 relationship also explicitly emphasizes this. Previously, L2's primary goal was to scale Ethereum, with differentiation and customization as secondary values; now, it's about providing differentiated functionality while continuing to contribute additional scaling capacity.
Correspondingly, L1 needs to become a sufficiently powerful, permissionless, and highly resilient global hub, carrying settlement, shared state, liquidity, and DeFi.
This essentially pushes L2 from a uniform technical category towards a more complex continuum:
- At one end of the spectrum are Rollups that aim to inherit as many of Ethereum's security properties as possible, seeking to reduce multisig security committees, open permissionless proof mechanisms, and ensure users can still exit to L1 even if operators cease functioning.
- In the middle are execution environments that inherit some Ethereum properties based on business needs, potentially possessing stronger management permissions, independent sequencers, or specific compliance designs in exchange for performance, privacy, and operational flexibility.
- At the other end might be chains that adopt EVM, use Ethereum assets, or connect to some cross-chain facilities, but are relatively independent in terms of security and settlement.
This is why Ethereum isn't abandoning L2s, but rather redefining the division of labor. Essentially, over the past 3-5 years, L2 first and foremost represented a scaling technology; in the future, it is more likely to represent a set of execution environments that establish different security, settlement, and liquidity relationships with Ethereum.
2. Interoperability Isn't Just About Cross-Chain, But How States Trust Each Other
However, as Ethereum scales into a system comprising numerous L2s, another perennial issue gradually surfaces: the proliferation of L2s inevitably fragments liquidity, account states, and application experiences.
This has been vividly demonstrated in actual usage over the past few years. For instance, users might hold assets on one chain, use applications on another, and need to go to a third chain to complete a transaction. This results in the same stable币 having different versions across networks, and the same account needing to handle different Gas Tokens, bridges, and asset entry points.
Therefore, interoperability has become an increasingly important part of Ethereum's roadmap.
The Ethereum protocol team has focused its 2026 "Improve UX" roadmap on two directions: native account abstraction and interoperability, believing the core to solving L2 fragmentation lies in making Ethereum "feel like one chain again." This vision relies on the maturation of intent-based architecture.
- Among them, the Open Intents Framework allows users to simply declare their desired outcome, such as "convert a certain asset on Chain A to USDC on Chain B," with solvers handling path computation, bridging, execution, and fund rebalancing behind the scenes.
- A step further, the Ethereum Interoperability Layer (EIL) attempts to build a trustless transport layer, aiming for cross-L2 transactions to have an experience indistinguishable from single-chain transactions.
On the account side, EIP-7702 in the Pectra upgrade already allows traditional EOAs to temporarily execute smart contract code, supporting transaction batching, gas sponsorship, and recovery mechanisms. Subsequent native account abstraction proposals, represented by EIP-8141, aim to further embed smart account logic into the protocol, making smart contract wallets the default account form and reducing reliance on additional Bundlers, Relayers, and intermediary services.
The L1 Fast Finality proposal attempts to provide a stronger confirmation signal within tens of seconds, before full finality is achieved, significantly shortening application wait times in most normal scenarios. This directly benefits all cross-chain applications relying on L1 finality, which is crucial for bridges, stablecoin settlement, and RWA asset trading.
Because the real bottleneck for many cross-chain interactions isn't whether a message can be sent, but when the target chain can be sufficiently confident that the state on the source chain will not be reverted.
A commonly overlooked point is that a transaction being included in a block does not mean it has achieved finality—from a user's perspective, a transaction might show success within seconds, but for bridges, exchanges, lending protocols, and cross-chain solvers, they still need to assess the possibility of this transaction being affected by a chain reorganization, and whether they can release assets or execute the next operation on another chain based on it.
This is why many cross-chain services today that appear "instant" do not actually wait for the source chain to achieve finality; rather, solvers or liquidity providers advance the funds. This mechanism optimizes user experience but doesn't make the underlying wait time disappear.
Therefore, Ethereum's long-term goal is to gradually shorten finality itself from minutes to seconds. However, this is not a single upgrade scheduled for deployment, but a set of research tasks requiring phased advancement, including decoupling finality votes from fork choice, optimizing validator sets, vote aggregation and network propagation, and gradually changing the consensus protocol.
Overall, good interoperability experience is not about giving dozens of chains the same cross-chain button, but about enabling different execution environments to trust each other's states faster and at lower cost.
3. When L1 Becomes a Rollup, Does the Layered Boundary Still Exist?
If the repositioning of L2s and shortening finality are adjustments within the existing layered architecture, then another point raised by Barnabé touches the very definition of L1 and L2: with proof systems entering the Ethereum mainnet, L1 may eventually also become a sort of "rollup of itself."
This sounds somewhat counterintuitive.
After all, a rollup is typically understood as a scaling network built on top of L1; it executes transactions externally, with L1 validating the state results. So how could Ethereum, being the underlying consensus and settlement network, become its own L2?
Understanding this viewpoint requires first separating "Rollup" from the hierarchical relationship. In today's Ethereum, after a node receives a block, it needs to re-execute all transactions within, independently compute state changes, and judge whether the block adheres to protocol rules.
This model ensures nodes can verify independently, but it also means the network's overall execution capacity must be constrained by ordinary nodes' hardware capabilities. The more computation in a block, the more hardware and time validators need to complete execution.
In the future, as real-time proofs and L1 zkEVM mature, transactions can still be computed by high-performance execution nodes, but ordinary validators may not need to personally re-execute every transaction. For instance, after an execution node completes computation and generates a validity proof, other validators only need to verify the smaller, cheaper proof to confirm the state transition is correct.
From the perspective of the relationship between execution and verification, this indeed shares similarities with Rollups: a subset of participants is responsible for high-performance execution, execution results are compressed into cryptographic proofs, and a broader set of consensus participants no longer repeats all computations, but verifies proofs and confirms the final state.
Therefore, Barnabé's phrase "L1 becoming its own rollup" is better understood as a summary of this verification paradigm, not that the Ethereum mainnet will be placed on another underlying chain or be "demoted" to its own L2.
His point is that when proofs gradually replace repeated execution by all nodes, a rollup may no longer be just a layer name above L1, but become a more general execution and verification architecture.
This will further blur the traditional boundary between L1 and L2.
On one hand, L1 can expand its own execution capacity with zkEVM proofs; on the other hand, Native Rollups aim to allow L2s to more directly invoke validation capabilities within the Ethereum protocol, with L1 validating L2 state transitions in a more native, unified manner.
Today, different Rollups typically need to build their own proof systems, verification contracts, upgrade mechanisms, and security committees. Once a proof system has errors, a protocol needs emergency upgrades, or an operator fails, users often still rely on additional governance and trust structures. The long-term direction of Native Rollups is to turn part of the Rollup validation logic into a native Ethereum capability, allowing L2s to reduce self-built security structures, inherit L1's state transition rules more completely, and potentially move away from security committees.
Going a step further, when multiple L2s can rely on faster L1 confirmation, unified proof mechanisms, and synchronous composability to access each other's states, their relationship with the mainnet may no longer be connected by bridges as it is today.
They would be more like multiple execution domains under the same Ethereum consensus, some responsible for general finance, some for gaming, social, or payments, some providing privacy or special compliance capabilities. They have different execution logics and product forms, yet collectively rely on a set of verifiable state, security foundations, and asset settlement systems.
Of course, this remains a long-term direction.
But regardless of the final form these technologies take, they have already transformed the L1-L2 boundary from a clear architectural line into a spectrum of different degrees of security inheritance.
In Conclusion
Long-divided, must unite; long-united, must divide.
Ethereum once gained global composability through shared state; later, it split execution out via Rollups to gain greater capacity. Now, its task is to reconnect the fragmented assets, accounts, and applications without undoing the scaling achievements.
For ordinary users, the ideal Ethereum should never be a network map of dozens of chains, different Gas tokens, and bridges. Where transactions execute, where liquidity comes from, and who ultimately settles 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 experience.
Therefore, the endgame for L2s is perhaps neither replacing L1 nor being made obsolete by an increasingly scalable L1. Instead, it is to become a set of execution environments with different functionalities and performances, yet sharing security, liquidity, and state relationships.
In the past, Ethereum gained greater capacity by splitting execution apart.
In the next phase, let's see if, after being split apart, it can still be put back together as one Ethereum.
