以时间换容量:Glamsterdam 如何重写以太坊的验证时钟

以太坊验证时钟的编辑插画

头图将 Glamsterdam 呈现为一次“何时完成验证”的重构,而不只是“一个区块能塞进多少交易”的扩容。

研究日期:2026 年 10 月 9 日

执行摘要

以太坊 Glamsterdam 升级在 10 月 6 日跨过了一个关键门槛:按照既定计划,它于 UTC 13:53:36、epoch 353,024、slot 11,296,768 在 Sepolia 测试网激活。这一节点的意义,并不在于为又一次硬分叉开启倒计时,而在于一套新型扩容架构首次进入公共网络环境。Glamsterdam 由执行层 Amsterdam 与共识层 Gloas 组成;两项核心变化——协议内置的提议者—构建者分离(ePBS)与区块级访问列表(BAL)——重新安排区块的生产、传递与验证。与之配套的 gas 重定价,则试图让资源计费足够诚实,使容量提升不至于把隐性成本转嫁给节点运营者。

本报告的核心判断是:Glamsterdam 真正押注的是验证余量。它不是单纯追求每个区块执行更多交易,而是把共识与执行载荷交付拆开,把状态依赖显式化,并让状态密集型操作的价格更接近实际成本。这三者共同把一个串行、时间高度压缩的验证流程,改造成分阶段且更易并行的流程。与孤立提高 gas 上限相比,这是一条更可持续的 L1 扩容路径。

代价同样真实。ePBS 把构建者经济活动带入共识,增加角色、接口和故障模式,并把广泛的执行验证延后到下一时隙。BAL 会增加区块数据,还可能诱导客户端进行无效预取,因此必须有严格边界。gas 重定价可能使依赖旧有固定 gas 假设的合约失效。更重要的是,Sepolia 激活证明的是实现已经成熟到可以公开检验,而不是主网上线已经确定。以太坊基金会公告截至本报告日期仍将 Hoodi 和主网时间列为待定。

因此,对机构、应用团队和基础设施运营方而言,合理结论应当克制:Glamsterdam 增强了“以太坊能在不放弃广泛可验证性的前提下扩大基础层”的可能性,但也改变了区块构建、确认与 gas 安全的操作含义。眼下最合适的做法既不是提前庆功,也不是过度警报,而是持续观察公共测试网的客户端多样性、载荷可用性、构建者集中度与合约兼容性。

Sepolia 上究竟发生了什么

此次公共测试格外重要,因为各组件并非各自为战。官方公告将 ePBS 与 BAL 定义为提高 L1 吞吐量、同时维持节点可验证性的基础。两者的组合才是重点:ePBS 为关键路径争取时间;BAL 为客户端提供区块触及哪些状态的地图;重定价则避免这张地图演变为对磁盘和状态资源的无价承诺。

阶段

2026 年 10 月 9 日状态

能证明什么、不能证明什么

多轮开发网与专项测试

已完成多个迭代

规范和多客户端实现在受控环境中可以互操作。

Sepolia 激活

计划于 10 月 6 日 13:53:36 UTC、slot 11,296,768 激活

公共测试网开始检验分叉边界和分叉后行为;这不是主网性能保证。

Hoodi 激活

待定

面向验证者的演练仍是质押与构建者基础设施的重要关卡。

主网激活

待定

不能虚构日期,也不能把“计划纳入升级”写成“已生产部署”。

这个区分并非措辞游戏。以太坊升级是节点运营者主动更新软件的协调事件;未实现新规则的节点无法继续跟随升级后的链。基金会公布的 Sepolia 版本矩阵覆盖多个共识层和执行层客户端,但“已有软件发布”不等于“在主网负载与对抗环境下运行稳定”。公共测试正是时序假设、替代中继的新接口以及资源上限第一次在非受控环境中碰面。

flowchart LR
    A[多轮 Glamsterdam 开发网] --> B[Sepolia 激活<br/>2026 年 10 月 6 日]
    B --> C{观察公共网络表现}
    C --> D[客户端互操作性]
    C --> E[载荷交付与时序]
    C --> F[Gas 与合约兼容性]
    D --> G[决定 Hoodi 安排]
    E --> G
    F --> G
    G --> H{主网就绪评审}
    H -->|证据充分| I[安排主网激活]
    H -->|仍有问题| J[修订、复测或延期]

ePBS:把既有市场带进协议

现实中的以太坊早已有提议者—构建者分离。验证者普遍把执行载荷的构建交给专业构建者,并由中继完成双方交换。这一结构催生了竞争性的区块构建市场,却也让受信任中间件进入关键路径。处于“Last Call”阶段、截止日为 2026 年 11 月 1 日的 EIP-7732,把这项交换正式写入共识。

