讲师中心 微信公众号
AI工具推荐 视频效率加速

以太坊重估L1与L2:当主网走向Rollup化后会怎样

云明大大_4267

云明大大_4267

发布时间:2026-07-26 15:30:22

|

1070人浏览过

|

来源于php中文网

原创

‍

l2再校准:当l1变成自身的rollup,以太坊的终局是什么?

“L2 会不会不断削弱 L1 的价值?”“以太坊会不会因为越来越多的 L2,而失去原本像‘一条链’那样的整体体验?”在 L2 叙事最火热的那几年,这类问题几乎贯穿了整个以太坊社区,也成为理解以太坊扩容路线时很难绕开的核心讨论。

按照当时较为主流的分工,L1 主要负责安全性更强、但使用成本更高的结算;L2 则承担更便宜、更高效的交易执行。这样的设计确实让以太坊获得了更多区块空间,也让更多应用有了落地空间。不过,代价同样明显:用户、资产和应用被分散到不同网络后,以太坊作为一个统一系统的体验被削弱了。

也正因为如此,过去两年中,市场和社区一直在重新思考一个问题:L1 和 L2 未来到底该怎么分工,它们之间的关系又该如何重新定义。

一方面,以太坊 L1 正在持续提高 Gas Limit,并推进无状态化和 zkEVM 验证,不再满足于只充当一个低吞吐量的结算底层;另一方面,社区也在重新审视过去的扩容前提。年初,Vitalik 就曾指出,随着以太坊主网本身的扩容能力增强,五年前将 L2 视为核心扩容路径时所依据的一些前提条件,已经发生了变化。

最近,以太坊研究者 Barnabé Monnot 也进一步提出,应该重新看待 L1 与 L2 的长期关系,包括:L2 将来如何建立自身价值、为什么最终确定性需要显著缩短,以及当证明系统逐步纳入主网验证流程之后,L1 是否也可能在某种意义上变成“自身的 Rollup”。

这些观点并不等同于已经拍板的协议路线,但它们确实提供了一个值得关注的观察角度,帮助我们理解以太坊下一阶段可能会往哪里走。

归根结底,以太坊现在面对的核心问题,已经不只是继续扩展区块空间,而是当交易、资产和用户状态被分散到越来越多执行环境之后,L1、L2、执行层和结算层到底该如何重新划分职责。

以太坊重新定义L1与L2

一、以太坊正在重新评估 L1 与 L2 的关系:L2 没有被放弃,但角色正在变化

如果回到最初的背景来看,Rollup 之所以成为以太坊的重要扩容方向,目标其实很直接:让 L2 为以太坊提供更多、同时也更便宜的交易空间。

在当时的技术条件下,这样的分工非常合理。

原因并不复杂。以太坊主网上的验证者需要重新执行 L1 交易,所以主网吞吐量很难在短时间里大幅提升。而 Rollup 可以先在链下批量执行交易,再把压缩后的数据或状态承诺提交回主网。这样既尽量保留了以太坊的安全属性,也显著降低了单笔交易成本。

于是,以太坊扩容逐渐形成了两条并行路线:L1 保持更谨慎的扩展节奏,优先维护去中心化和安全;L2 则承接新增交易需求,并借助 Blob、数据压缩和证明系统持续降低成本。

但现在,这套分工赖以成立的一些前提,已经开始发生变化。

以太坊基金会在 2026 年重新整合协议工作,把原本相对独立的“扩展 L1”和“扩展 Blob”并入统一的 Scale 路线。提高 Gas Limit、增强数据可用性、优化执行客户端、推进无状态化,以及 zkEVM attester client,都被放进同一套扩容框架里。

这意味着,以太坊不再把 L1 扩容和 L2 扩容视为两件彼此割裂的事情,而是开始从整个系统的角度,统一考虑执行、共识和数据容量该如何配置。

这当然不代表所有活动都要回到主网,更不意味着以太坊要放弃 L2。更准确地说,新的信号是:L2 很难再只靠“更快”“更便宜”这两个标签,来证明自己的长期价值。

如果未来 L1 能在兼顾安全和去中心化的前提下,把自身执行能力提升几个数量级,那么通用 EVM 执行和低成本区块空间,就不再是 L2 独有的优势。到了那时,L2 更需要提供的是 L1 很难统一满足的差异化能力,比如特定场景下的应用优化、隐私能力,以及更灵活的治理和经济设计。

以太坊基金会今年对 L1 与 L2 关系的最新表述,也体现了这种变化。过去,L2 的首要任务是帮助以太坊扩展容量,差异化和定制化更像附加价值;而现在,L2 的定位明显更偏向于提供差异化功能,同时继续贡献额外的扩展能力。

对应地,L1 则需要成为一个足够强大、无需许可且具备高韧性的全球枢纽,承载结算、共享状态、流动性以及 DeFi 活动。

