以太坊Glamsterdam：开发者们在Soldøgn测试了什么

区块链文库报道：

凌晨两点的压力测试：以太坊Glamsterdam 开发网实战记录

凌晨两点，房间昏暗，有人突然涌入大量测试交易，让内存池几近沸腾。笔记本风扇嗡嗡作响，开发者们低声抱怨，客户端记录下所有数据。这就是 Soldøgn——一场在以太坊 Glamsterdam 开发网上进行的漫长而混乱的冲刺。

周末结束时，网络没有崩溃。但一些开发者关心的地方确实出现了问题。而这正是测试的意义所在。

如果你想知道实际测试了什么，以及为什么局外人应该关心，以下是直截了当的版本。

什么是 Glamsterdam？

Glamsterdam 是一个跨客户端开发网周期，以太坊客户端团队、构建者和协议研究人员在此推动下一波变更，直到它们出现问题或被证明足够稳定。它位于公共测试网和主网之前——在这里，糟糕的想法被淘汰，优秀的想法被打磨完善。

现在承受压力，比以后后悔更划算。开发网让以太坊在用户感受到之前，就能发现 Gas 核算、构建者市场和引擎 API 中的潜在问题。

在 Soldøgn 期间，开发者用更高的交易负载冲击 Glamsterdam，观察构建者在压力下的行为，并迭代那些会影响钱包、二层网络和 MEV 基础设施的 Gas 语义。这项工作直接反馈到下一个开发网周期 DevNet-8，该周期已经列出了一系列必须完成的任务。

Glamsterdam 到底是什么？

可以把它想象成一个旋转的舞台，每个主要的以太坊执行和共识客户端都会带着接近最终的代码出现，开启或关闭功能，并同步处理共同的漏洞。它不是一个分叉名称，而是一场实弹彩排。

当前测试从何开始？

Glamsterdam-devnet-6 于 2026 年 6 月 25 日上线，并从第 30 个 epoch 开始启用 Gloas——这是一个记录在客户端事件流中并由 EthPandaOps 团队整理的细节。他们的事件矩阵覆盖了 6 月 25 日至 7 月 9 日，清晰地展示了客户端如何随时间观察和发出相同的状态。

为什么开发网在测试网之前如此重要？

公共测试网非常适合应用程序流量和钱包用户体验。而开发网则是协议人员协调影响区块构建方式、Gas 计算方式以及节点间通信方式的变更的地方。如果这里出现问题，每个人都要在以后付出代价：工具链出现偏差，构建者分叉其逻辑，主网也会面临意外情况。

Soldøgn：实际测试了什么？

Soldøgn 冲刺不是为了演示，而是为了试图破坏底层系统。

吞吐量测试

主要结果：根据 7 月 27 日的核心开发者测试会议记录，Glamsterdam-devnet-7“在周末承受了增加的交易负载，表现良好”。这是一个你在不眠周末之后希望看到的稳定结果。

压力下的构建者竞争力

不那么稳定的是构建者方面的问题。同一份会议记录指出，Geth Builder 和 Nethermine 未能持续赢得竞标。这暗示了在区块密集时，构建者、中继和提议者之间可能存在竞争力或集成方面的差距——这正是 MEV 相关基础设施必须妥善处理的场景。

边缘情况故障排查

除了原始吞吐量，团队还研究了时间边缘和记账细节。根据同一份记录，多个客户端在周末推出了修复程序，以弥补负载测试暴露出的问题。

测试通常如何进行

启动修补后的客户端版本，部署在不同的基础设施上，确认健康的节点连接状态。启动交易生成器，针对特定的调用数据和 Gas 模式进行测试。在切换负载配置的同时，观察中继上的构建者竞标结果。捕捉客户端间事件流中的不匹配并记录差异。修补、重启、重复，直到故障连续两次不再出现。

Gas 核算调整：命名、数字和连锁反应

Glamsterdam 中一个较安静但重要的线程是 Gas 语义。7 月 27 日，客户端团队引用了一个活跃的拉取请求，将 EIP-8037 中的术语“常规 Gas”更名为“执行 Gas”。这听起来是表面工作，但目标是清晰度：将支付 EVM 执行的费用与其他类别分开，以便实现和工具使用相同的语言。

为什么用词很重要

Gas 标签会渗透到费用市场、钱包估算以及构建者选择交易的方式。如果两个客户端或库对同一个记账桶使用略有不同的名称，就会导致交易定价错误或 RPC 响应混乱。尽早统一术语有助于保持浏览器、SDK 和中继的一致性。

重新定价问题

除了命名之外，“最终重新定价数字”被标记为下一个开发网的关键先决条件。这表明需要进行校准工作——在锁定下一个周期的代码之前，确定在负载和真实区块条件下，哪些操作应该花费多少成本。

构建者、竞标和中继现实

Soldøgn 期间出现的构建者问题是一个特性，而不是一个 bug。你希望现在失败，在日志和补丁管线就绪的情况下。报告的问题——Geth Builder 和 Nethermine 未能可靠地赢得竞标——提醒我们，区块生产是一个生态系统协作，而不是单一二进制文件。

构建者可能失败的原因

集成漂移：微小的 API 或负载预期变更可能导致构建者与中继或提议者不同步。时间敏感性：更高的负载暴露了影响竞标的延迟路径。记账不匹配：如果 Gas 语义稍有偏差，构建者对盈利捆绑包的看法可能会偏离网络的看法。

