跳到主要内容

Glamsterdam 推迟：以太坊 MEV 改革因 ePBS 进度滞后而面临工程现实挑战

· 阅读需 13 分钟
Dora Noda
Dora Noda
Software Engineer

在以太坊加速推进的 2026-2027 年分叉节奏中，路线图首次出现了动摇。2026 年 4 月中旬，核心开发者公开承认了客户端团队已私下传达数周的消息：协议内提议者-构建者分离（ePBS）—— Glamsterdam 硬分叉中最具野心的核心部分 —— “比预想的更棘手”，原定于 5 月至 6 月的主网窗口期几乎肯定无法实现。这次推迟将 Glamsterdam 推向了 2026 年第三或第四季度，缩小了与已排期的 Hegota 分叉之间的间隙，并重新引出了一个以太坊本以为已经解决的问题：在 Pectra 之后的 L2 经济需求下，基于五个客户端的底层网络是否还能保持原有的升级节奏？

这个问题的答案其影响远超以太坊自身的生态系统。ePBS 在开发网（devnet）中每多待一周，现有的 Flashbots 中继寡头垄断就会多掌控一周每年数百亿美元的 MEV 流量，L2 就会多在一周内根据本应由分叉缓解的供应曲线为 blobs 定价，而 Solana —— 它在 2025 年 9 月为其 Alpenglow 共识大修锁定了 98.27% 的验证者支持率 —— 将在可衡量且更快的单体升级节奏上进一步扩大领先优势。Glamsterdam 从来不仅仅是又一个硬分叉。它是以太坊对“快速 L1”论调的回应。而现在，这个回应迟到了。

定义 Glamsterdam 的两个 EIP​

Glamsterdam —— 是 Gloas（共识层代号）和 Amsterdam（执行层代号，遵循以 Devcon 主办城市命名的传统）的合称 —— 由两个头牌 EIP 支撑，它们将共同重塑以太坊产出区块的方式。

EIP-7732 (ePBS) 在协议层面将共识区块与执行区块分离。目前，运行 MEV-Boost 的验证者通过中心化中继将区块构建交给协议外的构建者市场。Flashbots 在 2024 年 12 月将其所有构建者和订单流迁移到 BuilderNet，这本身就承认了中继架构存在中心化风险。ePBS 将这种分离原生化：提议者和构建者成为协议的一等参与者，直接进行交互，无需中继。

EIP-7928（区块级访问列表） 要求区块预先声明其读写足迹 —— 即涉及的账户和存储槽。客户端随后可以并行化执行和验证，从而缩短区块传播的时间。与 ePBS 结合使用，这两者旨在将有效区块延迟降低约 50%。

在理论上，这些提案相辅相成。但在实现过程中，它们正以原始规范未完全预见的方式，与 Pectra 之后的其他组件（包括已在 Pectra 中交付的 EIP-7251 MaxEB 验证者合并）发生交互。

究竟是什么进度落后了​

2026 年 4 月 16 日的全核心开发者共识会议（ACDC #177）揭示了工程现实。直到本月，测试仍分在两个独立的网络中进行：用于提议者-构建者分离的 epbs-devnet 和用于访问列表的 bals-devnet。合并这两者的“通用开发网（generalized devnet）” —— 即所有 Glamsterdam 组件共存的第一个环境 —— 直到 Lighthouse 和少数其他共识客户端在 4 月的互操作窗口期间产出稳定版本后才获准启动。

“ePBS Devnet Zero 与其说是为了性能，不如说是为了互操作性，”一位客户端工程师在会议总结中指出。翻译一下：我们仍在探索当五个共识客户端和五个执行客户端各自独立解读规范时，会发生什么故障。早期运行产生的多为空块 —— 这不是结构性缺陷，而是一个信号，表明即便是正常路径也仍在铺设中，更不用说应对攻击路径了。

