从CSM中移除初始削减

lido__ 发布于 2024-12-04 阅读 11

文章针对以太坊Pectra硬分叉后共识层初始削减惩罚值的变化,探讨了Lido CSM模块的应对方案。当前CSM会在收到削减报告时立即销毁该惩罚值,但新协议下该值已不再适用。作者提出三个选项:A. 直接更新模块中的惩罚值,简单但存在跨升级账本不一致风险;B. 提前通过CSVerifier禁用削减报告,最安全但需重新审计和链上投票;C. 忽略该问题,假设期间不会发生削减,随CSM v2移除相关代码,最省事但依赖乐观假设。结论认为B最稳妥,C最直接但风险较高。

我们的目标

我们需要处理与 Pectra 硬分叉带来的 CL 初始 slashing 惩罚值变更相关的问题。该值目前在 CSM 模块中使用,用于在提交 slashing 报告时立即销毁这笔惩罚。

我们的最终目标是从系统中移除所有与 slashing 相关的代码,因为它在当前协议状态下已不再有意义。即使模块支持 MEB,大部分惩罚也将在 slashing 期间本身就被应用。

有多种方法可以实现下述目标。

A. 更新模块中的 INITIAL_SLASHING_PENALTY

所需操作

  • 部署一个使用更新变量值的新 CSM 实现,并完成部署验证
  • 发起并通过 Aragon 投票

优点

  • 无需重大操作或资源
  • 无需重新审计
  • 可随支持 Pectra 的 CSVerifier 实例接入一并纳入

缺点

  • 需要投票
  • 从模块角度来看不够安全(见下文注意事项)
  • 仍需在取款时保留对销毁值的检查

注意事项

  • 理想情况下,我们应该在硬分叉时更改该值
  • 如果在升级(投票)之前提交了 slashing 报告,导致 1 ether 的惩罚被销毁,然后在升级之后提交取款报告,CSM 使用更新后的 INITIAL_SLASHING_PENALTY 值时,合约将无法正确核算先前已销毁的惩罚。这会导致总销毁量超过所需量的问题。该问题可以通过调整 CSM 模块本身的逻辑来解决,但这样做会抵消无需审计的优势。

B. 远在 Pectra 之前通过 CSVerifier 禁用 slashing 报告

所需操作

  • 准备更新后的 CSVerifier 代码并重新审计
  • 部署 CSVerifier 并完成部署验证
  • 发起并通过 Aragon 投票

优点

  • 从模块角度来看是最安全的方式
  • 能够在即将发布的 CSM 版本中移除取款时的 slashing 惩罚检查

缺点

  • 需要重新审计 CSVerifier
  • 需要在二月中旬进行链上投票

C. 在 prover 实例上禁用 slashing 交付,并通过 CSM v2 移除所有初始 slashing 相关代码

该方案依赖于一个假设:在 v2 升级完成之前,不会有新的 slashing 报告提交给 CSM,或者任何此类报告都不会附带 slashing 证明。鉴于历史背景(总共只有几百个验证者被 slashed),并考虑到唯一有兴趣向 CSM 提交 slashing 的参与者是 Lido,这一假设似乎是合理的,并且很可能成立。

如果我们的假设被证明是错误的,并且在升级之前或期间有 slashing 报告提交给 CSM,那么在最坏的情况下,可能会出现:

  • 运营商被重复施加惩罚
  • 可能已解除质押的运营商,其请求退出的验证者因该问题而卡住

所需操作

  • 禁用 prover 机器人部分链下逻辑
  • 祈祷不会发生 slashings!
  • 发布 CSM v2

优点

  • 无需处理该问题,只需发布 CSM v2

缺点

  • 依赖一个有风险的假设
  • 如果计划失败,需要大量操作

结论

从模块角度来看,选项 B 似乎是最安全的方法,但它需要重新审计 CSVerifier 并进行链上投票。选项 C 是最直接的解决方案,但它依赖于一个可能过于乐观的假设。

  • 原文链接: hackmd.io/@lido/SyGQJp2Q...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论