Glamsterdam 的容量契约：以太坊扩容，但不把成本藏起来
头图：Glamsterdam 把更长的传播时间、面向并行的执行方式与可持续的状态定价连在一起；缺少任何一环，都不足以支撑安全扩容。
研究日期：2026 年 8 月 12 日
执行摘要
以太坊下一次升级不应被简化为“让以太坊更快”。更准确的理解是：Glamsterdam 正在重新界定 Layer 1 可以在什么约束下安全扩容。8 月 6 日更新的以太坊官方路线图，已将升级窗口明确为 2026 年第四季度。两项头部改动——协议内提议者与构建者分离（enshrined proposer-builder separation，ePBS）和区块级访问列表（Block-Level Access Lists，BALs）——再加上状态创建重新定价，分别处理三类瓶颈：大负载传播和验证的时间不足、执行依赖只能边运行边发现，以及吞吐提升后永久状态对节点存储造成的长期负担。
本文的核心判断是：Glamsterdam 对机构真正重要的地方，在于它把单一的 gas 上限讨论，改造成了一份显性的“容量契约”。ePBS 把构建者与提议者之间的关键交换纳入共识，并将有效负载的传播窗口从约 2 秒延长至约 9 秒；BALs 为区块附上一张经过认证的状态读写与结果地图，让客户端能够并行读取，并为并行执行和更快同步铺路；EIP-8037 则提高并统一创建永久状态的成本，当前设计目标是把极端情况下的状态增长控制在每年 120 GiB。以太坊基金会 5 月的互操作报告认为，这三者共同使升级后的 2 亿 gas limit 下限成为可信的工程目标；4 月的协议更新所述基线为 6000 万。需要强调：2 亿是工程判断，不是已经确定的主网参数，更不是吞吐量保证。
对于资产管理机构、支付公司、Rollup、交易所和基础设施服务商，最有意义的结果不是一个漂亮的 TPS 数字，而是更大、更可预测的结算空间，以及更少的协议外信任依赖。代价同样真实：时隙结构更复杂，构建者抵押和支付机制改变，一些应用创建状态的成本会上升，客户端与运营流程也需要大幅调整。因此，合理的机构立场应是“建设性但有条件”：把第四季度与 2 亿视为需要持续验证的里程碑，而不是提前写入估值模型的既定事实。
为什么此时值得关注
过去数次升级把不同类型的扩容任务逐步拆开。Pectra 于 2025 年 5 月落地；Fusaka 随后于 2025 年 12 月上线，引入 PeerDAS，使验证者不必下载全部 blob 数据，而可以抽样检查。之后的仅调整 blob 参数的分叉，又在不等待完整功能升级的情况下提高了目标值和上限。Glamsterdam 则把焦点转回 Layer 1 的执行空间与区块生产流程。
这一转向很关键，因为直接提高 gas 上限，可能把成本转移到系统中最不显眼的一端：必须接收、执行、存储并持续提供链上数据的节点运营者。以太坊的去中心化主张，不仅依赖多个独立客户端，也依赖非工业级运营者仍能验证链。如果新增容量只能由最快的客户端、昂贵硬件或少数中间件提供方承受，那么这种容量并不等同于普遍可验证的容量。
官方 Glamsterdam 页面 将目标概括为三项：并行化、扩大容量、控制数据库增长。这比把各个 EIP 当成互不相关的功能清单更准确。Soldøgn 互操作总结称，超过 100 名核心贡献者对多客户端实现进行了压力测试，并认为升级后的 2 亿 gas limit 下限具备可信基础。更近一步，ethPandaOps 在 6 月 25 日至 7 月 9 日期间，对 glamsterdam-devnet-6 上不同共识客户端如何发出新的 ePBS 事件进行了实测调查。这说明互操作工作已相当具体，但仍不能等同于生产就绪。
timeline
title 以太坊通往 Glamsterdam 容量空间的路径
2025-05 : Pectra 激活
: 账户与验证者能力升级
2025-12 : Fusaka 激活
: PeerDAS 改变 blob 数据处理
2026-01 : 第二次 blob 参数分叉
: 每区块目标 14 个，上限 21 个 blob
2026-05 : Soldøgn 多客户端互操作
: 升级后 2 亿 gas 下限被认为可信
2026-06 : Glamsterdam devnet-6 启动
: 跨客户端观察 ePBS 事件行为
2026-Q4 : 官方目标窗口
: 主网上线仍取决于测试与客户端成熟度三位一体的工程契约
一、ePBS 用更长时间换容量，并把信任边界收进协议
以太坊区块生产事实上已经存在角色分工。专业构建者组装具有经济价值的执行负载，被选中的验证者作为提议者选择出价并提出共识区块。当前，这个交换过程很大程度上依赖核心协议之外的 MEV-Boost 与 relay。它促进了专业化区块构建市场，却也把一个影响活性和信任的关键交接点留在中间件层。
EIP-7732 将这种分工协议化。提议者可把构建者承诺写入共识区块，构建者随后揭示执行负载，“负载及时性委员会”（Payload Timeliness Committee）则证明负载是否按时到达；支付与失败路径均成为共识规则的一部分。以太坊官网称，新的时隙结构把负载传播窗口从约 2 秒扩大到约 9 秒，客户端因而有更多时间处理更大的执行负载与 blob 数据。
这并不意味着构建者、拍卖或 relay 会消失。复杂的订单流和更丰富的竞价服务仍可留在协议外。ePBS 更克制、也更重要的成果，是把“负载换支付”这项最低限度的交易变成无需信任的协议机制。对机构而言，关键路径中对中间件的依赖下降了；但构建者份额集中、私有订单流与审查风险并不会自动消失。
flowchart LR
U[用户与应用] --> M[公开或私有订单流]
M --> B[构建者组装执行负载]
B -->|出价与承诺| P[当选提议者]
P --> C[共识区块]
B -->|揭示负载| E[执行负载]
C --> A[验证者证明共识]
E --> T[负载及时性委员会]
T --> F{负载是否及时}
F -->|是| S[协议结算构建者付款]
F -->|否| R[协议执行失败路径]新结构在消除旧风险的同时，也引入新失败模式。4 月的 Checkpoint #9把 ePBS 称为升级的一大难点，因为每种客户端都要处理“部分区块”和共识内两方依次行动的情况。Soldøgn 期间，团队仍在争论低抵押构建者设计如何抵抗点对点网络中的女巫攻击。截至 8 月，ePBS 已明显成熟，但严谨的结论仍是“正在强化”，而非“风险已经解决”。
二、BALs 把执行从临场发现变成可调度任务
以太坊执行之所以难以并行，是因为节点通常只有真正执行交易后，才知道交易会触碰哪些账户与存储槽。两笔看似无关的交易可能争用同一状态。客户端可以尝试推测性并行执行，但冲突会造成重复工作与额外复杂度。
EIP-7928 要求每个区块携带区块级访问列表：一份经过认证的账户、存储读写位置及相关执行后结果记录。有了这张地图，节点便可预加载状态、并发读取磁盘、识别无冲突任务，并并行计算部分状态转换。配套的网络协议改动则让节点可以相互交换这些列表。
BALs 不应被误读为“立即实现无限并行执行”。近期收益首先包括并行 I/O 和更确定的调度；客户端仍须把这些信息转化成稳定性能。它的战略价值在于，把依赖关系变成协议边界上的显式数据。列表包含执行后结果，也支持“免重放执行”的状态同步：同步节点可以应用经过认证的结果，而不必重演所有历史交易；与此同时，共识规则仍会验证相应承诺。
对自营节点或同时使用多家节点服务的机构而言，更快、更可预测的同步有时与吞吐本身同样重要。故障恢复时间、切换能力，以及分散 RPC 或托管供应商的可行性，都是运营风险指标。BALs 可能改善这些指标，但它也扩大区块数据，并引入一个所有客户端必须一致构造和验证的新共识关键对象。
三、状态重新定价，让永久存储成本不再隐身
更高 gas 上限允许更多计算，但不同 gas 对系统的长期成本并不相同。临时计算在执行后消失；新账户、存储槽或合约却会扩大所有节点长期保留的状态。如果状态创建费用低估永久负担，提高吞吐就会加速数据库增长，并悄然抬高硬件门槛。
EIP-8037以固定的“每状态字节成本”和单独的计费储备机制处理这一错配。最新官方说明称，当前参数旨在把最坏情况下的状态增长限制在每年 120 GiB。Soldøgn 参与者放弃了随区块 gas 上限动态变化的价格，因为这会使测试组合成倍增长；未来如需调整，将在分叉边界重新定价。这一选择以自动适应能力换取确定性与可审计性。
这是整套设计里最不适合营销、却可能最重要的一部分。状态重新定价意味着，即使另一项已安排提案 EIP-2780 可能降低普通转账成本，一些部署操作和状态密集型应用仍会变贵。因此，“容量增加”并不等于所有操作都降价。协议试图让价格更诚实：对被高估的工作降费，对长期外部成本被低估的行为加价。
编辑框架：可信的 gas 上限提升，必须同时兼顾用户容量、客户端性能余量和受控的长期状态增长。
对机构与 Rollup 经济的含义
最直接的机构收益，是 Layer 1 为结算、发行和高价值执行提供更大余量。更大的 gas 空间能在需求突增时缓和费用压力；更长的传播窗口也降低了只有网络条件极佳的运营者才能跟上的可能性。L1 扩容还会间接帮助 Rollup：即便大部分数据通过 blob 提交，它们仍需在 L1 结算证明、管理桥并发布部分交易。
第二项收益来自架构。把最低限度的提议者—构建者交换纳入协议，可以减少基础层对可信 relay 的依赖。评估以太坊能否作为中立基础设施时，机构需要问清楚：谁能中断交易纳入？不同依赖究竟靠合同、社会共识还是协议共识约束？ePBS 把一项重要关系移入最后一类。
第三项收益是运营可预测性。BALs 和更准确的 gas 定价，为区块触及什么、状态应付出多少成本提供了更清晰的信息，有望改善节点性能与费用模型。然而，升级不会无摩擦完成。验证者必须同时更新执行和共识客户端；质押池可能需要改变监控构建者行为和处理新时隙的方式；交易所、托管商和 RPC 提供商则需要保守的维护窗口与多客户端测试。
对 Rollup 而言，信号较为细腻。Glamsterdam 没有逆转以 Rollup 为中心的路线，PeerDAS 仍是 blob 数据可用性扩容的基础。更多 L1 执行容量或使主网重新适合更多类型的交易，但 L2 在高频和应用专用执行方面仍有结构优势。更可能出现的是互补：更宽裕的结算层承托更大的 Rollup 经济，而不是所有活动重新回流 L1。
风险、反论与可证伪条件
进度风险。 2026 年第四季度是目标窗口，不是激活日期。以太坊流程要求先有稳定开发网、客户端发布、安全审查与公开测试网，之后才会确定主网时间。官方路线图也明确提醒，社区驱动的开发随时可能变化。任何假定具体季度的资本或运营计划，都应预留延期空间。
复杂度风险。 ePBS 增加承诺、揭示时序、付款和部分区块失败处理；BALs 增加数据量和跨客户端共识要求。每项改动都对应真实瓶颈，但它们的交互扩大了测试面。因安全工作而延期可被视为负责任的工程选择，却仍会推迟经济收益。
中心化可能只是转移，而非消失。 协议内 PBS 能消除基础交换对可信 relay 的依赖，却不会自动分散构建者市场份额或私有订单流。更大区块仍可能有利于高性能运营者。如果升级后的数据出现漏块率上升、客户端集中加剧，或数据中心节点即使在更长窗口下仍获得持续优势，本文的积极判断就会被削弱。
2 亿容易被误读。 Soldøgn 使用的是“可信的升级后下限”；最新 ethereum.org 页面又指出，状态定价目前以 1.5 亿 gas 的参考区块进行推导。两者都不是无条件的主网设置。gas limit 最终取决于验证者行为和实际安全余量。观察者应追踪最终参数与生产遥测，而不是把当前活动简单乘以一个宣传比例。
状态定价具有分配效应。 EIP-8037 通过更准确地收费保护节点可持续性，但状态密集型协议和合约部署会承担更多成本。开发者可能压缩存储、使用事件或把活动迁往 L2；设计不佳的应用也可能直接把费用转嫁给用户。系统层面的可持续收益，在应用层存在明确的承担者。
机构监测框架
在把 Glamsterdam 视为“已经交付”之前，机构观察者至少应关注四道门槛。第一，多种执行与共识客户端能否在对抗性测试和高负载下保持稳定互操作？第二，最终主网范围能否守住“时隙时间、面向并行的执行、状态控制”三者平衡？第三，激活后漏块率、重组行为、节点资源消耗与构建者集中度是否仍处于可接受区间？第四，费用和容量优势能否在真实需求冲击中出现，而不只存在于合成基准测试？
现有证据跨过了一道重要、但仍属中间阶段的门槛。Glamsterdam 已不只是纸面规范：5 月互操作周产生了多客户端管线与基准测试；6 月 devnet-6 支持跨实现观察；8 月路线图列出了已安排功能及第四季度窗口。但它尚未跨过生产门槛，因为最终激活日期和主网上线后的运营记录都不存在。
结论
Glamsterdam 的核心理念可以概括为“有纪律的充裕”。以太坊只有为负载争取更多时间、为客户端提供更多依赖信息，并为永久状态设定更诚实的价格，才能扩大容量。ePBS、BALs 与 EIP-8037 因而是同一个容量空间中彼此依赖的部分，而非三项松散功能。
如果整套设计如预期运行，以太坊完成的将不只是提高一个参数：它会把关键的信任边界收进协议，为执行并行化做准备，并约束一个原本会在每个节点上不断累积的外部成本。对机构而言，这一点很重要，因为中立结算基础设施只有在验证成本与失败依赖清晰可控时才真正有价值。反面的约束也必须同样清楚：第四季度只是目标，2 亿是工程判断，新共识机制必须在生产环境中逐步赢得信任。
截至 2026 年 8 月 12 日，合理结论既不是追捧，也不是否定。Glamsterdam 是以太坊确立 Rollup 路线以来最重要的扩容重构之一，实施证据正在增加。衡量它是否成功，不能只看峰值吞吐，而要看以太坊能否在增加有效容量的同时，不让独立验证、客户端多样性和可信中立性成为一张被隐藏的账单。