一项于10月26日合并的规范变更,修复了以太坊存款处理中的一个漏洞。该漏洞曾可能让节点运营商在网络的Glamsterdam升级激活后,将质押者排队中的存款转入其自行控制的余额。该修复落地于consensus-specs代码库——以太坊各客户端团队所实现的参考规则——距离该漏洞在GitHub上被报告已有两周。只有分叉激活时仍在队列中等待的存款才可能被错误路由,而由于Glamsterdam尚未上线主网,没有资金损失。

节点运营商如何可能获取质押者的存款

池化质押协议通常将运行验证者的工作分工处理:协议提供ETH,而外部节点运营商持有验证者的签名密钥。以太坊将签名与提款分离,因此运营商可以运行验证者,却无法提取协议的质押资金。

Glamsterdam将执行层变更与名为Gloas的共识层升级配对,并在内建的提议者-构建者分离机制下引入构建者这一新型参与者。构建者组装每个区块中携带交易的部分,并持有自己的余额。在分叉时,以太坊会将仍在队列中等待的合格存款转换为构建者账户。

漏洞正是存在于这一转换过程中。根据旧规则,一旦某笔待处理存款为某个密钥注册了构建者,之后该密钥的每笔存款都会充入该构建者,无论其提款凭据指向何处。运营商可以用其控制的地址为一条新密钥排入构建者存款。如果质押协议随后为同一密钥注入验证者存款,且两笔存款在分叉时仍处于待处理状态,协议的ETH将被计入运营商的构建者余额,运营商随后即可将其提取。同时也不会创建任何验证者。某些协议只有在证明新验证者携带其提款凭据后才释放剩余质押资金,而该证明将永远不会出现。

在后续评论中,该问题的报告者列出了可能受此漏洞干扰的设计:Lido的预存款担保、Origin的OETH和Rocket Pool的Saturn,同时指出该列表是快速的AI辅助研究,可能包含错误。在每种情况下,风险敞口都是首笔存款——在ido和Rocket Pool的例子中为1 ETH——剩余质押资金将被锁定,直至执行恢复步骤。报告者将这些描述为条件性的代码发现,而非实际可利用的漏洞。

10月19日被关闭,一周后合并

该修复于10月12日提出。在两次核心开发者电话会议讨论后,它于10月19日因缺乏客户端支持被关闭,测试会议提议在Hoodi测试网升级后再进行原型开发,而不是打乱原有日程。

三天后,以太坊基金会推迟了Glamsterdam在Hoodi上的激活,以调查EIP-8037与现有智能合约的交互问题,该问题与存款无关。多出的时间重新开启了相关讨论。10月23日下一次测试会议议程上的一条评论将存款变更与修订后的时间表挂钩,报告者当天添加了存款排序测试,该变更于10月26日合并。

新规则的作用

分叉后,构建者存款与验证者存款已根据EIP-8282走不同的路径。该修复将相同的逻辑应用于分叉时的队列:由提款凭据而非公钥决定每笔待处理存款的去向。

将同一密钥同时用于验证者和构建者仍然被允许;每笔存款中声明的用途现在决定它为哪个账户注资。

分叉前仍需完成的工作

规范合并只是第一步;各客户端团队现在需要实现相同的规则。Teku于10月27日提交的变更仍在审查中,Lodestar的对应变更也仍处于打开状态。

这一后期变更还必须在每个客户端中以完全一致的方式落地。旧的参考测试编码了先前的路由逻辑,因此遵循新规则的客户端将无法通过这些测试。Teku的开发者报告已通过根据更新后的规范生成的测试,但这些测试尚未打包进正式的规范发布版本。如果各客户端在到达分叉时对同一队列应用不同的规则,它们将计算出不同的余额,并对链的状态产生分歧。

基金会尚未公布新的Hoodi日期或Glamsterdam主网日期。依赖存款证明的质押协议也有自己的防线:据该问题的报告者称,在预存款检查中拒绝已带有构建者存款的密钥,可以防止这一情形。接下来值得关注的指标是两个仍处于打开状态的客户端拉取请求、打包了更新测试的规范发布版本,以及Hoodi和主网的新日期。