以太坊拟于10月6日在Sepolia激活Glamsterdam

ACDC #186会议纪要及以太坊协议研究员Christine D. Kim的后续报道显示，该日期仍为暂定。开发者在选定Sepolia时间表时，尚未在私有开发网络上完成稳定的Glamsterdam激活。

测试计划此后又推进了一轮迭代。Kim于9月11日表示，关注点已转向Glamsterdam-Devnet-11，该网络预计于9月14日（周一）启动。此前计划曾将Devnet-10列为下一项主要测试。

Hoodi测试网和以太坊主网的激活日期均未确认。开发者曾讨论可能在12月发布主网，但测试结果将决定该时间表是否仍可行。

在9月3日的全核心开发者共识会议上，与会者同意将Sepolia epoch 351232作为拟议激活点。Kim报告称，对应时间为UTC 10月6日13:53。会议召开时，开发者尚未在用于Glamsterdam的私有测试网络上展示稳定性能。

选定epoch为客户端团队、基础设施运营商和应用开发者提供了一个共同的规划目标，但这并不代表激活已成定局。如果下一阶段测试发现重大故障，或客户端团队无法准备可靠的版本，开发者可以推迟分叉。

在Devnet-9出现最终性（finality）问题后，这一保留条件仍然重要。根据会议材料，该网络包含约1,000个验证者节点，是当时验证者数量最多的Glamsterdam开发网络。

最终性要求足够多的验证者就链状态达成一致。当测试网络无法最终确认时，开发者必须判断原因涉及客户端软件、验证者参与、网络配置，还是不同协议变更之间的交互。

Devnet-11将在Sepolia之前测试修复

原计划是在此前试验出现故障后启动Devnet-10。Kim的最新更新将Devnet-11列为开发者正在关注的下一个测试，表明私有测试序列已超出早前计划。

稳定的Devnet-11将为以太坊客户端团队提供另一个测试Glamsterdam组合规范的环境。Layer-2团队、质押服务商和其他基础设施运营商需要可用的客户端实现，才能安全地针对拟议分叉测试其系统。

客户端多样性使流程更加复杂。以太坊通过多个独立开发的执行客户端和共识客户端运行，升级必须能在不同客户端组合下正常工作。即使故障仅限于某个实现，当受影响的验证者拥有足够权重时，仍可能中断测试网络。

ACDC #186议程记录了Lido和Optimism提出的要求：分叉前至少需要一天稳定运行。议程将客户端修复和成功的互操作性列为Sepolia之前需要确认的事项。

Devnet-11失败或不稳定不会自动取消10月6日的激活。开发者需要评估原因和修复所需时间。严重问题可能导致他们在全核心开发者会议上重新考虑该日期。

共识层与EIP-8037漏洞延长了测试

此前的Glamsterdam试验暴露了以太坊架构两侧的故障。以太坊基金会开发者运维工程师Stefan Starflinger报告称，Devnet-8揭示了一个共识层问题，涉及重复父哈希的区块。

“你可能会让整个网络停止。”Starflinger在描述测试场景时表示。

该问题影响了负责区块共识的系统。随后Devnet-9出现非最终性，促使工程师在更大的验证者集合中调查更多边缘情况。

在执行层方面，以太坊基金会研究员Maria Silva报告了一个涉及EIP-8037的实现问题。该提案改变了以太坊为创建新状态（包括新账户、合约和存储条目）收取gas的方式。

EIP-8037通过多维gas模型将状态创建成本与正常执行成本分离。其公开规范称，该设计旨在以太坊提高区块gas上限时控制状态增长。该提案仍在同行评审中。

发现的问题要求执行客户端修改其实现，并引发了规范工作。EIP-8037已与升级中的其他协议变更一同测试。

测试的目的不同于单独批准每项提案。开发者必须确认所有选定的变更能在多个客户端、验证者配置和交易模式下协同工作。

Hoodi和主网日期取决于测试结果

在Sepolia仍为暂定的情况下，开发者拒绝为Hoodi安排Glamsterdam。Hoodi预计将作为第二个公共测试网阶段，为质押运营商和协议团队提供另一个更接近主网条件的环境。

Teku开发者Enrico del Fante支持在确定Hoodi日期前继续等待。在ACDC #186期间，他引用了最近的Devnet-9问题，并倾向于在Sepolia决定后留出更多测试时间。

12月主网激活仍是一个可能的目标，而非确认的发布窗口。将Sepolia安排在10月初，为另一个公共测试网阶段和客户端发布准备保留了足够的日历时间，前提是测试进展不会出现长时间延误。

开发者尚未公布主网epoch、激活时间戳或最终的客户端发布计划。关于10月6日是否仍适合Sepolia，尚未宣布正式的决定截止日期。

当前最直接的流程事件是计划于9月14日启动的Devnet-11。客户端团队将检查最终性、跨客户端行为以及此前测试后引入的修复，再决定Sepolia能否按当前时间表推进。