时间线的影响是连锁的：

  • Devnet Zero 必须在共识侧的 Lighthouse、Prysm、Teku、Nimbus 和 Lodestar，以及执行侧的 Geth、Nethermind、Besu、Erigon 和 Reth 之间实现稳定。
  • Devnet One 和 Two 需要发现 ePBS、BALs、Gas 调价以及正在考虑的 25 多个非核心 EIP 之间的交互漏洞。
  • 公共测试网（Holesky 的继任者、Sepolia）在能够可靠设定主网日期之前，至少需要 6-8 周的影子分叉活动。
  • 客户端版本 必须进行削减、审计并分发给质押者，并留出足够的缓冲时间，以确保主网上的分叉选择问题不会演变成活跃性事故。

每一步都以周而非天来衡量。5 月至 6 月的发布要求 Devnet Zero 在 2 月份就保持稳定。但事实并非如此。6 月至 7 月的要求是 3 月份稳定。但事实并非如此。到 4 月，时间账目已经无法对齐 —— 因此大家低调承认，这个头牌分叉将推迟到 2026 年下半年。

客户端多样性悖论​

以太坊的五个执行客户端多样性可以说是其最具价值的、公信中立的属性 —— 单个客户端的 bug 不会导致网络瘫痪。但这种多样性也是 Glamsterdam 如此困难的原因。

每个实现团队必须独立构建、测试并稳定 ePBS。每个团队都会发现不同的边缘情况。4 月 ACDC 会议纪要描述了多个客户端的“待处理拉取请求（pending pull requests）”，并指出共识规范的更改可能会完全阻塞 ePBS Devnet Two，直到问题解决。这正是单实现链无需支付的协调成本。

对比一下 Solana 的节奏。Alpenglow 是 Solana 的共识替代方案，目标是 100-150 毫秒的确定性终局性，它在 2025 年 9 月以 98.27% 的支持率通过了验证者投票 —— 这是该网络历史上最强大的授权之一。推出计划很简单：Anza 的 Agave 客户端在 2026 年第三季度交付升级；随后是 Jump Crypto 的第二个实现 Firedancer。因为 Solana 在今年早些时候 Firedancer 超过 20% 的主网质押份额之前，实际上只有一个生产客户端，其协调面只是以太坊的一小部分。

这并非中立的观察。单体链交付更快，多客户端链交付更安全。Glamsterdam 的推迟是以太坊架构选择的代价 —— 而自合并（The Merge）以来，市场第一次在权衡这个代价是否仍然值得支付。

延迟对 L2 和 MEV 意味着什么​

Pectra 分叉已于 2025 年按计划发布。紧随其后的 Fusaka 增加了 PeerDAS 并扩展了 blob 容量。L2 团队围绕 Glamsterdam 在第二季度落地制定了 2026 年的容量计划，并期待通过进一步的 blob 扩展和 MEV 重新分配来满足激增的 rollup 需求。

这些计划现在需要重新制定。

Blob 定价。 Glamsterdam 原本预计将进一步提高每区块的 blob 数量——可能达到 72 个或更多——为 optimistic 和 ZK rollup 提供显著更多的廉价数据可用性。推迟到第三至第四季度意味着 blob 供应紧张的情况将多持续 2-4 个月，这对于已经饱和其费用通道的 rollup 来说至关重要。

MEV 重新分配。 今天的 MEV-boost 架构给大型构建者带来了不成比例的回报。订单流聚合的超线性回报意味着，一旦构建者确立了领先地位，经济规律就会推动其走向垄断。ePBS 并没有消除 MEV，但它移除了中继器这一协调瓶颈——理论上，这应该将目前提取的一小部分收益重新分配给提议者，并进一步流向质押者。延迟的每一个月，都是现有 MEV 动态持续的一个月。

L2 竞争。 Base 已经实现了 2 秒的区块时间。Arbitrum 和 Optimism 正在以独立的节奏发布各自的排序器和数据可用性（DA）改进。L1 瓶颈持续的时间越长，L2 的路线图就越偏离统一的 L1 升级——“以 rollup 为中心的路线图”就越会变成 N 个独立的 rollup 路线图，只是碰巧在同一个基础层进行结算。

FOCIL 问题与 Hegota 挤压​

