
Glamsterdam 把共识层的生产流水线与执行层的状态工作地图组合起来。相比任何单一的容量数字,这种组合本身更值得关注。
以太坊下一次计划中的网络升级 Glamsterdam,官方目标是 2026 年下半年。把它概括成“又一次扩容”会遗漏真正重要的变化。两项主角提案——协议内置的提议者与构建者分离(ePBS,EIP-7732),以及区块级访问列表(BAL,EIP-7928)——共同改造的是一个区块从经济承诺走向全网验证状态转换的方式。
本文的核心判断是:Glamsterdam 是一次“架构先于容量”的升级。ePBS 将对区块的共识与执行载荷的传播、验证拆开,把目前常由外部中继承担的协调功能纳入以太坊共识规则;BAL 则公开一个区块会触及哪些状态,使客户端可以并行取数,并为不逐笔重放交易的状态更新创造条件。前者争取时间,后者让计算可调度。二者结合,目标并非要求每个验证者用更强硬件把同一套串行工作做得更快,而是在不压缩安全余量的前提下,为提高一层容量铺路。
这对机构用户有直接意义。更强的 L1 可以改善 Rollup 与应用共享的结算底座;由协议强制执行构建者付款,可降低对受信中间件的依赖;同步加速也可能降低自营基础设施的门槛。但收益绝非自动兑现。ePBS 增加共识复杂度、改变交易确认的阶段语义,并赋予构建者一种可能在剧烈行情中获利的“免费期权”:承诺后拒绝发布载荷。BAL 会增加带宽和验证负担,而且只是让并行处理成为可能,仍需各客户端真正实现。因此,合理结论既不是“Glamsterdam 已经解决扩容”,也不是“这只是用户无感的底层管道”。它是一场影响深远的重构,衡量成功与否的指标应包括韧性、客户端多样性与载荷可靠交付,而不只是目标 gas 上限。
以太坊官方路线图呈现的是一组互补升级:Dencun 于 2024 年 3 月引入 blob 容量,Pectra 于 2025 年 5 月上线,Fusaka 于 2025 年 12 月上线 PeerDAS 并提高默认 gas 上限;Glamsterdam 则处于开发阶段,目标为 2026 年下半年。这一顺序很关键。Rollup 通过批量处理降低执行成本,但仍依赖以太坊提供数据可用性、结算与可信退出。提高 blob 容量解决 Rollup 数据承载;提高 L1 执行能力强化共享结算层。若传播和验证仍挤在狭窄的关键路径上,两者都无法无限扩展。
现实中的以太坊区块市场已经存在提议者与构建者分工。专业构建者组装价值较高的区块,提议者通常通过 MEV-Boost 与中继接收竞价,并在事前看不到完整载荷。这套协议外安排具有经济效率,却带来中继可用性、信任与审查依赖。ePBS 并非发明这种分工,而是试图把既有分工变成以太坊原生、可执行的规则。
另一个瓶颈位于执行内部。节点通常只有执行交易后,才知道它会读取或改动哪些账户与存储槽。多笔交易可能争用相同状态,因此发现依赖的过程带来串行工作和不规则数据库读取。现有交易访问列表是可选的,也可能不完整。BAL 改为要求提供完整的区块级状态访问记录及交易后的相关状态值,把隐藏依赖变成经过认证的输入。
flowchart LR
A[Rollup 与 L1 用户需要更多容量] --> B{当前瓶颈}
B --> C[传播与验证窗口过短]
B --> D[执行时才发现状态依赖]
C --> E[ePBS 拆分信标区块与执行载荷]
D --> F[BAL 记录访问与执行后状态]
E --> G[为更大载荷与更多 blob 留出传播时间]
F --> H[并行读取、验证与状态更新]
G --> I[更安全地提高 L1 容量]
H --> IEIP-7732 规范引入由协议跟踪的构建者、执行载荷竞价、载荷信封以及载荷及时性委员会(PTC)。简化来看,提议者先发布包含某个构建者竞价承诺的共识区块;构建者随后揭示执行载荷;PTC 证明载荷是否按时到达。构建者通过信标链锁定资金,使付款可以由协议执行,而无需依赖私有中继的声誉。
这改变了关键路径。Glamsterdam 官方说明称,传播窗口将从约 2 秒延长至约 9 秒。EIP-7732 对机制的描述更精确:下一位提议者有 6 秒验证载荷,其他验证者有 9 秒。验证被延后,而不是被取消。这一区别至关重要:以太坊并非通过放松执行规则来换吞吐量,而是重新安排时隙,让完整载荷验证无需在第一条共识消息传播前全部完成。
效果类似流水线:网络就一个组件形成共识时,另一个组件可以同步传播、检查。更大的执行载荷与更多 blob 数据,因而不必争夺同一个狭窄时间窗。协议原生付款也减少了提议者和构建者为了公平交换而依赖外部中继的理由;不过,竞争性区块发现、订单流与构建者集中度仍然属于市场层问题。
对用户而言,“已打包”会更明确地分成多个阶段。进入时隙 N 的交易,要等验证者处理载荷并对后续区块投票后,才得到广泛的执行验证。钱包、交易所与风控系统应区分载荷发布、链头、合理化与最终确定,而不能把它们压缩成一个“已确认”标签。Glamsterdam 并未让概率性结算突然成为问题;它只是让内部流水线更显性,也略微更复杂。
sequenceDiagram
participant B as 构建者
participant P as 提议者
participant N as 共识网络
participant T as 载荷及时性委员会
participant V as 验证者
B->>P: 签名竞价与载荷承诺
P->>N: 信标区块选中竞价
B->>N: 揭示执行载荷
T->>N: 证明载荷按时到达
V->>V: 执行并验证载荷
V->>N: 对下一链头投票
Note over P,V: 共识与执行验证形成流水线,并未取消验证EIP-7928 规范要求区块访问列表记录执行过程中触及的每个账户和存储位置,以及相关的执行后数值;区块头中放入其哈希承诺。缺项或伪造项都可能使区块无效,因此这不是提示性元数据,而是共识关键数据。
它支持三类经常被混为一谈的改进。第一,客户端可以并行预取账户与存储,不必等执行逐个发现数据库读取。第二,状态足迹互不重叠的交易未来可以并发验证。第三,同步节点可以应用经过认证的执行后状态变化,而不必逐笔重放全部历史交易,即所谓“免执行”状态更新;节点仍可验证承诺,并在需要时重执行。
网络层还必须真正送达这些列表。EIP-8159定义 eth/71 点对点消息,让客户端请求、提供 BAL,并依据区块头承诺核验。这个配套提案揭示了协议扩容的一条规律:有用的数据结构本身不够,还需要传播规则、保留政策、抗拒绝服务限制以及可互操作的客户端实现。
BAL 不会让 EVM 一夜之间全面并行。冲突交易仍需排序;客户端团队也必须利用新信息,工程化实现并行存储读取、状态根计算与执行。因此,最初收益可能首先表现为验证和同步更可预测,而不是惊人的基准跑分。这仍然很有价值:数据库延迟与状态增长都是运营约束,降低不可预测 I/O 能让未来提高 gas 上限更安全。

