BTC
ETH
HTX
SOL
BNB
시장 동향 보기
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

L2「재조정」: L1이 자신의 롤업이 될 때, 이더리움의 종말은 무엇인가?

imToken
特邀专栏作者
2026-07-21 12:40
이 기사는 약 4923자로, 전체를 읽는 데 약 8분이 소요됩니다
L1이 직접 확장을 시작하고 L2가 차별화된 실행으로 전환할 때, 어떻게 이더리움을 재구성할 것인가.
AI 요약
펼치기
  • 핵심 관점: 이더리움은 L2를 단순한 확장 도구로 보는 시각에서 벗어나 L1과 L2의 역할 분담을 재정의하고 있다. L1은 강력하고 안전한 글로벌 결제 허브가 되고, L2는 낮은 가스비 이점에만 의존하지 않고 차별화된 기능, 프라이버시 및 특정 최적화를 제공해야 한다. 궁극적인 목표는 이더리움을 "다시 하나의 체인처럼 느끼게" 만들어 파편화 문제를 해결하는 것이다.
  • 핵심 요소:
    1. L2 가치 재정의: 과거 L2의 일차적 목표는 이더리움을 확장하는 것이었으나, 미래에는 차별화된 기능(예: 프라이버시, 특정 애플리케이션 최적화, 유연한 거버넌스)을 제공하고 확장 능력에 계속 기여하는 방향으로 전환될 것이다.
    2. L1 역할 강화: 이더리움 재단은 확장 로드맵을 통합하여 L1 자체의 실행 용량과 데이터 가용성을 높이고 있다. 이는 L1이 단순한 결제 레이어에 만족하지 않고 공유 상태, 유동성, DeFi의 글로벌 허브가 되려는 의도이다.
    3. 상호운용성의 핵심은 상태 신뢰: 파편화 문제 해결의 핵심은 단순한 크로스체인 브리징이 아니라, 서로 다른 L2가 더 빠르고 저렴하게 서로의 상태를 신뢰할 수 있도록 하는 것이다. 의도 아키텍처와 더 빠른 최종 확정성이 핵심 기술 경로이다.
    4. L1이 자체 롤업이 될 가능성: zkEVM 증명이 성숙해짐에 따라 검증자는 모든 트랜잭션을 재실행할 필요 없이 증명만 검증하여 상태를 확인할 수 있다. 이러한 실행과 검증의 분리 모델은 L1과 L2의 경계를 모호하게 만들 것이다.
    5. 이더리움 장기 전망: 미래의 L2는 더 이상 단일 계층이 아니라, 이더리움의 보안, 유동성 등의 속성을 공유하지만 서로 다른 실행 로직과 제품 형태를 가진 "실행 환경"들의 집합이 될 것이며, 이는 공통된 검증 체계에 의존한다.

"Is L2 cannibalizing L1's value?" "Is Ethereum losing its global composability?" During the peak popularity of L2, such anxieties permeated the entire Ethereum community.

In Ethereum's scaling framework at that time, L1 served as the stable but expensive settlement layer, while L2 functioned as the cheap and efficient execution layer. This indeed provided Ethereum with more block space, but it also gradually led to the loss of a cohesive experience as a 'single chain'.

Consequently, over the past two years, these questions have continuously driven Ethereum to re-evaluate the relationship between L1 and L2.

On one hand, the Ethereum L1 has been consistently increasing the Gas Limit, advancing statelessness and zkEVM verification, no longer content with being merely a low-throughput settlement base. On the other hand, community discussions have become increasingly heated. Earlier this year, Vitalik stated outright that as the Ethereum mainnet's own scaling capabilities improve, some of the premises of the roadmap formulated five years ago, which positioned L2 as the primary scaling method, have changed (read more in 'Understanding Vitalik's L2 Reflection: Moving Away from Fragmentation, Correcting Course Towards Native Rollup in the New Phase').

