以太坊的路线图，为什么不是一张时间表？

以太坊已经在生产环境里承载资产、合约与应用。它不能停机重装，也没有一家公司可以关掉旧版、 一夜切换到“Ethereum 2.0”。每次改变都必须让多个执行客户端、共识客户端、节点运营者、 验证者、应用和基础设施，在预定区块或时刻对同一套新规则达成社会与技术共识。

因此，“The Merge / Surge / Verge / Purge / Splurge”首先是意图桶： 每个桶收纳一组相近的问题与长期目标。研究团队会并行工作；一场网络升级也常把多个桶里的 改动打包在一起。名称帮助人类思考，却不是协议自己认识的版本号。

用 EIP-4844 做一次词汇拆分

“给 Rollup 更便宜的数据空间”属于 Surge；定义 Blob 交易的是 EIP-4844；把它与其他改动一起带到主网的是 2024 年的 Dencun 网络升级；让节点正确处理它的是多个执行层与共识层 客户端版本。四句话说的是同一历史链条的四个不同层次。

这套分层还能解释“为什么一场升级横跨多个阶段”：Pectra 同时包含账户、质押与 Blob 容量相关改动；不能把它只塞进 Splurge、Merge 或 Surge 中任意一个抽屉。

它完成了什么？

• 从 PoW 转向 PoS：矿工退出主网共识，验证者以质押参与出块与证明。
• 能耗大幅下降：ethereum.org 给出的估计约为 99.95%。
• 建立后续共识改进的基础：执行与共识职责明确分层。

它没有做什么？

• 没有直接扩大 L1 区块容量，所以不是一次降 Gas 费升级。
• 没有创建“新 ETH”，也不要求普通持币者换币或迁移钱包。
• 没有把所有 PoS 设计一次定稿；快速最终性、独立质押与攻击恢复仍可改进。

为什么同名工作流还在继续？

Vitalik 在 2024 年把 The Merge 的后续目标概括为：单时隙最终性、更快确认与最终确定、 改善独立质押可行性、提高稳健性，以及增强对 51% 攻击的抵御和恢复能力。这说明 “Merge 事件完成”与“Merge 工作流完成”是两件事。

2024 年的路线图阐述给出一个醒目的长期目标：L1 + L2 合计达到 100,000+ TPS， 同时保持 L1 去中心化与稳健，让至少一些 L2 真正继承 Ethereum 的开放、无须信任和抗审查属性， 并让跨 L2 体验最终像同一个生态，而不是几十条割裂的链。

这里最重要的词是“同时”。若只提高吞吐，却迫使验证节点使用数据中心硬件，扩容会侵蚀底层的 自我验证能力；若 L2 很快，却依赖中心化升级密钥、不可用数据或无法退出的桥，它也没有完整继承 L1 安全。

PoS 可以在密码学上安全，却仍受到经济结构的集中化压力：大型质押池可能因规模经济占优， 专业区块构建者可能控制交易排序，MEV 可能把价值从用户转给少数中介，审查也可能发生在交易 进入区块之前。Scourge 的目标正是降低这些风险与过度价值提取。

它与其他工作流交叉：更轻的节点有利于个人质押者；更大的区块会提高专业构建者优势； 快速最终性需要与区块构建流程共同设计。因此它不是在五条轨道之后追加的“第六阶段”， 而是一条贯穿多处的可信中立约束。

区块链与中心化数据库的关键差别，不只是数据由很多机器复制，而是参与者可以独立拒绝违反规则的链。 如果完整验证只能由少数大型运营者完成，其他人只能信任 RPC 返回的答案，这项能力就会空心化。

“Verge”最初几乎等同于把状态树换成 Verkle Tree，用更紧凑的见证支持无状态验证。 到 2024 年，其范围已扩展为更大的“低资源验证”愿景：无状态客户端、执行有效性证明、共识有效性证明， 以及能否直接转向对后量子路线更友好的二叉树与 STARK 方案。

无状态，不等于“链上没有状态”

合约余额与存储当然仍存在。所谓无状态验证，是验证者不必在本地永久保存完整全局状态； 出块者随区块附上本次访问状态的见证，验证者从旧状态根检查成员关系、执行转换并得到新状态根。

Verge 与 Purge 最容易混在哪里？

当前区块通过哈希、状态根和其他承诺连接到过去。验证某个旧区块或旧交易时， 你不必让每个共识参与者都保存一份副本；只要能从至少一个来源取回数据，再用承诺与证明验证即可。 这把“全网对当前状态达成共识”与“谁长期提供旧历史”拆成了不同问题。

但这不意味着可以先删除、以后再说。如果旧历史只剩少数中心化供应商，永久性与抗审查会受损。 因此历史过期必须与 Portal Network、归档节点、分布式存储、标准文件格式和可验证取回路径一起考虑。

这条工作流的长期目标包括：把 EVM 带到高性能、稳定的终局形态；把账户抽象更深地纳入协议， 让安全恢复、批量操作与 Gas 代付不再依赖额外中介；优化交易费用经济；探索可能改变长期能力边界的密码学。

“Splurge”听起来像随意加功能，但真正的约束恰恰是兼容性与简洁性。 Ethereum 上有多年部署的不可升级合约，EVM 的每个变化都可能影响编译器、调试器、证明系统、L2 与安全假设。

EIP-7702 为什么只是“桥”，不是终点？

它让现有 EOA 可以授权代码处理交易，从而支持批量调用、Gas 代付与恢复等体验， 同时保留现有地址。但完整原生账户抽象还要解决交易格式、mempool、抗拒绝服务、 包含保障、费用与验证逻辑如何直接进入协议。2026 年官方工作重点已继续讨论 EIP-7701 与 Frame Transactions 等更深层方案。

2026 年，实际研发团队用什么词组织工作？

Ethereum Foundation 的 Protocol 团队在 2026 年把重点重新组织成三条执行轨道： Scale、Improve UX、Harden the L1。 这是团队协作与近期交付的视角，不是把 Merge / Surge 等长期意图从历史上“删除”。

研究者提出机制，EIP 作者把它写成规范，客户端团队判断能否安全实现， 测试与安全团队寻找故障，应用与基础设施反馈兼容性，节点运营者最终选择运行什么软件。 核心开发者会议能协调升级范围与时间，却不能像公司董事会一样单方面强迫全球节点升级。

这也解释了路线图为何会改变：Rollup 的发展让原计划中的执行分片转向数据分片； Verkle Tree 曾是 Verge 的中心，后来二叉树与 STARK 方案变得更有吸引力； 安全与集中化问题被从 Merge 等桶中抽出，形成 Scourge。

1. 它解决什么具体瓶颈？ 是执行、数据、验证、状态、历史、MEV、账户还是费用？
2. 它处在哪个生命周期？ 研究草案、EIP、客户端原型、devnet、测试网、已排期还是已激活？
3. 谁多做了什么，谁少做了什么？ 出块者、验证者、普通节点、L2、证明者与用户的负担如何转移？
4. 它保护了什么，又引入什么新信任？ 去中心化、可用性、抗审查、兼容性与复杂度如何变化？
5. 状态与日期从哪里来？ 优先核对规范、客户端发布、测试网公告与 ethereum.org，并记录核对日期。