关键事实

Ethereum 开发人员于周一合并了一项针对共识规范的更改，该更改通过提款凭证对 Gloas 分叉中的待处理存款进行路由。此修复方案确保即使构建者使用相同的密钥，验证者存款仍保留在验证者队列中，从而堵住了一个漏洞：该漏洞可能将一方资助的验证者存款错误地记入由另一方控制的构建者名下。

该提案最初因缺乏客户端支持而于 10 月 19 日关闭，但在经过新的测试和审查后，于 10 月 23 日重新开放并于周一合并。

Ethereum (ETH) 开发人员已合并了对 Glamsterdam 升级规范的修复，当升级激活时，该修复可防止验证者存款被记入与构建者共享相同密钥的区块构建者账户中。

根据引发此次更改的问题描述，在一个示例场景中，该漏洞可能允许运营商提取质押协议支付并投入验证者存款的 ETH。

10 月 12 日提交该问题的贡献者写道：“在 Gloas 分叉时，`onboard_builders_from_pending_deposits` 功能可能会将由一方资助的验证者存款记入由另一方控制的构建者名下。”Gloas 是 Glamsterdam 的共识层部分。”以太坊/consensus-specs 仓库中的拉取请求 #5736 于 10 月 26 日合并。来源：GitHub

Glamsterdam 存款漏洞的工作原理

根据修复前的分叉规则，一旦待处理存款注册了某个构建者，后续针对同一公钥的存款将补充该构建者的额度，无论其提款凭证如何，问题描述中指出这一点。

在其示例中，运营商为新密钥排队了一个构建者存款，随后一个质押协议为该密钥注资了一笔验证者存款。

“如果两笔存款在分叉时都处于待处理状态，那么两笔金额都将归入该构建者名下。运营商可以提取协议的资金。”问题描述中称。

根据协议设计的具体情况，这可能会破坏会计记录、导致相关资金被锁定或阻碍协议的正常恢复路径，问题描述指出。

合并后的修复内容

该拉取请求通过提款凭证对分叉时的待处理存款进行路由。即使构建者使用相同的密钥，验证者存款仍保留在验证者队列中，而有效的构建者存款则用于注册或补充构建者额度。

后来合并了此项更改的 GitHub 用户 jtraglia 曾于 10 月 19 日关闭该提案，表示“当时客户端的支持力度不足以进行此项更改”。该提案于 10 月 23 日重新开放，并在审查员批准后于周一合并。一位审查员表示，新增的测试“涵盖了我们关注的场景”。

审查员 potuz 写道：“我找不到任何利用此漏洞的方法，但这并不意味着不存在任何方法。”他补充说，尽管对此在分叉前引入此更改仍感到“担忧”，但随着分叉状态现在变为“未知”，有“充足的时间来研究此更改”。

此项修复是在开发人员上周推迟 Hoodi 测试网上的 Glamsterdam 升级之后落地的。

该问题的示例主要围绕代表运营商注资验证者存款的质押协议展开。Glamsterdam 本月早些时候在 Sepolia 测试网上线，Lodestar 客户端团队已开放一项拉取请求以实施共识层更改。