以太坊(ETH)开发者合并Glamsterdam存款修复方案 此前方案曾于10月19日被否

Glamsterdam前存款规则重写

以太坊(ETH)下一轮升级的客户端团队如今拿到了一套修订后的存款规则,可以并入各自软件。开发人员已合并一项补丁,封堵了即将到来的硬分叉Glamsterdam中的一个资金盗取漏洞。该变更于星期一通过一项拉取请求进入共识规范,改写了待处理存款的排序方式。按照新规则,质押服务机构为激活共识机制下的验证者而发送的资金,不能再被以构建者身份注册了同一标识符的运营方认领。漏洞出在Glamsterdam处理尚未入账存款的方式上:运营方可以先用某个特定公钥注册为构建者,公钥是验证者或构建者绑定的标识符。如果质押服务机构随后用同一把钥匙存入Ethereum (ETH)来启动验证者,草案规则会把两笔存款都记在构建者名下,后者便可提取协议资金。由于验证者根本不会被创建,质押服务机构无法出示追回资金所需的证明。修复方案按取款凭证对待处理存款排序,该设置决定存款资金最终去向,这样即便构建者使用同一把钥匙,验证者的存款仍归验证者所有。修订后的规则已并入各客户端共同遵循的规范正文。该风险从未波及以太坊(ETH)价格或已质押余额:它只涉及按草案规则处理的存款,目前没有损失报告。

打开这扇门的设计选择,本身就是Glamsterdam的核心。这次升级把今天捆绑在单一角色中的两项职责拆开:构建者组装交易区块,而质押ETH、在权益证明下协助维护网络安全的验证者负责挑选并确认区块。双方都可以存入ETH,资金本应分开记账,这正是流动性质押服务商及其储户资金安全的前提。攻击场景由研究员avsetsin在consensus-specs仓库的一项议题中列出,他还评估了Lido、Origin和Rocket Pool可能受到的影响。风险敞口取决于各协议处理存款的方式。avsetsin在Lido的GitHub组织中列名,他把结论定性为条件性的代码发现,而非已确认的线上利用,并补充说,现有机制会拒绝较早的构建者存款,这在实际中可能阻止攻击。研究员对核心案例的总结很直白:“运营方可以提取协议的资金。”这个补丁的合并之路并不平坦。10月19日,开发人员曾关闭拟议的修复方案,维护以太坊共识规范的Justin Traglia当时写道,客户端对该变更的支持不足。客户端是验证者运行、用于参与网络的独立软件程序。经过进一步审查后拉取请求被重新打开,avsetsin在10月23日补充了测试,Traglia于星期一合并了变更,距最初被否恰好一周。

客户端工作与Hoodi推迟

修复如何落地,与修复本身同样重要。Glamsterdam已在Sepolia测试网上运行,但原定10月26日在第二个测试网络Hoodi上的启动被推迟。存款变更在同一天并入规范,这表明开发人员是借推迟之机,在又一次公开演练之前落定修复,而不是带着已知的存款入账缺陷发布升级。剩下的工作是实现。合并进共识规范只是设定了目标,客户端团队仍需把新的排序规则写进自己的软件,主网日期才有讨论的基础。在客户端版本带上修订后的存款处理逻辑之前,Glamsterdam的时间表掌握在客户端开发者手中;而重新排期后的Hoodi,会给他们一个完整的网络来预演这次变更,然后再上主网。