从这个角度理解,L2 已经不再只是一个单一技术标签,而更像是一条连续分布的“光谱”:

  • 一端是尽可能完整继承以太坊安全属性的 Rollup。这类网络希望减少对多签安全委员会的依赖,开放无许可证明机制,并确保即便运营方停止服务,用户也能通过 L1 安全退出;
  • 中间区域则是按业务需求继承部分以太坊属性的执行环境。它们可能拥有更强的管理权限、独立排序器或特定合规设计,以换取性能、隐私和运营灵活性;
  • 另一端则可能只是采用 EVM、使用以太坊资产或接入部分跨链设施,但在安全和结算层面保持较高独立性的链。

所以,说以太坊要“抛弃 L2”并不准确。更贴切的说法是,以太坊正在重新明确 L1 与 L2 的功能边界。在过去 3 到 5 年里,L2 首先是一种扩容技术;而在未来,它更可能代表一组与以太坊建立不同安全、结算和流动性关系的执行环境。

以太坊重新定义L1与L2

二、如何理解以太坊互操作:重点不只是“跨链”,而是状态怎样建立互信

不过,当以太坊逐步演变成一个由大量 L2 组成的系统后,另一个老问题也会变得更突出:L2 越多,流动性、账户状态和应用体验就越容易被切碎。

这点其实很多用户已经亲身感受到了。你可能在一条链上持有资产,在另一条链上使用应用,还要去第三条链上完成交易;同一种稳定币在不同网络里可能对应多个版本;同一个账户还要面对不同的 Gas Token、跨链桥和资产入口。

因此,互操作正在成为以太坊路线图里越来越关键的一部分。

以太坊协议团队已经把 2026 年 Improve UX 路线的重点放在两个方向上:原生账户抽象和互操作。核心目标很明确,就是缓解 L2 碎片化,让以太坊“再次感觉像一条链”。而这一愿景,也与 intent 架构逐渐成熟密切相关。

  • 例如,开放意图框架 Open Intents Framework 允许用户只表达自己想要的结果,比如“把 A 链上的某种资产换成 B 链上的 USDC”,后面的路径计算、垫资、执行和资金再平衡,则交给求解器处理;
  • 再进一步看,以太坊互操作层 EIL 试图构建一个无需信任的传输层,目标是让跨 L2 交互尽可能接近单链交易体验。

在账户层面,Pectra 升级中的 EIP-7702 已经让传统 EOA 能临时执行智能合约代码,从而支持交易批处理、Gas 代付和恢复机制。后续以 EIP-8141 为代表的原生账户抽象方案,则希望把智能账户逻辑进一步嵌入协议层,让智能合约 wallet 逐步成为默认账户形态,并减少对额外 Bundler、Relayer 和中介服务的依赖。

L1 的快速确认规则,则尝试在完整最终确定性到来之前,先在十几秒到几十秒内给出更强的安全确认信号,从而缩短大多数正常场景下的等待时间。这一点会直接影响所有依赖 L1 最终性的跨链应用,对跨链桥、稳定币结算以及 RWA 资产交易都有现实意义。

这里有个很关键、但也很容易被忽视的点:很多跨链交互真正的瓶颈,并不只是“消息能不能发过去”,而是目标链什么时候能足够确信源链状态不会被撤销。

换句话说,一笔交易被打包进区块,并不等于它已经获得最终确定性。对普通用户来说,交易可能几秒后就显示成功;但对桥、交易所、借贷协议和跨链求解器来说,它们仍然需要评估这笔交易被区块重组的概率,以及是否足以据此在另一条链上释放资产或继续执行后续步骤。

这也是为什么,当前不少看起来接近“即时到账”的跨链服务,并不是真的在等待源链完成最终结算,而是由求解器或流动性提供方先行垫付资金。它改善了用户体验,但并没有让底层等待时间真正消失。

以太坊重新定义L1与L2

所以,从长期方向看,以太坊希望把最终确定性从分钟级逐步压缩到秒级。不过,这并不是某个已经排好上线时间的单一升级,而是一组需要分阶段推进的研究任务,包括将最终性投票与分叉选择解耦、优化验证者集合、改进投票聚合和网络传播,并逐步调整共识协议。

总体来看,好的以太坊互操作体验,不只是让几十条链共享一个“跨链按钮”,而是让不同执行环境能够以更快、更低成本的方式信任彼此状态。

三、当以太坊 L1 也开始出现 Rollup 化特征,L1 与 L2 的边界还清晰吗

如果说 L2 定位变化和最终确定性缩短,仍然属于对现有分层结构的重新调整,那么 Barnabé 提出的另一个判断,就更进一步触及了 L1 与 L2 的定义本身:随着证明系统逐步进入以太坊主网,L1 最终也可能在某种意义上成为“自身的 Rollup”。

