Glamsterdam 的真正赌注：以控制面升级扩容以太坊，而不只是扩大区块空间

Glamsterdam 三项扩容控制的编辑示意图

Glamsterdam 把区块市场重构、执行依赖地图与长期状态预算放进同一套升级。图中的数字是测试参数和工程目标，并非主网容量承诺。

执行摘要

以太坊下一次升级即将进入更关键的验证阶段。Glamsterdam 已于 2026 年 10 月 6 日在 Sepolia 激活；以太坊基金会（EF）随后宣布，Hoodi 测试网计划于 10 月 26 日 17:42:48（UTC）激活升级，并在同一时点把 Hoodi 的 gas 上限提高到 2 亿。主网激活日期尚未确定。 这一区别至关重要：Hoodi 即将进行的是取证式压力测试，不是生产环境承诺。官方公告还要求 Hoodi 节点运营者升级执行层与共识层客户端；普通主网用户和 ETH 持有者现阶段无需操作（EF Hoodi 公告）。

这次升级的意义远不止 gas 上限。Glamsterdam 试图重构以太坊的“控制面”——即协议如何分配出块职责、验证时间、状态依赖和长期存储成本。三项相互支撑的核心是：协议内置的提议者—构建者分离（ePBS）、区块级访问列表（BAL），以及针对状态创建与访问的 gas 重定价。

本文的核心判断是：评价 Glamsterdam 不应盯住单一吞吐数字，而要看整套设计能否在增加容量的同时，不把代价暗中转嫁为中继信任、验证延迟或硬件中心化。架构方向值得期待，但风险只是迁移，并未消失。ePBS 能降低对受信中继的依赖，却提高共识复杂度；BAL 能让数据读取和状态计算更易并行，却增加新的传播与实现义务；重定价可约束数据库膨胀，也会改变部分合约依赖旧 gas 规则形成的经济和行为假设。因此，机构、Rollup 和基础设施运营者最合理的态度是“有条件的信心”：Sepolia 已完成，Hoodi 是下一场受控试验，主网准备度取决于多客户端稳定性，以及三项机制能否协同工作的公开证据。

截至 10 月 17 日，升级走到了哪里

Glamsterdam 是执行层 Amsterdam 与共识层 Gloas 的合称。升级范围已经冻结，但 Ethereum.org 明确提醒，汇总升级范围的 Meta EIP 仍处于草案状态，主网上线前细节仍可能变化（Ethereum.org 概览）。因此，报道时间表必须严格区分事实与预期：Sepolia 激活已经发生；Hoodi 已排期但尚未发生；主网日期仍待决定。路线图中的“预计 2026 年第四季度”不能等同于主网激活公告。

timeline
    title 截至 2026 年 10 月 17 日的 Glamsterdam 验证路径
    2026 年 10 月 6 日 : Sepolia 完成激活
    2026 年 10 月 16 日 : 官方公布 Hoodi 排期
    2026 年 10 月 26 日 : Hoodi 计划激活
                         : Hoodi gas 上限提升至 2 亿
    主网日期待定 : 尚无最终决定
                 : 需等待独立官方公告

这条分阶段路径体现了以太坊治理最务实的一面。网络升级不是由某个中心按钮开启；节点运营者通过安装兼容软件，主动接受新规则。不理解新规则的节点无法继续跟随升级后的链。测试网因而不只是部署彩排，还要暴露规范文字无法覆盖的问题：独立客户端之间的分歧、跨地域验证者的时序故障、极端工作负载以及运维假设。

Hoodi 尤其关键，因为 ePBS 跨越共识与执行的边界。EF 4 月的开发进度报告直言其难度：两个参与方在共识内部依次行动，协议必须处理分歧、负载缺失和“部分区块”，变化几乎触及整个技术栈（EF Checkpoint #9）。Sepolia 平稳过叉是积极信号，却不足以证明系统能在持续、对抗性且多样的流量下承受 2 亿 gas 环境。

第一支柱：把出块交接写进协议

以太坊出块早已出现角色专业化：构建者组装有价值的执行负载，提议者选择区块。此前，这个市场的大部分协调发生在基础协议之外，由中继连接双方。它实现了有用的职责分离，却也把信任与可用性假设放进以太坊本身并未规定的中间件。