好处很简单：当多个主要构建者在相同的压力配置下出现问题时，它为客户端团队和中继运营商提供了一个共享的、可重现的漏洞来修复。Soldøgn 周期似乎正好产生了这样的结果。

从 DevNet-7 到 DevNet-8：切换前还需要做什么

团队初步计划在 8 月初从 DevNet-7 迁移到 DevNet-8，并列出了一些必须完成的任务：确定最终的重新定价值，并集成强制性的 EIP-8070 引擎 API 变更。没有戏剧性，只是一个清晰的迁移目标。

各开发网日期、关注领域和重要说明如下：Glamsterdam-devnet-6 于 2026 年 6 月 25 日至 7 月初运行，关注基线稳定性、功能标志（包括从第 30 个 epoch 开始的 Gloas），进行了跨客户端事件一致性审查，并捕获了 SSE 事件数据。Glamsterdam-devnet-7 在 7 月周期（包括 Soldøgn 周末）运行，专注于高负载交易测试、构建者竞争力和 Gas 语义，在负载下保持稳定，观察到构建者竞标问题，并进行了持续修复。计划中的 Glamsterdam-devnet-8 目标在 8 月初启动，需要最终确定重新定价并集成 EIP-8070 引擎 API 变更，关键先决条件必须在启动前完成。

为什么 EIP-8070 在此重要

引擎 API 的变更会波及每个执行客户端、中继和构建者路径。即使很小的模式或字段更新也可能破坏中间件的假设。将 EIP-8070 作为 DevNet-8 的强制要求划定了界限：立即更新，否则你将无法参与。

谁应该关注——以及应该做什么

二层网络团队

Gas 语义和重新定价不仅影响 L1。它们还会影响 L2 如何估算费用、选择批次大小以及处理最坏情况的执行峰值。在 DevNet-8 的数字停止变动之前，保持你的 Gas 模型的灵活性。

钱包和 SDK

像“执行 Gas”这样的术语变更会波及用户体验。如果你在应用内标注费用，请跟踪术语，以免混淆用户或支持团队。同时，监控 RPC 响应中与引擎 API 工作相关的细微字段变化。

构建者和中继

如果 Geth Builder 和 Nethermine 在压力下可能出错，那么任何人都可能出错。使用修补后的客户端重新测试集成，演练中继故障转移，并在区块填充速度超出预期时监控延迟预算。

基础设施和节点运营商

随着 DevNet-8 的上线，预计会有另一轮二进制文件更新。谨慎固定版本，并在暂存环境中验证 EIP-8070 兼容性时，保持快速回滚路径。

风险与可能出错的地方

引擎 API 更新的部分采用会导致构建者和中继出现类似分叉的行为。最终的 Gas 重新定价可能遗漏某个边缘情况，导致钱包费用混乱或构建者在压力下定价错误。特定客户端的修复可能在其他平台或旧硬件配置上出现回归。监控和遥测数据的漂移可能使下一个周期的跨客户端调试变慢。术语更新可能已应用于客户端，但未更新到钱包和浏览器中，从而混淆最终用户。

最大的失败不是在开发网中崩溃，而是一个干净的开发网隐藏了主网的问题。不要假设任何事情；在全新的负载模式下重新测试一切。

常见问题

Soldøgn 在此上下文中是什么意思？

这里的 Soldøgn 指的是一个集中的开发者冲刺活动，与 glamsterdam 开发网周期相关。它不是公共测试网事件。可以把它想象成长时间的工作会议，客户端团队、构建者和研究人员在此协调压力测试和补丁。

为什么 glamsterdam-devnet-7 很重要？

这是第一个开发者公开注意到网络在较重负载下保持稳定，同时暴露了值得在下一个周期前修复的构建者竞标问题的周期。这种稳定性与可操作的失败相结合是富有成效的。

“执行 Gas”与“常规 Gas”有什么区别？

团队正在清理 EIP-8037 中的术语，从“常规 Gas”转向“执行 Gas”，以更清楚地说明哪些成本与 EVM 执行相关。这减少了客户端、SDK 和浏览器之间的歧义。

什么是 Gloas，为什么提到它？

根据 EthPandaOps 的事件分析，Gloas 从 glamsterdam-devnet-6 的第 30 个 epoch 开始激活。提到它是为了说明早期测试中哪些功能是开启的；具体细节主要与客户端一致性和日志记录有关。

DevNet-8 预计何时上线？

计划说明指向 8 月初的目标，最终的 Gas 重新定价数字和强制性的 EIP-8070 引擎 API 变更是启动前的关键先决条件。

这些开发网结果今天会影响用户吗？

不会直接影响。开发网是测试网之前的阶段。但修复和命名变更会迅速进入公共测试网，然后进入主网。跟踪开发网变更的钱包、二层网络和构建者将更快适应，并避免后续出现粗糙的边缘问题。

项目团队如何复制 Soldøgn 风格的测试？

使用相同的模式：统一客户端版本，编写多样化的负载配置，记录跨客户端事件，跟踪中继上的构建者结果，并迭代直到你的失败案例消失。然后在每次 API 或重新定价变更后再次进行。

免责声明：本文仅供信息参考。不构成或意图用作法律、税务、投资、财务或其他建议。