Lido CSM v2:社区质押模块升级设计

lido__ 发布于 2025-04-12 阅读 14

本文是Lido社区质押模块(CSM)第二版的设计文档,概述了在以太坊Pectra升级背景下对CSM的多项改进计划。主要内容包括:支持EIP-7002的执行层触发退出机制,用于惩罚延迟退出或表现不佳的验证者;引入“违规标记”系统,对不良验证者进行扣除和退出;改进CSM性能预言机算法,纳入区块提议和同步委员会参与度,并妥善处理错过报告帧;将原有的Early Adoption机制转变为可更新的“认证质押者列表”,以支持不同类别的质押者并定制权限;为认证的独立质押者提供优惠费用、优先存款队列和单独的性能阈值;由于Pectra中初始罚没惩罚降低,移除单独的罚没报告机制。文档还讨论了EIP-7251对大型验证者的影响,并决定在CSM v2中暂不支持。该文档为Lido协议的后续开发提供了详细的技术方向。

[已弃用] CSM v2

本文档已关闭!

请前往以下链接查看并发表评论:https://hackmd.io/@lido/csm-v2-internal

image

社区质押模块(CSM) 第一版自 2025 年 10 月起已在主网上线。为了及时交付与 Pectra 硬分叉相关的更新以及已发现的各项改进,应当启动 CSM 第二版的研究与开发工作。

范围

image

新版本的 CSM 需要实现以下几个重要功能和改进:

  • 支持 EIP-7002,并结合 LoE 协议中的相应变更;
  • 引入 Strikes 系统,允许踢出表现不佳的验证者;
  • 改进 CSM Oracle 算法;
  • 将 Early Adoption 机制转变为 Entry Gates 机制;
  • 为已识别的 solo stakers 引入优惠的奖励分成;
  • 为已识别的 solo stakers 引入优先存款队列;
  • 为已识别的 solo stakers 引入单独的性能阈值;
  • 由于 Pectra 中初始 slashing 惩罚的减少,移除单独的 slashing 报告机制;
  • 针对 Pectra 的变化重新考虑 bond 曲线;

关于 EIP-7251 的说明:提高 MAX_EFFECTIVE_BALANCE

随着 EIP-7251 的引入,以太坊验证者可能会被整合为大型验证者(2048 ETH),也可能在创建之初就是大型验证者。由于验证者数量减少,P2P 网络的负载将显著降低。然而,由于无法为大型验证者指定"自定义上限",stakers 只能在小型(32 ETH)和大型(2048 ETH)验证者之间进行选择。就整体协议的资本效率而言,只有当合并后的大型验证者余额达到 1700 ETH 或以上时,将小型验证者合并为大型验证者或创建大型验证者才有意义(参见 Lido 贡献者的研究结果)。CSM 名称中的"社区"一词,意味着该模块的目标受众是平均运行约 10-20 个验证者的社区 stakers。这意味着,对大多数社区 stakers 来说,合并对协议而言是资本效率低下的。同时,考虑到每个验证者的 bond 要求较低(目前为 1.3 ETH,在 CSM v2 中约为 0.6 ETH),社区 stakers 也不会从合并中获得太多收益。综上所述,由于在底层 LoE 协议没有相应更改的情况下,CSM 无法支持大型验证者,因此建议不要在 CSM v2 中添加对大型验证者的支持。

然而,未来一旦获得各运营者平均验证者数量的真实数据,并且 LoE 协议引入对大型验证者的支持,届时可能会再次考虑支持 EIP-7251 中的大型验证者。

关于 Preconfirmations 支持的说明

Preconfirmations 是以太坊领域的热门话题。目前正在研究如何在 Lido 协议层面实现 preconfirmations 支持。根据研究结果,应考虑将更多功能纳入 CSM v2。

EIP-7002 支持

执行层可触发退出(EIP-7002)将允许质押协议为提款凭证指向其合约的验证者请求退出。然而,这种退出请求方式需要支付费用。因此,现有的通过验证者私钥签署相应消息来请求退出的方式仍然更为可取。

在以下几种情况下,CSM 可能需要使用 EL 可触发退出:

  • 为被 VEBO 请求退出但未及时退出的验证者触发退出;
  • 为长期表现不佳的验证者触发退出;
  • 在验证者私钥丢失的情况下,允许 CSM Node Operators 为自己的验证者触发退出;