EIP-7732 把关键交换纳入共识。ePBS 下，提议者可以承诺接受某个构建者的出价，协议规则负责负载揭示和构建者付款；负载及时性委员会（PTC）判断执行负载是否按时到达；共识区块证明与负载及时性投票使用不同截止点。Ethereum.org 表示，这一设计把负载传播窗口从约 2 秒扩大到约 9 秒（Glamsterdam 概览）。增加的时间不是舒适度，而是传播和验证更大负载所需的“时序预算”，可避免验证者被迫持续升级到更快的网络和机器。

flowchart LR
    B[构建者组装执行负载] -->|出价与承诺| P[提议者选择出价]
    P --> C[共识区块传播]
    B -->|揭示负载| N[网络收到执行负载]
    C --> A[验证者对共识区块作证]
    N --> T[负载及时性委员会投票]
    A --> S[协议确定该时隙结果]
    T --> S
    S --> X[支付构建者或执行协议内失败处理]

这项收益应准确表述为“减少一类信任依赖”，而不是消灭中介或 MEV。Ethereum.org 明确指出，构建者和提议者仍可为核心协议未覆盖的复杂功能继续使用外部中继。把市场写进协议也不会自动分散构建权；订单流、模拟能力与低延迟带来的规模经济，仍可能让构建者趋于集中。真正改变的是最低层的结算规则：支付和失败处置从中继的私有惯例变为协议事项。

即使机构用户从不运行验证者，这一变化也与其风险管理相关。中立结算网络的质量，部分取决于故障域是否清晰。把关键交换放进共识，可让行为更可观察，并降低对少数中继运营商的依赖；与此同时，共识状态机更复杂。机构尽调不该只问“中继是否已被移除”，而应追问客户端多样性、监控和事件响应是否跟得上新增复杂度。

第二支柱：让执行工作量提前可见

传统以太坊执行往往要在交易运行时才发现状态依赖。如果两笔交易触及同一账户或存储槽，先后顺序就有意义；若完全不重叠，则可能并行处理。没有权威依赖地图时，客户端只能采取保守策略。

EIP-7928 的区块级访问列表把工作量显式化。列表记录整个区块访问的账户、存储位置和执行后数值，区块头则对该列表作密码学承诺。客户端因此可预取状态、并行读取磁盘，并更高效地计算状态更新。配套的 EIP-8159 允许执行客户端在点对点网络中交换这些列表。官方测试网公告把目标概括为：并行状态读取、并行交易验证和更高效的状态根计算（EF 测试网公告）。

但 BAL 不是应用吞吐量的即时倍增器。互相冲突的交易仍需排序；客户端也必须真正利用这些信息。列表本身还要经历生成、校验、传播，以及适当的保存或清理。近期更根本的进步，是把区块执行从“边跑边发现”的串行工作，变成客户端可提前观察的工作负载。这为并行处理提供可信路径，也为部分同步流程带来“免执行”状态更新的可能：节点可应用经认证的执行后状态，而不必重放每一步运算。

这与去中心化直接相关，因为瓶颈不只来自 CPU 算术。实时状态越大，随机数据库读取和状态根计算就越困难。在基准服务器上安全的容量，如果让普通磁盘或网络经常错过验证期限，就会排除家庭节点。BAL 的目标既是提高上限，也是改善工作形态和可预测性。

连接时间、可见性与价格的三部分框架

扩容论证必须同时成立：更多处理时间、可见的状态依赖，以及贴近真实资源消耗的价格要彼此强化。

第三支柱：让永久性承担价格

提高 gas 上限会带来经典错配：执行容量在当下被消耗，新账户、存储槽和合约代码却会让节点在未来长期承担成本。如果 gas 定价低估这种持久负担，短期吞吐收益就会变成长期硬件债务。

EIP-8037 提高并单独计量状态创建成本；EIP-8038 根据当前状态规模下的实测性能更新状态访问成本。EF 指出，状态操作的价格上次系统调整是在 2021 年 Berlin 升级；团队用新规则重放历史主网交易后，只发现少量合约存在潜在问题，其中大多数可通过提高 gas 限额修复，并已主动联系受影响最大的开发者（EF 重定价分析）。这令人宽慰，却不是担保：历史重放无法完整再现未来调用路径、私有交易和所有组合式交互。