More recently, Ethereum researcher Barnabé Monnot called for a re-examination of the long-term relationship between L1 and L2. This includes how L2 should create value in the future, why finality needs to be significantly shortened, and whether L1 could also become a 'Rollup of itself' in a sense as proof systems are progressively integrated into the mainnet verification process.

While these viewpoints do not yet represent a finalized protocol roadmap, they offer a valuable lens for observation.

Ultimately, the challenge Ethereum faces today is no longer just about how to further increase block space. It is about how to re-divide labor among L1, L2, execution layers, and settlement layers when transactions, assets, and user states are dispersed across more and more execution environments.

1. Ethereum Hasn't 'Abandoned' L2, but Must Find a New Positioning

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

Under the technical conditions of that time, this division of labor was entirely reasonable.

Because Ethereum validators need to re-execute L1 transactions, the mainnet's throughput couldn't be aggressively increased in the short term. Rollups could batch-execute transactions off-chain and only submit compressed data or state commitments back to the mainnet, significantly reducing unit transaction costs while retaining some of Ethereum's security properties.

Thus, scaling formed two parallel paths: L1 remained restrained, prioritizing decentralization and security, while L2 absorbed incremental transactions, continuously reducing costs through Blobs, data compression, and proof technologies.

Now, however, the premises of this division of labor have changed.

In 2026, the Ethereum Foundation re-integrated protocol work, merging the previously separate 'Scale L1' and 'Scale Blob' tracks into a unified Scale roadmap. Initiatives like increasing the Gas Limit, expanding data availability, optimizing execution clients, and advancing statelessness and the zkEVM attester client were placed within a single scaling framework.

In other words, Ethereum no longer views the scaling of L1 and L2 as two separate tasks but is reallocating execution, consensus, and data capacity from a holistic system perspective.

This change does not mean Ethereum intends to abandon L2 or suck all activity back to the mainnet. On the contrary, it means L2 can no longer easily prove its long-term value solely by being 'faster and cheaper'.

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

The Ethereum Foundation's latest statements on the L1-L2 relationship this year also clearly emphasize this point. Previously, L2's primary goal was to scale Ethereum, with differentiation and customization being secondary values. Now, the goal is to provide differentiated functionality while continuing to contribute additional scaling capacity.

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

This effectively pushes L2 from a unified technical category onto a more complex continuous spectrum:

  • At one end of the spectrum are Rollups that inherit Ethereum's security properties as much as possible. They aim to reduce reliance on multi-sig security councils, open up permissionless proof mechanisms, and ensure that even if the operator stops functioning, users can still exit via L1.
  • In the middle are execution environments that inherit some Ethereum properties based on business needs. They might have stronger management privileges, independent sequencers, or specific compliance designs in exchange for performance, privacy, and operational flexibility.
  • At the other end are chains that merely 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 is not abandoning L2, but rather redefining the division of labor. Ultimately, in the past 3-5 years, L2 primarily represented a scaling technology. In the future, it is more likely to represent a group of execution environments that establish different security, settlement, and liquidity relationships with Ethereum.

2. Interoperability Isn't Just About Cross-Chain, It's About How States Trust Each Other

However, when Ethereum expands into a system composed of numerous L2s, another perennial issue comes to the fore: the increasing number of L2s inevitably fragments liquidity, account states, and application experiences.

This has been starkly evident in real-world usage over the past few years. For instance, a user might hold assets on one chain, use an application on another, and need to go to a third chain to complete a transaction. The same stablecoin might have different versions across different networks, and the same account needs to handle different Gas Tokens, bridges, and asset entry points.

Therefore, interoperability has become an increasingly crucial part of the Ethereum roadmap.

The Ethereum protocol team has focused the 2026 Improve UX roadmap onto two main directions: native account abstraction and interoperability. They believe the key to solving L2 fragmentation lies in making Ethereum 'feel like one chain again', a vision that depends on the maturity of intent-based architecture.

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, like EIP-8141, seek to further embed smart account logic 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 confirmation signal within tens of seconds, well before full finality is achieved. This would reduce application wait times in most normal scenarios, directly benefiting all cross-chain applications that depend on L1 finality – a significant development for bridges, stablecoin settlements, and RWA asset trading.