4 月 ACDC 最重大的决定之一是将分叉选择包含列表（FOCIL）移出 Glamsterdam 并放入 Hegota，FOCIL 已被正式选定为 2026 年底共识层的核心特性。

FOCIL 是以太坊对抗审查的方案——这是一种允许提议者委员会集体强制包含交易的机制，从而使单个构建者无法系统性地排除有效载荷（例如 OFAC 制裁的地址）。Base 工程团队 曾公开警告，将 FOCIL 与 ePBS 捆绑在一起会使 Glamsterdam 完全推迟到 2026 年之后。将其剥离为 Glamsterdam 争取了时间——代价是压缩了 Glamsterdam 最终主网激活与 Hegota 激活之间的时间窗口。

如果 Glamsterdam 在 2026 年第四季度发布，而 Hegota 的目标是第四季度晚些时候，那么间隔可能短至 6-8 周。对于验证者、区块构建者、质押服务商和 L2 团队来说，在下一次协议更改到来之前，消化上一次更改的时间窗口非常短。Hegota 路线图 还包括重大的状态膨胀处理工作——早期讨论集中在 Verkle 树上，这虽然能降低节点硬件要求，但需要进行大量的测试。

以太坊目前正在悄悄规划的场景是：一个季度内落地两个重大分叉，而这种测试矩阵通常是 Solana 在单次协调发布中完成的。

为什么这还不是危机——暂时​

将 Glamsterdam 的推迟解读为生存危机是错误的。以太坊的分叉流程正完全按照设计运行。ePBS 被推迟并不是因为协调失败，而是因为协调在问题到达主网之前发现了问题——即规范模糊和实现的边缘情况。另一种选择是按期发布，然后在主网处理价值 4000 亿美元以上的实时分叉选择错误，那情况会糟糕得多。

更深层次的问题是，随着每个分叉复杂性的增加，以太坊目前的节奏是否可持续。Glamsterdam 不仅仅是两个 EIP；它是两个核心功能加上 25 个以上的小改动，每个改动都与 Pectra 之后的验证者集相互作用，而这个验证者集已经拥有了 maxEB 整合、启用 PeerDAS 的 blob 以及其上的成熟 L2 生态系统。每一个新的分叉都让测试矩阵变得更庞大。

拆分 Glamsterdam 本身的提案（如在第三季度发布 BALs，在 2027 年第一季度发布 ePBS）已经提出，但到目前为止已被拒绝。反对方的理由很有说服力：没有 ePBS 的 BALs 带来的价值微乎其微，因为并行执行的收益受到当前构建者架构的制约。这些功能是互补的，拆分它们虽然节省了进度，但却以牺牲升级的连贯性为代价。

未来 90 天值得关注的事项​

对于开发者、质押者以及任何为 2026 年下半年 L2 区块空间定价的人来说，有三个信号至关重要：

  1. Devnet Zero 的稳定性。 如果通用的开发网（Devnet）到 6 月初能连续运行 30 天以上且未发生重大事故，那么 2026 年第三季度的目标就变得可信。否则，第四季度将是底线。
  2. 公共测试网激活。 Holesky 的继任者和 Sepolia 需要在主网分叉前至少 8 周进行分叉。没有测试网分叉日期 = 没有主网分叉日期。
  3. Hegota EIP 选择。 2026 年 2 月确定的 Hegota 核心特性是 FOCIL；执行层的核心特性仍在讨论中。无论选择什么，都将进一步限制这两个分叉序列的紧凑程度。

以太坊 2026-2027 年的路线图一直充满雄心。Glamsterdam 的推迟是第一个具体的提醒：雄心勃勃并不意味着准时。对于一个信誉建立在谨慎处理难题之上的网络来说，有节制的延迟并不是失败。它是其特性。

BlockEden.xyz 在 Pectra、Fusaka 以及每一个预演 Glamsterdam 分叉规则的测试网上运营企业级以太坊基础设施。如果你正在针对不断变化的升级目标进行开发，并且需要并行跟踪主网、测试网和开发网的节点，探索我们的以太坊 API 服务 —— 为那些无法承受在规范变更中站错分叉状态的团队而设计的后端基础设施。

来源​

Share on Twitter