第一种情况应在 VEBO 内部解决,因为当退出请求是出于提款覆盖或由于 targetLimit 而发起时,CSM 并不掌握被 VEBO 请求退出的验证者密钥信息。但是,VEBO 应通过"hook"方法告知 CSM 正在为延迟验证者触发退出,以便 CSM 能够惩罚 Node Operator 的 bond。该惩罚不应被销毁,而应转移到 Lido DAO 金库,以弥补 VEBO 为触发退出请求所支付的费用。

由于退出需要针对特定密钥触发,第二种和第三种情况必须由 CSM 直接发起。这意味着 LoE 对 EIP-7002 的实现应支持直接为特定验证者密钥请求触发退出。

在因 strikes 而被踢出的情况下,所有相应惩罚应在踢出时一并施加。值得考虑的是,向方法调用者提供小费,以补偿其 Gas 费用并给予一定溢价。该小费应从 Node Operator 的 bond 中扣除。

对于自愿退出,模块不应施加任何额外惩罚,前提是 Node Operators 自行承担退出的全部费用。

此外,还提议允许 DAO(通过投票或 EasyTrack)明确请求踢出 CSM 验证者。

总结

上述考虑可以总结如下:

  • VEBO 应负责为收到退出请求后未自愿退出的验证者触发退出;
  • 负责触发退出的协议部分应告知 CSM 正在为延迟的 CSM 验证者触发退出(包含 Node Operator ID 信息);
  • LoE 协议应允许 CSM 直接请求为 CSM 验证者触发退出;
  • CSM 应实现 voluntaryEjectValidator 方法,允许 Node Operators 为其验证者请求触发退出;
  • voluntaryEjectValidator 方法应可由 DAO 调用;
  • CSM 应实现一种方法,用于为拥有大量 strikes 的验证者触发退出;

表现不佳 strikes

该主题对于当前文档而言过于宽泛,详情请参阅单独文档

CSM Oracle 算法的改进

目前,已确定对 CSM Performance Oracle 的以下几项改进:

  • 如果在奖励分配 frame 期间有任何验证者被 slashed,则将 Node Operators 从奖励分配池中排除;
  • 引入更复杂的性能计算算法,该算法将纳入区块提议,并可能包括同步委员会参与。参见此处
  • 正确处理错过的 frame。如果某个 frame 因故错过,下一次报告应作为两个报告合并计算的结果,而不是作为一个更长 frame 的报告;

总结

上述考虑可以总结如下:

  • 如果在奖励分配 frame 期间有任何验证者被 slashed,CSM Performance Oracle 应将 Node Operators 从奖励分配池中排除;
  • CSM Performance Oracle 应在所用性能指标中纳入区块提议和同步委员会参与;
  • CSM Performance Oracle 应正确处理错过的 frame,将下一次报告作为两个单独报告的总和交付,而非作为一个更长 frame 的报告;

Early Adoption 机制的演变

Early Adoption 机制的主要目的是允许已识别的 solo 和社区 stakers 在 Early Adoption 期间加入 CSM。该期间从模块部署时开始,一旦结束便无法再次激活。

可以预计,到 CSM v2 升级时 Early Adoption 期间已经结束。因此,将此机制从模块代码中移除似乎是合理的。

反对完全移除 Early Adoption 机制的一个理由是,优惠的 bond 曲线是为那些由 Early Adoption 列表中的地址创建的 Node Operators 设置的。

提议将 Early Adoption 机制转变为可更新的已识别运营者列表。这将允许多个可更新的已识别运营者列表按不同标准分组,例如 solo stakers、公共物品运营者、小型专业运营者等。

为了鼓励这些运营者群体在 Early Adoption 期间结束后仍能加入 CSM,提议:

  • 将 Early Adoption 列表重命名为已识别 stakers 列表(Identified Stakers List(s));
  • 将现有 Early Adoption 列表中尚未加入 CSM 的参与者转移至已识别 solo stakers 列表(Identified Solo Stakers List);
  • 允许 Lido DAO 更新已识别 solo stakers 列表,以便在 CSM 运营期间添加新的 solo stakers;
  • 允许无权限参与者在加入 CSM 后,如果其地址被添加到已识别 solo stakers 列表,则可以领取 solo staker 福利;