更宏观的设计目标很能说明问题。Ethereum.org 称，EIP-8037 的固定“每状态字节成本”框架，以每年约 120 GiB 的状态数据库增长为目标。5 月的一次多客户端互操作活动中，开发团队形成了 EF 所称的“可信的 Glamsterdam 后 2 亿 gas 下限”：ePBS 提供更多执行时间，BAL 优化释放客户端处理余量，重定价则约束失控的状态增长（Soldøgn 回顾）。工程回顾中的“可信”和“下限”，不等于主网治理已经拍板。Hoodi 的 2 亿配置正是验证这一整合判断的下一次机会。

控制机制	所解决的约束	预期收益	剩余风险
ePBS	紧张的负载交接时间与中继信任	更长传播窗口；协议内支付及失败规则	共识状态增多；构建者集中仍可能持续
BAL	未知状态依赖与串行磁盘工作	预取、并行读取，以及并行验证和同步路径	数据面扩大；客户端优化程度不一
状态重定价	永久存储和访问定价不足	提高容量而不让数据库同比失控膨胀	合约边缘案例；状态密集型应用成本上升

市场层面会改变什么，又不会改变什么

若升级成功，以太坊作为通用结算层的主张会在三方面增强。第一，L1 容量提升，而 Rollup 最终仍要在 L1 结算并提交承诺。第二，出块过程少了一层协议外信任边界。第三，持久状态成本更加显性，让应用经济与验证者硬件可持续性更一致。

但 Glamsterdam 不会抹平 L1 扩容和 Rollup 扩容的区别，不保证所有市场环境中的用户费用都下降，也不会消灭 MEV、构建者专业化或审查风险；并非所有智能合约都会因此变快。官方概览提到另有降低交易固有 gas 的改动，但更广泛的费用效果仍取决于需求、未来 gas 上限治理，以及客户端利用 BAL 的效率。新增供给也可能被新增需求完全吸收。

对应用团队，眼前问题是 gas 敏感性：硬编码 gas 限额、固定 stipend 或依赖剩余 gas 假设的合约，应在新规则下测试。对质押服务商，ePBS 会改变监控和构建者选择流程。对交易所与托管方，关键准备指标是兼容客户端发布、过叉期充提策略，以及各受支持客户端之间没有分歧。对资产配置者，这不是一次代币事件，而是基础设施容量和运营风险的变化。

风险、反方观点与主网上线证据门槛

最有力的反方观点是复杂度。Glamsterdam 在同一次升级中协调新的双参与方出块序列、及时性投票、新执行产物和多项 gas 规则变化。每一项都有充分动机，但真正接受检验的是它们的交互。即使组件分别通过单元测试，复杂性仍可能造成相关性实现漏洞或意外激励。

第二项风险是优化不对称。如果某个执行客户端借 BAL 获得巨大性能收益，而其他客户端落后，运营者可能迁移到最快实现，削弱客户端多样性。第三项是经济适应：更高状态成本可鼓励精简合约，却可能对价值本就依赖持久链上记录的应用不利。第四项是叙事超前：若把 Hoodi 的 2 亿配置说成主网既定容量，就是在证据和治理之前抢跑。

因此，主网上线前的合理门槛应是多维的：多客户端稳定终局；在高负载和不利网络条件下仍能及时交付负载；普通硬件资源占用可预测；状态根和 BAL 不出现无法解释的分歧；重组行为处于可控范围；重定价测试发现的合约退化得到公开处置。这里列出的是本文的分析框架，并非声称开发者已经发布了一份统一正式清单。

结论

Glamsterdam 押注的是：以太坊的限制因素既是计算，也是协调。ePBS 创造时间并规范区块市场交接；BAL 提供执行依赖的可见性；重定价保护长期状态预算。抽掉任何一条腿，“增加 gas”都不再令人信服：更大负载若没有更多时间，会压迫验证者；没有依赖地图，并行化仍停留在愿景；吞吐提高却不为状态定价，则是在抵押去中心化。

截至 2026 年 10 月 17 日，证据令人期待，也理应尚不完整。Sepolia 已完成过叉；Hoodi 计划于 10 月 26 日用 2 亿 gas 测试整套设计；主网没有确定日期。这一顺序不是犹豫，而是治理和工程流程正在发挥作用。最有意义的成功指标不会是测试网上一个醒目的容量数字，而是独立客户端和普通节点硬件能否持续承载这套新控制面，且不把显性瓶颈替换成隐性中心化。