在 ePBS 下,提议者在信标区块中放入构建者签名的承诺,而非完整执行载荷;构建者随后揭示承诺中的载荷。载荷及时性委员会判断载荷及相关 blob 数据是否按时到达,协议则处理构建者向提议者付款的逻辑。构建者由此成为需要质押的协议实体。其目标是在没有受信任中继完成“货款交换”的情况下,让诚实提议者获得报酬,也让诚实且及时揭示的构建者载荷得到协议承认。

扩容收益来自时间重排。现行流程把大量工作压在时隙早段:接收区块、执行载荷、检查数据可用性、更新共识状态并投票。EIP-7732 将完整执行验证移出最紧张的投票前窗口。其设计说明称,下一位提议者可获得 6 秒,其他验证者可获得 9 秒来验证执行载荷。它并没有让执行本身变便宜,而是给执行一个更宽松的截止时间,并让完整载荷退出共识区块最关键的传播路径。

sequenceDiagram
    participant U as 交易用户
    participant B as 已质押构建者
    participant P as 信标区块提议者
    participant T as 及时性委员会
    participant V as 验证者
    U->>B: 交易与交易包
    B->>P: 签名的载荷承诺与报价
    P->>V: 携带承诺的信标区块
    B-->>T: 揭示执行载荷与 blob 数据
    T-->>V: 证明数据及时可用
    V->>V: 在扩展窗口内验证执行
    Note over P,V: 共识与执行验证被分阶段,而非被取消

这是结构性改进,但“协议内置”不等于“一纸规范实现去中心化”。高级构建者仍会从专有订单流、低延迟网络和资本优势中获益。协议可以减少支付与交付交换中的中继信任,却不会自动创造多元构建者市场。机构应区分机制风险与市场结构风险:Glamsterdam 能降低前者,后者仍取决于竞争、开放接口和透明监测。

确认语义也会发生细微变化。EIP-7732 指出,在时隙 N 纳入的交易,要等到下一位提议者在其上构建区块、且下一时隙验证者投票之后,才得到广泛的执行验证。因此,“已经看到”“数据可用”“执行已验证”“经济终局”是不同状态。即使交易所或跨链桥的正式终局策略不变,把这些状态压缩成单一“确认”标签的产品也应重新审视风险表述。

区块级访问列表:让隐藏的状态工作变成共享地图

如果说 ePBS 买来时间,BAL 的目标就是更有效地利用这段时间。以太坊执行很难并行,因为客户端事先不知道交易会触及哪些账户和存储槽。过去可选的交易级访问列表无法提供完整且强制的地图。EIP-7928 同样处于 Last Call 阶段,它要求每个区块携带规范化记录,列出被访问的状态位置以及交易后的状态变化。

这份记录支持多种并发处理:客户端可以从磁盘预取状态,并行验证相互独立的交易工作,并行计算交易后状态根,并在某些场景下无需逐笔重执行即可重建状态变化。对机构而言,最重要的理解是 BAL 本身不是面向用户的“加速按钮”,而是一层让大区块不至于显著加重验证负担的基础设施。

EIP 附带的实证分析抽取了 100 个历史主网区块。在包含存储读取的配置下,BAL 原始大小平均为 91.3 KB,范围为 25.1–164.8 KB,压缩后平均为 42.7 KB。这些数字只适用于特定样本和规范版本,不能被包装成普遍生产开销。但它们清楚展示了交换关系:以太坊增加一个规模适中的显式数据对象,以换取把原本隐藏且昂贵的状态依赖暴露给并行客户端流水线。BAL 大小分析还发现列表大小与唯一账户数量高度相关,这有助于建立资源边界。

时间、可见性与计费组成的三部分扩容交换

Glamsterdam 的三个组件各自解决不同约束;缺少任意一项,安全提高容量的论证都会变弱。

BAL 也带来攻击面。恶意区块生产者可能声明不必要的存储读取,迫使客户端做无效 I/O,直到执行后期才发现问题。EIP-7928 明确讨论“虚假存储读取”,并对列表项目数量设限。这提醒我们:发布元数据不会自动带来安全并行;元数据本身成为共识关键输入后,也必须有确定性、尺寸边界,并能低成本拒绝畸形输入。

重定价:扩容中最不讨喜、却最关键的部分

只有当 gas 能大致反映节点真实消耗时,更高 gas 上限才安全。如果某类状态操作长期定价不足,扩大容量只会放大名义区块限制与实际 CPU、内存、磁盘或带宽成本之间的偏差。Glamsterdam 的重定价提案调整状态创建与访问成本,让协议计费更贴近物理工作量。

以太坊基金会的重定价影响评估称,对历史交易重放后,绝大多数合约未受影响;少量合约可能因为依赖固定 gas 假设而失效或性能下降,多数已标记问题可通过提高调用时提供的 gas 上限修正。这个结果令人宽慰,却不能扩展成“普遍兼容”的保证。硬编码 gas 补贴、依据剩余 gas 分支执行、或缓存旧常量的合约,可能以常规业务逻辑测试难以覆盖的方式失败;钱包与 RPC 服务商也必须更新估算逻辑。