已识别 stakers 列表这一功能将需要对 CSM 合约进行重大更改,如下图所示:

image

需要新增一个 permissioned 方法 createNodeOperatorVettedAddressesRegistry 的实例可以在执行预先检查后创建 CSM Node Operators。同时需要 PermissionlessGate,以维持 CSM 的无权限准入。

每个入口合约都应具备暂停功能,以缓解可能出现的列表问题。列表可以通过 EasyTrack 更新,以降低治理负担。

由于入口合约通过角色机制挂接到 CSM,第三方可以开发自己的 gate 合约。Gate 合约既可以是向运营者分配自定义 bond 曲线的入口 gate,也可以是拥有自己的记账逻辑和底层运营者结构的全功能附加组件(例如用于 DVT)。这为第三方 CSM 集成打开了巨大的潜力空间。

一种名为 Gates and Extensions 的更通用方法在单独文档中有详细描述。提议在 CSM v2 中实现这一通用方法。上文描述的方案可以视为该通用方法的一个特例。

为已识别 solo stakers 提供优惠费用

渐进式费用是一个可能实现 CSM 可持续增长的选择。简而言之,CSM 可以为前 N 个验证者、接下来的 M 个验证者等设定不同的费用。这样既可以对前 N 个验证者(早期加入者)收取较高费用,又能确保模块增长的费用结构保持可持续。

CSM 在 Staking Router 层面的费用无法做到可变。因此,应将其设置为最高可能值。CSM 应能够在 Oracle 报告时将多余的 stETH 奖励转移到 Lido DAO 金库。CSM Oracle 应在链下管理费用分配。

关于渐进式费用的更多考虑,请参见此处

总结

上述考虑可以总结如下:

  • CSM 在 Staking Router 中的费用应设置为 CSM 验证者所需支付的最高可能费用;
  • CSM 应能够在 Oracle 报告时将多余的 stETH 奖励转移到 Lido DAO 金库;
  • 费用参数应存储在链上,并应可由 Lido DAO 配置;

为已识别 solo stakers 提供优先存款队列

"solo staker 应该总是有一种方式可以加入 CSM 并快速开始验证" - Max

为已识别 solo stakers 提供优先存款队列的核心思路是:当 CSM 队列已排满无权限运营者时,为已识别的 solo stakers 提供可行的机会,让他们在合理的时间内加入 CSM 并开始验证。将该福利限制在特定数量的验证者密钥上,对于防止已识别 solo stakers 列表产生活跃的衍生列表至关重要。

提议引入一个独立的优先队列。如果 Node Operator 是已识别的 solo staker,其上传的前 N 个密钥应放入优先队列,并在主队列之前处理。

此外,该方法还可以扩展为多个优先队列。更详细的信息参见单独的文档

总结

上述考虑可以总结如下:

  • CSM 应为已识别的 solo stakers 实现优先存款队列;
  • 只有已识别 solo staker 上传的前 N 个密钥应放入优先队列;
  • 优先队列应在主队列之前处理;

为已识别 solo stakers 设置单独的性能阈值

随着 CSM 不断壮大,Lido DAO 可能会考虑提高 CSM Performance Oracle 所使用的性能阈值。这将导致对已识别的 solo stakers 提出更严格的性能条件。

提议为已识别的 solo stakers 引入单独的性能阈值,从而为其保留现有的性能阈值;而无权限运营者的性能阈值则可能会相应提高。

总结

上述考虑可以总结如下:

  • CSM 应为已识别的 solo stakers 实现单独的性能阈值;

参数注册表(Parameters registry)

为了支持上述三个功能并将其扩展到其他已识别 stakers 列表,需要一个独立的注册表合约。该合约在单独文档中有详细描述。

如果 CSParametersRegistry 是可升级的,这种方法将允许在未来添加更多的福利和参数。

移除单独的 slashing 报告

随着 EIP-7251 的引入,初始 slashing 惩罚将从 1 ETH 降至 1/64 ETH(针对 32 ETH 验证者)。考虑到相关的 Gas 费用,在 Pectra 之后报告初始 slashing 将变得毫无用处。

关于解决方案空间的更多细节,请参见此处

总结

上述考虑可以总结如下:

  • 应从 CSM 和 CSVerifier 中移除用于 slashing 报告的无权限方法;

链接

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

相关文章

0 条评论