Because the real bottleneck for many cross-chain interactions is not whether a message can be sent, but when the target chain can be sufficiently confident that the state on the source chain won't be reversed.

An often overlooked point is that a transaction being included in a block does not equate to its 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 still need to assess the likelihood of a block reorganization on the source chain before releasing assets or executing subsequent operations on another chain.

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

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

In general, a good interoperability experience isn't about giving dozens of chains a single cross-chain button. It's about enabling different execution environments to trust each other's states faster and at a lower cost.

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

If the changing role of L2 and the shortening of finality are still about readjusting the existing layered architecture, then another observation from Barnabé delves deeper into the very definitions of L1 and L2: as proof systems enter the Ethereum mainnet, L1 itself might eventually become a 'Rollup of itself' in a sense.

This statement might seem counterintuitive.

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. How could Ethereum itself, the underlying consensus and settlement network, become its own L2?

To understand this viewpoint, one must decouple 'Rollup' from strict hierarchical relationships. In today's Ethereum, a node receiving a block must re-execute all its transactions, independently compute state changes, and verify that the block adheres to protocol rules.

This model ensures nodes can verify for themselves, but it also means the network's overall execution capacity is constrained by the hardware limitations of ordinary nodes. 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 could still be computed by high-performance execution nodes. However, ordinary validators might not necessarily need to re-execute every transaction themselves. For example, an execution node could generate a validity proof after computation. Other validators would only need to verify the smaller, cheaper proof to confirm the state transition is correct.

From the perspective of the execution-verification relationship, this indeed resembles a Rollup. A subset of participants handles high-performance execution. The execution results are compressed into a cryptographic proof. The broader set of consensus participants no longer repeats all computations but instead verifies the proof to confirm the final state.

Therefore, Barnabé's notion of '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 main point is that when proofs gradually replace the need for all nodes to re-execute, 'Rollup' may cease to be just a layer name situated above L1. It 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 let L2s more directly call upon the verification capabilities embedded within the Ethereum protocol, allowing L1 to verify L2 state transitions in a more native and unified way.

Today, different Rollups often need to build their own proof systems, verification contracts, upgrade mechanisms, and security councils. If a proof system has errors, a protocol needs an emergency upgrade, or the operator fails, users often rely on additional governance and trust structures. The long-term direction of Native Rollups is to make part of the Rollup verification logic a native capability of Ethereum, allowing L2s to reduce self-built security infrastructure, inherit L1's state transition rules more completely, and potentially bypass security councils.

Taking a step further, if multiple L2s can access each other's states via faster L1 confirmations, unified proof mechanisms, and synchronous composability, their relationship with the mainnet might no longer resemble what it is today, connected by a network of bridges.

They would function more like multiple execution domains under the same Ethereum consensus. Some would handle general financial activities, others would be designed for gaming, social or payments, and some would offer privacy or specific compliance capabilities. They would have different execution logic and product forms, yet collectively depend on a unified system for verifiable state, security foundation, and asset settlement.

Of course, this remains a long-term direction.

But regardless of the final form these technologies take, they have already begun to shift the boundary between L1 and L2 from a clear architectural division into a spectrum of varying degrees of security inheritance.

Final Thoughts

The general trend under heaven is to long divide, must unite; to long unite, 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 undoing the scaling achievements.

For the average user, the ideal Ethereum should never look like a map of dozens of chains, different gas tokens, and bridges. Where a transaction executes, which chain the liquidity comes from, and who ultimately settles it can all be gradually handled by wallets, applications, and underlying protocols. However, the trust assumptions, security boundaries, and exit paths involved cannot be hidden alongside the improved user experience.

Therefore, the final outcome for L2 might be neither replacing L1 nor being phased out by an ever-scaling L1. Instead, L2s could become a set of execution environments with varying functions and performance levels, 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 being dismantled, it can be reassembled into a single Ethereum once again.

크로스체인
기술
Odaily 공식 커뮤니티에 가입하세요