这句话听起来确实有些反直觉。

通常我们理解的 Rollup,是建立在 L1 之上的扩容网络:它在外部执行交易,再由 L1 验证状态结果。既然以太坊本身就是底层共识和结算网络,它怎么会变成自己的 L2?

要理解这个说法,关键是把“Rollup”从传统层级关系里抽离出来看。在当前以太坊中,节点接收一个区块后,需要重新执行里面的全部交易,独立计算状态变化,并判断区块是否符合协议规则。

这种模式的优点是节点可以独立验证,但代价也很明显:网络整体执行能力必须受限于普通节点的硬件条件。区块里的计算越多,验证者完成执行所需的硬件资源和时间成本就越高。

未来,如果实时证明和 L1 zkEVM 逐渐成熟,情况可能会发生变化。交易仍然可以由高性能执行节点完成计算,但普通验证者不一定还需要亲自重放每一笔交易。比如,执行节点完成计算后生成有效性证明,其他验证者只需要验证体量更小、成本更低的证明,就能确认状态转换是否正确。

从“执行”和“验证”的关系来看,这的确和 Rollup 很相似:一部分参与者负责高性能执行,结果被压缩成密码学证明;更广泛的共识参与者不再重复全部计算,而是通过验证证明来确认最终状态。

因此,Barnabé 所说的“L1 成为自身的 Rollup”,更适合被理解为一种验证模式的概括,而不是说以太坊主网会被放到另一条更底层的链上,或者被“降级”为自己的 L2。

他的核心判断在于,当证明逐渐取代所有节点的重复执行时,Rollup 可能不再只是 L1 之上的层级名称,而会演变成一种更通用的执行与验证架构。

以太坊重新定义L1与L2

这也会进一步模糊 L1 与 L2 之间原本相对清晰的边界。

一方面,L1 可以借助 zkEVM 证明增强自己的执行能力;另一方面,Native Rollup 则希望让 L2 更直接地调用以太坊协议内的验证能力,使 L1 能以更原生、更统一的方式验证 L2 的状态转换。

在当前阶段,不同 Rollup 往往需要自行构建证明系统、验证合约、升级机制和安全委员会。一旦证明系统出现问题、协议需要紧急升级,或者运营方失效,用户通常仍需要依赖额外的治理与信任结构。Native Rollup 的长期方向,则是把部分 Rollup 验证逻辑内化为以太坊原生能力,让 L2 减少自建安全结构,更完整地继承 L1 的状态转换规则,并有机会降低对安全委员会的依赖。

如果再往前看一步,当多个 L2 能依靠更快的 L1 确认、统一的证明机制以及同步可组合性来访问彼此状态,它们和主网之间的关系,可能也不再像今天这样,主要依靠一座座跨链桥来连接。

更准确地说,它们可能更像是同一套以太坊共识之下的多个执行域。其中一些面向通用金融活动,一些服务于游戏、社交或支付场景,另一些则提供隐私或特定合规能力。它们拥有不同的执行逻辑和产品形态,但共同依赖同一套可验证的状态、安全基础和资产结算体系。

当然,这依然是一个长期方向。

但无论这些技术最终以什么形式落地,它们都已经在推动 L1 与 L2 的分界,从一条相对明确的架构边界,逐步转变为不同程度的安全继承关系。

总结:以太坊终局的重点,也许不是拥有更多链,而是重新找回系统整体性

以太坊早期依靠共享状态获得了很强的全局可组合性,后来又通过 Rollup 把执行能力拆分出去,以换取更大的容量。到了今天,它需要回答的问题是:在不否定过去扩容成果的前提下,如何把已经分散的资产、账户和应用重新连接起来。

对普通用户来说,理想中的以太坊,不应该是一张由数十条链、不同 Gas 代币和跨链桥组成的复杂网络图。交易到底在哪里执行、流动性来自哪条链、最终由谁结算,这些细节未来可以更多交给 wallet、应用和底层协议去处理;但其中涉及的信任假设、安全边界和退出路径,也不能因为体验优化而被完全隐藏。

因此,L2 的终局也许既不是取代 L1,也不是被持续扩容的 L1 淘汰,而是成为一组功能和性能各不相同,却能够共享安全、流动性和状态关系的执行环境。

过去,以太坊通过拆分执行换来了更大的容量。

而下一阶段更值得关注的问题是:在拆开之后,它是否还能重新组合成一个更完整的以太坊。

以上内容主要围绕以太坊 L1、L2、Rollup、互操作以及主网扩容方向展开,目的是帮助读者理解相关技术讨论和路线变化,不构成任何投资建议。加密资产与链上基础设施仍然存在技术、流动性和使用风险,参与前应结合自身情况审慎判断。

热门AI工具

更多
豆包大模型

