别只盯着 200M Gas：Glamsterdam 真正重要的是这三条技术线
原文链接 🔗https://blog.ethereum.org/2026/05/02/soldogn-interop-recap
🤝 搭建可靠的以太坊信息桥梁
ETHDaily 官方授权，内容由 ETHPanda 社区成员翻译校对，仅供学习交流，不构成任何建议。
以太坊下一次重要网络升级 Glamsterdam，正在从路线图讨论进入更具体的多客户端开发、联调与测试阶段。
5 月 2 日，Tim Beiko 在 Ethereum Foundation Blog 发布《Soldøgn Interop Recap ☀️》，回顾了刚刚结束的 Soldøgn Interop。过去一周，超过 100 位以太坊核心贡献者来到北极圈内的 Longyearbyen, Svalbard，围绕 Glamsterdam 升级进行集中开发、联调与设计讨论。
这不是一次普通的开发者聚会。按照 EF Blog 的描述，Soldøgn 延续了 Amphora、Edelweiss、Nyota 等互操作周的传统：让客户端团队、研究者和协议贡献者在同一时间、同一地点，围绕具体升级目标协作，把规格讨论、实现、测试、debug 和决策压缩到更短周期内完成。
这次 Soldøgn 的核心目标可以概括为一句话：harden Glamsterdam, scale Ethereum。也就是在增强 Glamsterdam 实现稳定性的同时，为以太坊 L1 更高吞吐量提供可信依据。
Glamsterdam 的重点不是“简单把 gas limit 调到 200M”，而是让 200M 成为一个可测试、可实现、可治理的工程目标。
200M Gas 的重点：不是“装更多交易”这么简单
过去几年，以太坊扩容叙事更多集中在 L2、blob 和数据可用性上。但 L1 本身的执行能力仍然是整个系统的底座。提高 gas limit 意味着每个区块可以容纳更多执行工作，但这件事不能只靠调高参数完成。
因为 gas limit 提高会同时放大多重压力：区块构建和传播是否仍能按时完成，客户端在高负载下是否还有余量，状态增长是否会变得不可控，不同客户端之间是否能在极端条件下保持一致性，以及主网治理能否把测试结论转化为可审计、可公开讨论的升级参数。
因此，Soldøgn Interop 中提到的 200M post-Glamsterdam gas limit floor，更准确地说，是一个在现有测试和实现进展基础上形成的可信目标，而不是已经完成主网治理流程的承诺。最终数值仍需要通过 AllCoreDevs 讨论、EIP 状态更新和客户端实现继续确认。
理解 Glamsterdam，可以抓住三个关键词：ePBS 争取执行时间，BAL 提供客户端吞吐余量，EIP-8037 降低高 gas limit 下状态增长失控的风险。三者合在一起，才构成 200M gas floor 的工程逻辑。
更具体地说，ePBS / EIP-7732 是把 proposer / builder 分离更明确地纳入协议设计，重组区块构建、payload reveal、attestation 等 slot 内时序；BAL / EIP-7928 是在区块层面记录账户和 storage 访问及执行后的状态变化，帮助客户端进行并行读取、并行验证和 state-root 计算；EIP-8037 则提高新建状态成本，并引入 state-gas / regular-gas 的二维计量与 reservoir model，目标是在更高 gas limit 下抑制状态增长。
FOCIL / EIP-7805 与 native account abstraction / EIP-8141 也在 Soldøgn 中被讨论，但它们更偏向 Hegotá 及后续 fork，不是这篇文章的 Glamsterdam 主线。
三条主线：时间、性能与状态增长
第一条线是 ePBS：为更高 gas 上限争取执行时间。在当前 PBS 相关设计中，proposer 和 builder 的关系仍有不少外部化和信任假设。ePBS 的目标，是把 proposer / builder 分离更明确地纳入协议结构，并重新安排 slot 内部的关键时间点，包括区块构建、payload reveal、attestation 等环节。
这对于扩容很重要。要安全提高 gas limit，核心问题不只是“一个区块能装多少交易”，还包括“客户端有多少时间执行、验证和传播这个区块”。ePBS 通过更清晰的 slot 结构，为执行层争取更多可控空间。
Soldøgn 期间，团队围绕 Glamsterdam devnet 进行了多轮跨客户端调试和压力测试。到周五，几乎所有客户端都已在 glamsterdam-devnet-2 上共同运行，external builders pipeline 也完成了端到端测试。不过，request signature 是否应绑定接收方 builder、1 ETH-staked-builder 设计如何抵抗 P2P Sybil 影响等问题，仍需要在 ACD 层面继续讨论。
更准确地说，ePBS 的状态不是“所有问题都结束了”，而是：多客户端路径已经跑通，核心流程显著稳定，但仍有安全与活性细节需要公开治理流程继续收敛。
第二条线是 BAL：扩容不能只看最快客户端。如果说 ePBS 解决的是共识层和 slot 结构问题，那么执行层还需要回答另一个问题：客户端能否稳定处理更大的区块？
BAL 的核心作用，是在区块层面提前提供读写集合和执行后状态变化信息，让客户端可以更好地进行并行磁盘读取、并行交易验证、并行 state-root 计算，以及 executionless state updates。换句话说，BAL 试图减少客户端在执行区块时面对的不确定性，从而提升处理大区块的能力。
Soldøgn 期间，BAL track 使用独立 devnet，与 Glamsterdam ePBS 链分开运行，避免共识层稳定性问题干扰执行层优化测量。每项优化也通过 feature flag 单独开启，方便团队比较不同优化对性能瓶颈的影响。
这背后的思路很重要：**以太坊客户端生态不是只需要最快实现变得更快，而是要让最慢路径也被抬高。**只有所有主要客户端在最坏情况下都有足够余量，提高 gas limit 才更可信。
第三条线是 EIP-8037：给状态增长重新定价。更高的 gas limit 会提高吞吐，但也可能带来更棘手的状态增长问题。新账户、合约代码、storage slot 等状态不是一次性数据，而是节点长期维护的负担。如果新建状态成本过低，更高 gas limit 可能直接转化为更快的数据库膨胀，最终推高节点运行门槛。
Soldøgn 之前，EIP-8037 规格中包含与 block gas limit 绑定的动态 per-state-byte pricing。这让测试矩阵变得复杂，也使 benchmark 更难处理。团队在互操作周内同意放弃动态定价，改为固定的 cost_per_state_byte，未来 repricing 则留到 fork 边界处理。
随后，EIP-8037 的参数与 rationale 进一步更新：当前规格将 CPSB 写为 1530 gas / byte，并以 150M reference block gas limit 和 120 GiB / year target state growth 推导该参数。按照当前 EIP 的 worst-case 表述，在 200M block limit 下，对应 worst-case growth rate 约为 160 GiB / year。
因此，这里更适合使用这样的表述：EIP-8037 的 repricing 路线已经在互操作周和 5 月 11 日 EF Protocol Update 中被表述为 finalized，但 EIP 本身仍处 Draft，最终主网落地仍需随 Glamsterdam 升级流程完成。
把三条线放在一起看，Glamsterdam 的扩容叙事就不应该被写成“以太坊要把 gas limit 提到 200M”这么简单。更准确地说，它是在回答一个更难的问题：怎样让 L1 执行能力提高，同时仍然保留客户端多样性、节点可运行性和公开治理节奏。
Glamsterdam 之外：哪些进展要看，哪些不用抢主线
除三条主线外，Soldøgn 还处理了一批较小的 Glamsterdam 范围问题。例如，EIP-8061 被纳入 glamsterdam-devnet-1；EIP-8080 被拒绝纳入；EIP-8045 被缩小到 look-ahead window 内的 proposer duties；EIP-7688 仍在 Glamsterdam 范围内，但暂未进入 devnet-1；EIP-8237 则被推迟出 Glamsterdam。
这些内容不是本文主线，但它们说明 Glamsterdam 并不是单一提案的推进，而是一组围绕 L1 扩容、客户端性能、共识流程、状态增长和升级治理 的组合调整。
Soldøgn 也为 Glamsterdam 之后的 fork 提前收集实现反馈。FOCIL / EIP-7805 已经在 Hegotá Meta EIP 中列为 Scheduled for Inclusion；根据 EF 5 月 11 日 Protocol Update，FOCIL prototypes 已经 functional，下一步是多客户端互操作和专门的 FOCIL devnet。
native account abstraction 也继续推进。相关 breakout 没有绑定单一提案，而是先梳理未来设计必须满足的需求和约束。Frame Transaction / EIP-8141 是当前 native AA 的重要候选之一，但在 Hegotá Meta EIP 中仍是 Considered for Inclusion，而不是已经 scheduled。
此外，ETH P2P track 也讨论了用基于 QUIC 的方案替代 libp2p 的可能性，并探索 privacy-by-default、slot-aware integration，以及 erasure-coded broadcast 等方向。这些内容可以保留为背景，但不需要展开太多；它们的作用是说明 Soldøgn 不只是在推进 Glamsterdam，也在为后续 fork 提前暴露约束、测试方向和工程假设。
下一步：从 devnet 走向主网参数
除了技术实现，Soldøgn 还讨论了 AllCoreDevs 流程本身，包括 headliner construct、strawmap 的取舍，以及 EIP SFI 标准化。这类流程变化对外部读者看似抽象，但对协议升级节奏很关键：进入 devnet、成为 fork 重点、最终纳入主网升级，都不只是技术成熟度问题，也涉及跨团队优先级排序与公开治理流程。
这也是为什么需要反复强调：**Soldøgn 的结果已经让 Glamsterdam 的扩容目标更可信，但它还不是最终主网激活公告。**测试跑通、参数收敛和 EIP 进入升级范围，都只是通往主网的不同阶段，不能混在一起写。
Soldøgn 之后，各客户端团队将把本周原型和修复继续推进到生产级实现。接下来几周的重点预计包括：继续 harden 客户端实现、完善测试覆盖、把 draft PR 转化为可合并代码，并在 AllCoreDevs 中公开讨论最终参数与规格细节。
对于中文读者来说，Glamsterdam 值得持续关注的原因在于：它可能是以太坊 L1 执行能力提升的重要节点，但它不是单点参数调整，而是一组围绕区块构建、执行性能、状态增长和协议治理的系统性改造。
换句话说，Soldøgn Interop 展示的不是一个已经完成的结论，而是以太坊如何把“扩容”这件事拆解成可实现、可测试、可争议、也可逐步收敛的工程过程。
如果说 200M gas floor 是这次互操作周最醒目的数字，那么更值得关注的，是以太坊正在为这个数字补齐一整套工程前提。
参考链接
免责声明：本文内容仅用于信息分享与行业交流，所提供信息可能存在滞后或误差，亦不构成任何形式的投资建议或官方背书。
翻译 & 校对 | 小白
编排 | 小白
👇 欢迎关注 ETHPanda 获取更多资讯！