两项主角提案的系统价值最高,但 ePBS 也承担最大的共识与市场设计负担。图中位置是定性编辑判断,并非量化测量。
两项主角提案彼此增强。ePBS 给数据传播与验证创造更长间隔;BAL 则组织更大执行负载所附带的状态数据。容量增长由更好的调度推动,而不是单纯升级硬件。以太坊基金会 2026 年协议优先事项明确把扩容与“强化 L1”并列,后者包括状态重新定价、历史过期及长期无状态化。Glamsterdam 应置于这一约束下理解:若新增容量损害个人运行节点或客户端多样性,就是得不偿失。
因此,机构观察者需要比 TPS 更宽的计分卡:
核心问题 | 应跟踪证据 | 重要性 |
|---|---|---|
流水线能否承受压力? | 载荷到达率、错过或空时隙、传播尾部延迟 | 平均延迟会掩盖剧烈行情中的失败 |
BAL 的运营效率如何? | BAL 体积、带宽、验证时间、同步性能 | 新增共识数据必须证明其成本合理 |
实现是否足够多样? | 各执行与共识客户端的功能一致性和事故 | 架构相同时,多样的软件故障模式更安全 |
构建者市场是否保持竞争? | 集中度、质押、竞价分布、上线后的中继依赖 | 协议固化接口,也可能固化市场结构 |
L1 是否仍可独立参与? | 节点硬件、带宽与存储需求 | 若独立验证变得不经济,容量增长并非中性 |
这种框架也可避免估值上的概念错误。gas 上限提高不会机械地产生手续费收入、ETH 需求或应用增长。容量只是供给;需求取决于有用应用、Rollup 经济与用户体验。区块空间更便宜甚至可能在活动增长时降低手续费压力。Glamsterdam 的投资意义是拓宽以太坊的选择空间与可靠运行边界,而不是保证短期货币结果。
最有力的反方观点是复杂度。ePBS 给信标状态增加构建者、新消息与及时性委员会,引入异步执行载荷处理,并让分叉选择需要处理完整、空载荷与跳过时隙等更多情况。以太坊基金会 2026 年 4 月的第九期进度检查称 ePBS 实现比预期更棘手;5 月的Soldøgn 互操作回顾记录了密集的跨客户端工作。官方路线图仍只写“2026 年下半年”,没有承诺区块高度。这种不确定性是健康的:独立客户端协调硬分叉,不是可以单方面定期交付的产品发布。
最重要的经济风险是“免费期权”。构建者承诺载荷后才予以揭示;若市场条件骤变,拒绝交付有时可能比履约更有利,造成空时隙,并恰好在波动最剧烈时伤害用户。EIP-7732 承认,模拟显示这种情况的发生次数可能不可忽略。关于动态惩罚的研究认为,递增处罚可以阻止大多数策略性失败,但也承认极端场景仍可能有利可图。这并不能证明 ePBS 不稳健;它说明协议强制交换是在用机制设计难题替代原有信任模型,必须在生产环境持续监控。
构建者集中化也存在两面性。减少中继依赖确实是去中心化收益,但构建者仍受益于复杂基础设施、私有订单流与资本。质押要求能提升问责,却也提高准入门槛。把接口写进协议,并不保证接口另一端的市场足够多元。
BAL 同样有成本。列表占用带宽与存储,需要在规定的同步周期内保留,并增加畸形数据与数据不可用的攻击面。其规模受与 gas 关联的上限约束,但最坏情况比典型区块更重要。“免执行”更新也改变信任与验证选择:节点可以依据认证差异快速更新,但高保证运营者仍可能选择周期性或持续重执行。同步更快,不等于独立复现了每一步计算。
最后,计划功能仍可能变化。EIP 可能停留在草案或评审阶段,参数会修改,开发网结果也会改变范围。EIP 仓库的状态定义明确说明 Draft 与 Review 并非 Final。读者应把本文视为截至 2026 年 8 月 18 日的阶段性评估,而非对主网最终内容的保证。
对 Rollup 而言,ePBS 若成功上线,将因载荷与数据传播空间扩大而提升 blob 吞吐量的安全边界。对 L1 应用而言,BAL 支持的并行 I/O 与可持续 gas 重新定价提供扩容路径,但实际费用和延迟仍取决于客户端采用及后续参数提升。对基础设施运营者而言,这不是无感升级:共识与执行客户端都必须实现更复杂的跨层握手与新数据可用路径。
对受监管中间机构而言,最直接的行动首先是更新观念,而非修改代码。确认政策应对应新的分阶段流水线;运营尽调应覆盖构建者交付、PTC 表现及不同客户端性能。承诺“一个区块即最终确定”的服务等级协议本就夸大以太坊保证;ePBS 上线后,这种表述的信息量更低。
对以太坊治理而言,Glamsterdam 将检验一个去中心化协议能否把广泛使用的中间件功能纳入自身,同时避免冻结当下构建者市场或让共识不堪重负。这比达到某个象征性 gas 目标更困难,也更有价值。
Glamsterdam 的核心是从协调方式中获取杠杆。若区块数据拥有更长传播时间,执行客户端又能提前获得可靠的状态工作地图,以太坊就可能更安全地扩容。ePBS 与 BAL 解决不同瓶颈,二者结合才是此次升级具有结构性意义的原因。
审慎结论必须带条件:若跨客户端测试证明载荷交付可靠,BAL 开销保持受控,节点要求仍让广泛参与者负担得起,并且构建者竞争没有恶化,Glamsterdam 就为下一阶段 L1 扩容奠定了可信基础。若这些条件落空,更高的名义容量上限只会转移注意力。以太坊的机构价值来自压力下仍可独立验证的结算;评价此次升级,应看它能否在扩大空间的同时守住这一属性。
研究截止日期:2026 年 8 月 18 日。升级范围、参数与时间仍取决于以太坊治理和测试流程。