这可能是整套升级最缺少传播吸引力、却最能体现治理可信度的部分。可持续扩容有时要求提高历史上过于便宜的操作价格,即使平均交易费总体下降。一条可信的基础链必须能够告诉应用:旧的资源补贴已经结束。否则,名义吞吐量的提升由节点运营者埋单,最终以硬件集中化的形式反噬网络。

对投资与运营的含义

对普通 ETH 持有者而言,Sepolia 激活无需操作,基金会也明确表示主网将另行公告。但对在以太坊上构建业务的机构,尽调问题已经改变。

首先,应把执行容量视为系统结果,而不是单一 gas 上限数字。高目标只有与区块传播、漏块、载荷可用性、状态增长和独立节点硬件分布一起考察才有意义。Sepolia 擅长暴露功能故障;Hoodi 与接近主网的负载测试更能反映验证者运营现实。

其次,区块构建者集中度依然重要。ePBS 让提议者与构建者的交换更少依赖信任,也可能让构建者这一角色更稳定、更制度化。分析者应跟踪胜出构建者分布、载荷失败或扣留、报价集中度,以及小型构建者能否负担质押与连接要求。协议可以强制公平交换,却无法保证市场公平。

第三,应用必须把 gas 行为当作外部依赖。基金会提供了重定价影响检查器,但没有被列入风险名单并不等于安全。历史重放无法覆盖未来所有调用路径。高价值协议需要特别测试固定 gas 外部调用、转发器、多签执行、清算机器人和跨链消息。

第四,确认政策需要更精确的词汇。坚持等待终局的交易所可能几乎无需改变政策,而低延迟跨链桥或交易系统会关心载荷揭示与广泛执行验证之间的时间差。风险团队应把控制措施映射到新的事件序列,而不是假设“区块”始终代表所有参与者在同一时刻完成的一次原子观察。

反方观点与故障模式

最强的反对意见是复杂度。以太坊正在用一个包含构建者注册、承诺、载荷投票和异步付款效果的丰富共识机制,替代协议外供应链。复杂度可以降低可见的信任依赖,却增加实现和规范风险。多客户端只有在边缘情形解释一致时才真正构成安全优势。

EIP-7732 本身记录了令人不安的情形:理性的构建者可能在扣留载荷有利可图时选择不揭示,造成空时隙并损害用户体验;规范讨论了可变惩罚作为缓解方案。它也分析委员会重复投票和构建者安全假设。这些问题并不构成否决 ePBS 的理由,却足以说明一次公共测试网激活无法终结安全论证。

第二个反对意见是 BAL 开销可能吞噬其释放的部分容量。列表会增大区块,需要生成与验证,还可能招致对抗性 I/O。对此不能只靠理论回答,而应测量真实和恶意负载下的列表大小、传播开销、执行时间以及不同客户端资源占用。所谓并行执行收益必须跨客户端验证。

第三种质疑认为 L1 扩容会削弱以 rollup 为中心的路线。这是一个伪二选一。Fusaka 的 PeerDAS 工作扩大了 L2 所需的 blob 容量;Glamsterdam 则改善基础层执行与验证。便宜而稳健的 L1 结算对证明、跨链桥和高价值交易仍是 rollup 的补充。真正的约束始终是:扩大 L1 时,是否还能让多样化运营者独立验证链。

最后,治理状态仍是暂定的。研究日期当天,两项核心 EIP 都标为 Last Call,主网安排也尚未公告。负责任的基线假设应当允许规范、客户端代码和时间表随着新证据继续变化。

接下来应观察什么

最有信息量的指标来自运营,而非宣传:

  1. Sepolia 分叉后,各主流执行层与共识层客户端组合是否持续稳定;

  2. ePBS 下的载荷揭示成功率、空时隙行为与时间分布;

  3. 不同客户端的 BAL 大小、传播开销、磁盘 I/O 节省与最坏情形;

  4. 可归因于重定价或过期 gas 估算器的合约和交易失败;

  5. 构建者参与广度与胜出载荷集中度;

  6. Hoodi 的正式安排,以及更晚才应单独公布的主网日期和客户端版本矩阵。

结论

Glamsterdam 的价值在于系统逻辑。以太坊识别出,瓶颈不仅是协议允许多少计算,还包括有多少验证工作被挤进一个时隙最狭窄的阶段。ePBS 拉长验证时间线并把构建者交换纳入协议;BAL 暴露并行工作所需的状态足迹;重定价使资源许可与实际成本重新对齐。这套组合追求的是让更大的区块仍然容易验证,而不只是让它在规则上有效。

因此,Sepolia 激活是一个有分量的证明点,却只是公共证据阶段的开端。若主网升级最终成功,它会强化以太坊在保持中立和广泛验证的同时提高 L1 容量的主张;若仓促上线,则会损害同一主张。截至 2026 年 10 月 9 日,最合理的判断是审慎乐观:架构以一致方式回应了真实瓶颈,规范也没有隐藏风险,而决定性证据现在必须来自运行,而不是愿景。

直接来源