豆包大模型是一款由字节跳动推出的企业级大语言模型服务平台。

二狗PPT
二狗PPT Hot

一款AI演示文稿工具,主要用于专为中式职场打造的AI PPT生成工具,适合需要提升相关任务效率的用户。

火山引擎

火山引擎是一款面向企业的云计算与AI服务平台。

SkildArt
SkildArt Hot

SkildArt是一款AI文本写作工具,一站式 AI 视觉创作平台。

VibeKnow
VibeKnow Hot

一款AI视频创作工具,主要用于全球首个AI知识视频创作平台,文档、文章、网页,一键生成视频,适合需要提升相关任务效率的用户。

DeepSeek

DeepSeek是一款面向对话、写作、编程和推理场景的AI大模型工具。

WorkBuddy

一款AI办公效率工具,主要用于腾讯云推出的AI原生桌面智能体工作台,适合需要提升相关任务效率的用户。

PixTV
PixTV Hot

PixTV是一款面向AIGC内容创作的AI视频生成工具。

Lovart
Lovart Hot

一款面向视觉设计创作的AI设计平台,可通过智能体和画布工作流辅助制作海报、Logo、网页、PPT及其他视觉内容。

相关专题

更多
LLVM自定义Pass怎么写
LLVM自定义Pass怎么写

本专题聚焦LLVM自定义Pass开发,整理Pass类结构、run()方法、PreservedAnalyses、CMake构建、插件注册、-load-pass-plugin加载和测试用例编写流程。

0

2026.09.30

LLVM RISC-V参数配置教程
LLVM RISC-V参数配置教程

本专题介绍LLVM对RISC-V基础ISA和扩展的支持方式,涵盖RV32、RV64、标准扩展、实验性扩展、厂商扩展、-menable-experimental-extensions和版本差异。

0

2026.09.30

LLVM IR中间表示入门指南
LLVM IR中间表示入门指南

本专题整理LLVM IR的核心概念,包括中间表示作用、模块结构、函数、基本块、SSA形式、类型系统和常见语法,帮助新手理解LLVM编译流程中的关键层。

0

2026.09.30

PDF转图片方法
PDF转图片方法

需要把 PDF 页面用于上传、预览、分享或图片归档时,PDF 转图片方法专题整理 JPG/PNG 格式选择、逐页导出、清晰度设置、批量下载和结果检查等流程,帮助用户稳定完成 PDF 图片化处理。

0

2026.09.30

PixTV AI视频生成与无限画布创作
PixTV AI视频生成与无限画布创作

PixTV专题整理AI视频与视觉内容创作相关功能使用教程,涵盖AI生图、视频生成、无限画布、多模型创作、素材管理、声音音乐及视频剪辑等功能,帮助用户快速掌握PixTV从创意到成片的完整制作方法。

0

2026.09.29

Buffalo框架数据库开发全教程
Buffalo框架数据库开发全教程

本专题围绕Buffalo框架数据库开发,讲解database.yml多环境配置、soda与fizz迁移生成回滚、模型结构体标签、增删改查与条件查询、一对多与多对多关联、数据校验、回调钩子、事务处理及原生SQL执行能力。

220

2026.09.23

Buffalo框架路由与请求处理实操指南
Buffalo框架路由与请求处理实操指南

本专题讲解Buffalo框架路由与请求处理机制,涵盖路由注册与分组、资源路由、Handler编写规范、Context上下文方法、参数绑定、中间件编写挂载、Session与Cookie读写、Flash消息及错误页面定制方法。

120

2026.09.23

Buffalo框架零基础入门教程
Buffalo框架零基础入门教程

本专题整理Buffalo框架入门内容,涵盖Go环境准备、buffalo CLI安装、新项目生成、目录结构说明、dev热加载启动、数据库连接配置与常见报错排查,帮助新手按约定优于配置的思路跑通第一个Buffalo框架应用。

100

2026.09.23

Conan创建软件包配方指南
Conan创建软件包配方指南

本专题介绍通过conanfile.py创建软件包的方法,讲解包名、版本、依赖和构建设置等基础信息,以及source、build、package、package_info等常用方法的作用及编写思路。

60

2026.09.22

热门下载

更多
网站特效
/
网站源码
/
网站素材
/
前端模板

精品课程

更多
相关推荐
/
热门推荐
/
最新课程
独孤九贱(6)_jQuery视频教程
独孤九贱(6)_jQuery视频教程

共44课时 | 36.7万人学习

讯飞星火使用攻略
讯飞星火使用攻略

共0课时 | 0人学习

文心AI功能使用
文心AI功能使用

共0课时 | 0人学习

关于我们 免责申明 举报中心 意见反馈 讲师合作 广告合作 最新更新
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号
PHP中文网订阅号
每天精选资源文章推送

Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn