以太坊基金会推迟Glamsterdam升级,错过10月27日测试网激活窗口

以太坊将Glamsterdam从Hoodi测试网撤回

以太坊(ETH)的Glamsterdam升级在距离主网上线仅一步之遥的测试网阶段被叫停。主网才是代码真正生效、承载实际业务的网络,而测试网则是在此之前验证新功能与稳定性的演练场。以太坊基金会在10月22日(星期四)发布的博客文章中说明,最新一次核心开发者会议已决定推迟Glamsterdam在Hoodi测试网上的激活时间。按照原计划,这次升级应在10月27日凌晨2时42分(韩国时间)触发,对应10月26日17时42分(UTC),距公告发布仅剩五天。目前没有替代日期,基金会表示新日期将另行公布。官方给出的原因是EIP-8037,这是一项以太坊改进提案,其对主网智能合约代码的影响需要进一步调查,开发者才肯推进,哪怕只是在演练网络上。原方案中,执行层与共识层本应在一个协调步骤中同步激活,这也正是Glamsterdam未来主网部署的形态。此次决定撤回了分叉两半的激活时间表:执行层的Amsterdam负责处理交易与合约调用,共识层的Gloas负责处理证明与最终性。与此同时被撤下的,还有把Hoodi的燃料费上限提升到2亿的计划。燃料费上限规定单个区块能承载的计算量,是需求上升时决定燃料费水平的关键参数。推迟发生在激活窗口前五天,等于在几乎没有缓冲的情况下,从节点运营者的日程表上抹掉了一个固定事件。需要说明的是,以太坊价格与这次决定无关,它出自协议自身的发布流程,基金会也将其定性为时间表调整,而非设计变更。

回滚的是配置,不是链上历史

基金会对这次推迟的边界说得很清楚。撤销升级配置,并不会回滚Hoodi上已经记录的区块链历史,区块保持原样,被撤回的只是面向未来的激活计划。Glamsterdam本身由两个部分组成:执行层的Amsterdam与共识层的Gloas,这一双客户端结构延续了以太坊转向权益证明以来的架构。正是这种结构,让运营者的检查清单变得相当繁重。Hoodi上的节点与验证者运营者现在必须确认分叉不会在原日期触发,具体做法是核对执行层与共识层客户端的版本说明,确认其中不再列出10月27日的激活安排。基金会还要求运营者逐一核实每个开发团队的发布指引是否已删除旧时间表,目的是防止测试网在仍然预期Glamsterdam的客户端与不再预期的客户端之间发生分裂。燃料费上限的撤回也值得单独一提:2亿的上限原本要在同一窗口内提升Hoodi的吞吐量,因此这次推迟连同这项单独的参数校准工作一并搁置。硬分叉只有在所有以太坊客户端在同一区块切换到兼容代码时才能成立,当年从以太坊1.0到2.0的转型,正是在大得多的规模上执行了同样的纪律。对运营者来说,眼下的任务很具体:阅读各客户端团队的部署指引,在新日期确定之前完成补丁。基金会的长线规划仍在并行推进,包括此前报道过的、在2029年12月前完成抗量子L1改造的目标,但Glamsterdam自身的路径,现在必须先穿过悬而未决的EIP-8037审查和一个尚未命名的新日期。

EIP-8037仍是拦路关卡

我们对这次发布流程的判断是:Glamsterdam还要过的关卡,先是EIP-8037审查获得放行,然后才是一个可供运营者同步对齐的、重新标记的激活日期。把2亿燃料费上限的提升与分叉一并撤回,是最值得琢磨的细节,它表明开发者希望Hoodi在被提案对主网合约的影响完全摸清之前,维持在一个已知状态。在基金会公布新日期之前,Hoodi将保持在当前配置上运行,Glamsterdam的主网时间线也继续处于待定状态。