🏛️ 社区质押模块架构

本文档描述了 Community Staking Module（CSM）的架构。该模块实现了 Community Staking Landscape 中提出的构想。本文的主要目的是详细说明 CSM 架构及关键设计决策。

文中 validator、key、validator key 和 deposit data 等术语的含义保持一致。

∑ TL;DR

CSM 是一个无需许可的质押模块（staking module），旨在吸引社区质押者（community stakers）以节点运营商（Node Operator）身份参与 Lido on Ethereum 协议。加入 CSM 成为 Node Operator 的唯一要求是能够运行验证者（validator）并提供保证金（bond）。只要密钥有效，质押金便会按照密钥的提交顺序分配给验证者密钥。Bond 并不直接与某个验证者的实际质押额Hook，而是作为安全抵押品。Bond 是 Node Operator 的一项属性，因此它为其名下的所有验证者提供抵押。这样一来，所需 bond 就可以随验证者数量增加而降低。Node Operator 名下的验证者越多，单个验证者对应的 bond 就越少。Node Operator 的奖励来源于 bond 的 rebase 收益，以及其在质押奖励（staking rewards）中的分成。若验证者表现高于阈值，则其对应的 staking rewards 部分会被社会化（即平均分配）。累积的 CL 惩罚若导致验证者余额降至存款余额以下，或发生 EL rewards 被窃取的情况，相应金额将从 Node Operator 的 bond 中没收。Node Operator 应在协议请求时执行验证者退出，也可以自行选择退出。

📓 术语表

• Staking router（SR）是 Lido on Ethereum 协议中的智能合约，负责在不同模块之间分配质押和分发奖励；
• Staking module（SM）是连接到 staking router 的一个或一组智能合约，负责：
  • 维护底层 operator 和 validator 集合，
  • 负责 operator 的加入/退出，
  • 维护 validator 的 deposits、withdrawals 和 exits，
  • 维护模块及参与者的费用结构和分配等；
• Bond 是 Node Operator 提供的 ETH 或 stETH，用于对其不当行为或低绩效提供抵押；
• Lido DAO 是一个去中心化自治组织，通过治理代币（LDO）的投票权决定受控流动性质押协议的关键参数。
• Node Operator（NO）是运行 validator 的个人或实体；
• Lido 是 Lido on Ethereum 协议的核心合约，负责存储协议状态、接受用户提交，并包含 stETH 代币；
• stETH 是由 Lido 铸造的 ERC-20 代币，代表 totalPooledEther 的份额；
• Deposit data 是指由 validator 公钥和提交给 DepositContract 的存款签名组成的结构。该术语在文中也称为 keys。Validator 私钥仅由 Node Operators 创建、存储和管理；
• DepositContract 是用于 validator 存款的官方合约；
• DepositSecurityModule 或 DSM 是一组智能合约及链下组件，用于缓解相关漏洞；
• 当某个 validator 无法被当前 Node Operator 的 bond 完全覆盖时，该 validator 被视为 “unbonded”；
• 如果 validator 在收到协议退出信号后没有及时退出，则会被视为 “stuck”；
• Curated module 是第一个 Lido staking module，此前称为 Node Operators Registry；
• EasyTrack 是一套智能合约及基于否决权的替代投票模型，用于简化日常 DAO 操作；
• AccountingOracle 是一个合约，负责收集链下预言机提交的关于 Lido 参与验证者及其余额的状态信息、协议金库（即 withdrawal 和 execution layer rewards 金库）积累的资金量、已退出和 stuck validator 的数量、协议可处理的 withdrawal request 数量，并分发 node-operator rewards。

🌎 总体信息

CSM 是一个带 bond 要求、支持无需许可加入的 staking module。该模块旨在为独立的社区质押者（solo stakers 或 home stakers）提供一条清晰的路径，使其进入 Lido on Ethereum 协议（LoE）的 Node Operator 集合。Bond 要求是一项重要的安全与对齐机制，它使无需许可的加入成为可能，同时不会损害底层质押协议（LoE）的安全性或可靠性。

🤓 模块特性

所有 staking modules 都应当遵循相同的 IStakingModule 接口。这不可避免地导致各个模块在组件和逻辑上存在大量共性。CSM 也不例外。例如，其 key 存储组件便是基于现有 Curated module 构建的。不过，仍有几个方面有所不同，值得单独说明。

Exited 与 Withdrawn

Curated module 将 validator 的“exited”状态（包括 Slashed and Exited 和 Unslashed and Exited）视为核算中最后一个有意义的状态，因为在此状态之后，validator 不再对 Beacon 链上的任何职责负责（延迟 sync committee 参与等罕见情况除外）。而 CSM 则需要了解每个 validator 的准确提款余额（withdrawal balance），以便决定是否对 bond 进行惩罚。因此，该模块仅使用 accounting oracle 报告的“exited”计数器来向 staking router 返回正确的“active”密钥数量，同时实现无需许可的报告方法，在 validator 进入 Withdrawable 状态后报告其提款余额（实际报告在其完成提款后发生）。

Stake 分配队列

Node Operator 必须提供 bond 才能向 CSM 上传新的 validator key。按照与 bond 提交顺序相近的顺序来分配 stake，是比较合理的做法。为此，CSM 使用 FIFO（先进先出）的 stake allocation queue。当 Staking Router 请求密钥以进行存款时，会从队列中取出接下来的 $X$ 个 keys，并保持 bond 提交时的顺序。

针对“stuck” keys 的替代措施

Node Operator 名下存在“stuck” keys，表明其违反了 Lido 退出政策。在这种情况下，模块应当对违反政策的 Node Operator 采取措施。CSM 采用了与 Curated module 不同的措施，具体内容在下方相应章节中描述。

Node Operator 数据结构

CSM 中的 Node Operator 数据结构与 Curated module 类似，但存在几处细微差异：

• 省略了 name 属性，因为对无需许可的模块来说它并不必要；
• rewardAddress 仅用作奖励和超额 bond 申领的接收地址；
• 新增 managerAddress 属性，Node Operator 需要从该地址发起方法调用；
• 新增 totalWithdrawnKeys 属性，用于统计每个 Node Operator 已提款的密钥总数；
• 新增 depositableValidatorsCount 属性，用于统计当前符合存款条件的 deposit data 数量；
• 新增 enqueuedCount 属性，用于跟踪尚未入队的 keys；

🔄 CSM validator 生命周期

描述 CSM 架构的最佳方式是沿着 validator 的生命周期展开。

🚪 第 1 步：加入 CSM

加入 CSM 流程

创建 Node Operator

要成为 CSM 中的 Node Operator，或为现有 Node Operator 注册新的 validator，至少需要提供一个 validator pubkey、对应的 deposit signature 以及相应的 bond 金额。

准备并上传 Deposit data

CSM 接受与 Curated module 相同格式的 deposit data（validator pubkey + deposit signature），其主要区别在于要求 Node Operator 在上传 deposit data 之前或同时提交 bond。

deposit signature 必须签署 (deposit_message, domain) 的根。其中 domain 用于标识链，deposit_message 为以下元组形式：

• validator pubkey；
• withdrawal_credentials，其中包含实际的 Lido Withdrawal Vault 合约 地址；
• 32 ETH amount；

Bond

在下文中，“bond”一词的含义如下：

Bond —— Node Operator 在向 CSM 上传 validator keys 之前必须提交的安全抵押品。该抵押品用于弥补 Node Operator 不当行为可能造成的损失。一旦 validator 退出 Beacon 链，且所有已发生的损失得到弥补，该抵押品即可被申领或用于上传新的 validator keys。

Bond 是 Node Operator 的属性，而非 validator 的属性。Bond 以 stETH 形式存储。Node Operators 可以提交 ETH、stETH 或 wstETH 作为 bond tokens。提交的 ETH 会被质押，wstETH 则会在提交时解包，以确保 stETH 是 bond 的唯一形式。

所需 bond 总额取决于 Node Operator 名下的 validator 总数，其形式为 getBondAmountByKeysCount(keysCount) 函数。

为方便读者理解，上图可以按单个 validator 而非 validator 总数重新绘制。

系统中可能存在多条 bond“曲线”（即 getBondAmountByKeysCount 函数的不同实现）。所有 Node Operators 在创建时都会被分配一条默认曲线，DAO 也可以为某个 Node Operator 设置自定义曲线。

已有 Node Operators 可以在不提交 deposit data 的情况下补充 bond，以弥补惩罚造成的损失，或提前存入 bond 资金。

Unbonded validators

引入“unbonded”这一术语，用于指代 bond 无法完全覆盖的 validator。考虑到 bond 对 Node Operator 名下所有 validator 是共用的这一设定，可按下图所示方式判断哪些 validator 处于 unbonded 状态。示例中，validator $N+1$ 即为 unbonded。

负 stETH rebase 可能带来的影响

由于 bond 以 stETH 存储，存在因 stETH 负 rebase 导致 bond 金额减少的风险。这可能导致部分 Node Operators 因实际 bond 低于要求而无法领取奖励，甚至使 validator 变为 unbonded。该问题在 Lido ADR 的 Bond 机制 中有详细说明。就本文而言，由于 stETH 负 rebase 发生概率较低，且 Lido DAO 掌握一笔可用的专项基金可用于兜底，因此 CSM 无需额外措施。

Deposit data 的验证与失效（即 vetting 与 unvetting）

鉴于即将上线的 DSM v1.5 升级，CSM 将采用 optimistic vetting 方案。上传的 deposit data 默认视为有效，除非 DSM 报告其无效。一旦检测到无效的 deposit data，DSM 会调用 decreaseOperatorVettedKeys，将 vettedKeys 指针设置到第一份无效 deposit data 之前的位置。

可存入的密钥（Depositable keys）

是否可以使用相应 deposit data 进行存款，取决于多个因素。这些信息体现在 Node Operator 的 depositableKeys 属性中。该属性表示从 Node Operator key 存储中最后一条已存入记录开始、按顺序提取出的可供 staking router 存款的 deposit data 记录数量。该数量的计算方式如下：

• 未设置 targetLimit：$vettedKeys - depositedKeys - unbondedKeys$；
• 已设置 targetLimit：$\min(vettedKeys,targetLimit) - depositedKeys - unbondedKeys$；若 Node Operator 存在 $stuckKeys \neq 0$，则为 $0$。

Stake 分配队列

CSM 中的 stake allocation queue 是一个传统的 FIFO（先进先出）队列。Node Operators 以 {noId, keysCount} 批次占用队列位置，等待轮到自己。

当队列轮转到 Node Operator 的批次时，CSM 会通过公式 $\min(depositableKeys, keysInBatch)$ 检查该批次中有多少 keys 可以被存入。

可能会出现这样的情况：Node Operator 的部分 keys 由于在队列遍历时还不具备存款条件而被跳过，因此不在队列中。normalizeQueue 方法允许 Node Operators 将所有可存入的 keys 重新放回队列。

关于 CSM 中的 deposit data 存储，存在多个指针，其中包括 totalKeys 和 vettedKeys。在采用 optimistic vetting 方案的情况下，如果没有关于无效 deposit data 的报告，这两个指针在大多数时候应保持同步（$totalKeys = vettedKeys$）。因此，deposit data 可以通过两种方式进入队列：

• 上传 deposit data 后，如果满足 $totalKeys = vettedKeys$；
• 调用 normalizeQueue 方法后，如果某些 keys 在上传时未能进入队列（上传时 $totalKeys \neq vettedKeys$），或在队列遍历时被跳过；

系统还提供了一些方法，用于检查接下来的 $X$ 个元素，并移除其中不包含可存入 keys 的元素。这些方法用于确保即使在极端场景下队列也能正常运行——例如队列被大量不可存入的 keys 严重“污染”。

队列的详细说明见单独文档。

删除 Deposit data

如果上传的 deposit data 尚未被存入，Node Operator 可以自愿将其删除。每删除一个 key，都会从 Node Operator 的 bond 中扣除 keyRemovalCharge，用于覆盖与队列处理相关的最大可能运营成本。Deposit data 可以按连续批次删除（例如从索引 5 到 10）。

如果与 deposit data 对应的 validator 已被协议存入，则 Node Operator 无法删除该 deposit data。停止验证职责的唯一方式是在 CL 上退出该 validator。一旦 validator 完成全部提款，Node Operator 即可申领超额 bond。

🤑 第 2 步：奖励

奖励概览

CSM Node Operators 可以获得两类奖励：

• Node Operator 奖励；
• Bond 奖励；

Node Operator 奖励来自 LoE 协议在 Consensus 和 Execution layers 奖励中的份额。这些奖励按完整 32 ETH validator 奖励的一定比例计算。Node Operator 奖励在所有 staking modules 之间按相同方式分配，即根据每个模块的 active validator 数量按比例分配，其中 $active = deposited - exited$。每份 Accounting Oracle 报告都会向 CSM 分配新的 staking rewards 份额，这些奖励会先存放在模块中。随后，CSM Performance Oracle 每个 frame 使用 Merkle tree 提交 CSM Node Operators 的奖励分配，使新的一部分奖励可供领取。

Bond 奖励（rebase）部分的来源在于：stETH 是一种 rebasing token，而 bond 以 stETH 存储。每次 Accounting Oracle 报告后，shareRate 都会发生变化（多数情况下是上升）。因此，同样数量的 stETH shares 会对应更多的 stETH tokens。

总奖励的公式为：$totalRewards = 32 * moduleFee + bondAmount * shareRateChange$。更多细节可参见相关帖子。

总奖励中有相当一部分来自 bond rebase。Bond 与 Node Operator 奖励在领取前会先合并。最终可领取的奖励金额按 $bond + NodeOperatorRewards - bondRequired$ 计算。这种方式也确保任何缺失的 bond 都会在领取奖励前被协议先行收回。

此外，任何超额 bond 也会被视为奖励。

Performance Oracle

Performance Oracle 会构建一棵包含 staking rewards 分配的 Merkle tree，并将根提交到链上。为方便用户获取原始 tree，它会发布在 IPFS 和 GitHub 上。每棵新树都会累积 CSM Node Operators 曾经获得的所有 Node Operator 奖励，因此无需分别保存多棵旧树，只需最新的一棵即可确定奖励分配。可领取的奖励金额计算方式为 $totalAcquiredRewards - claimedRewards$。

Performance Oracle 使用相对于 inclusion delay 的成功 attestation rate 作为 validator 整体表现的代理指标。系统通过一个 performance threshold 来决定实际 Node Operator 奖励的分配：表现高于阈值的 validators 会被纳入分配池，其余则不会。Activation 和 exit 事件会在 Node Operator 的份额计算中被考虑。分配池形成后，每个 validator 获得的 staking rewards 部分为 $totalStakingRewardsAccumulated / totalValidatorsInDistributionPool$。这实际上意味着模块获得的所有奖励都会在表现良好的 validators 之间进行分配。随后，validator 份额会被归集到相应的 Node Operators 名下，每个 Operator 可以一次性领取其名下所有 validator 的奖励。

需要特别注意的是，Performance Oracle 只管理全部奖励中的一部分。即使某个 validator 在一个 frame 内表现低于阈值，bond 奖励（rebase）仍然会被计入。奖励计算示例可在此处查看。需要注意，即使 validator 表现低于阈值，其单验证者奖励仍会高于 solo staking 的水平。

建议将 Performance Oracle 的 frame 设置为 28 天。这样 frame 足够长，可以覆盖短期性能中断（如果 frame 较短，这种容错效果会减弱，performance threshold 的参考意义也会降低）；而如果将 frame 设置得超过 28 天，则会导致奖励分配的额外延迟。

Performance threshold 应当相对于整体网络 attestation effectiveness 来设定，以确保 Node Operator 无法控制的网络问题不会影响奖励分配。

如果你想进一步了解 Performance Oracle 的具体算法，可参阅这篇详细文档。

👮‍♂️ 第 3 步：惩罚

立即惩罚与延迟惩罚

系统引入了以下两类惩罚方案：

1. 立即惩罚（适用于无歧义、可通过无需信任的证明直接判定的惩罚）；
2. 带 challenge period 的延迟惩罚（适用于可能出现误报或需要进一步调查的情况）；

延迟惩罚的 challenge period 是通过分离两个参与惩罚执行的 roles 来实现的。

第一个角色是“reporter”。该角色成员可以率先报告某个应触发惩罚的事实。在此阶段，bond 资金会被锁定，但不会被销毁或没收。“Reporter”也可以在 challenge 结果有利于 Node Operator 时撤销最初的报告。

第二个角色称为“settler”。该角色成员可以最终确定（结算）先前报告的惩罚。

将这两个角色分开，可以确保只有在两个独立参与方都认可的情况下，惩罚才会生效。

惩罚原因

CSM Node Operator 的 bond 可能因以下三个主要原因受到惩罚：

1. Validator 被 slashed。在这种情况下，会没收其初始（最小）slashing penalty，惩罚金额为 $1$ ETH（$\text{EFFECTIVE_BALANCE} / 32$）；
2. Operator 窃取了 EL rewards（MEV）。惩罚金额为 $\text{窃取金额} + \text{固定窃取罚金}$（可应用于该 Node Operator 的多个 validators）；
3. Validator 的提款余额低于 DEPOSIT_AMOUNT（32 ETH）。惩罚金额为 $32 - \text{validator 的提款余额}$；

第一种惩罚通过 EIP-4788 以无需许可的方式提交报告，用于证明 slashing 事实，并在报告交易中立即执行。

第二种惩罚采用带 challenge period 的延迟惩罚形式。一个专门的委员会（reporter）负责检测 MEV stealing 并在链上报告，从而锁定 bond 资金。随后通过 EasyTrack motion（settler）完成结算，以确保 DAO 与检测委员会之间的对齐。一旦惩罚被结算（确认），该 Node Operator 的所有权益都会因违反协议规则而被重置。如果惩罚在 retention_period 内未得到结算，被锁定的 bond 将自动解锁。

第三种惩罚使用 validator 的提款余额进行计算（具体报告方式见下文）。该惩罚会在报告交易中立即执行。如果已经执行过第一种初始 slashing penalty，则会将其计入，以避免双重处罚。

惩罚机制

与 Node Operator bond 惩罚相关的机制有两种。

第一种是使用 Burner 销毁 stETH shares。被没收的 shares 销毁后，stETH shares 的总量会减少，从而使 shareRate 上升，这实际上是将被销毁的 stETH 价值分配给了其他 stETH holders。

第二种机制是将被没收的 stETH 转入 Lido DAO Treasury。该方式适用于用于弥补协议运营成本的惩罚（例如 keyRemovalCharge）。

上一节所述的所有惩罚原因中，被罚资金都会以销毁方式处理。目前唯一转入 Treasury 的惩罚是 keyRemovalCharge。

Bond 不足

如果在惩罚执行后，Node Operator 的 bond 低于覆盖其名下 validators 所需的最低金额，则其全部新奖励将用于补充 bond，直到恢复到所需水平。Node Operators 也可以自行“补充”bond（提交所需差额），以便能够重新领取奖励。

如果惩罚金额超过 Node Operator 当前可用的 bond 总额，则所有可用资金都会被销毁。

权益重置

与默认曲线不同的 bond curve 可被视为 Node Operator 享有的一项权益。因此，在出现不当表现或违反规则的情况下，确保这些权益被重置至关重要。在 CSM 中，Node Operator 的权益会在以下 4 种情况下被重置：

• EL rewards stealing 已被检测并确认；
• NO 名下某个 validator 被报告 slashed；
• NO 名下某个 validator 因 CL 余额不足而被逐出；
• 根据 DAO 的决定执行重置；

如果 Node Operator 自愿退出名下所有 validators 并领回全部 bond，则不会触发权益重置，因为 Node Operator 不存在恶意或违规行为。

关于该主题的详细研究见单独文档。

👋 第 4 步：Validator 退出

退出流程概览

自愿退出

鉴于 CSM 的无需许可特性，Node Operators 可以随时自愿退出其名下 validators。

协议发起的退出

为了与核心协议及其他 staking modules 保持一致，CSM 使用 VEBO 来请求或触发 validator 退出。

从核心协议方面来看，为了满足 stETH holders 的提款请求，或依据 DAO 的决定，可以请求 validator 退出。

从 CSM 方面来看，可以为 unbonded validators 请求退出。这类退出请求会通过 forcedTargetLimit 自动发起。

forcedTargetLimit 目前正在 SR v1.5 中开发。简言之，它类似于现有的 targetLimit，但超出 forcedTargetLimit 的 validators 可以立即被请求退出，甚至无需先满足 stETH holders 的提款请求。

Node Operators 应关注 VEBO 事件（例如通过使用 Ejector 来跟进），以确保及时退出 validators。如果 Node Operator 在协议请求后拒绝退出 validators，则应适用以下惩罚和限制措施：

1. 将该 NO 的 keys 从队列中排除，直到 $stuckKeysCount = 0$ 时才重新放回；
2. 如果在 Performance Oracle 报告期间该 Node Operator 的 $stuckKeysCount$ 大于 $0$，则不向其分配 staking rewards；

此外，在特殊情况下，Lido DAO 也可以触发对 Node Operator validators 的退出。

长期低绩效

如果某个 validator 在 6 个 frames 内有 3 个 frames 的表现低于 performance threshold，则会被视为违反协议良好表现规则的差表现者。对于累计 3 次“strikes”（即低绩效 frames）的 validators，可以通过无需许可的方法将其逐出协议。另外，还可以考虑从 Node Operator 的 bond 中没收此类 validators 因低绩效而错失的利润，不过这一选项仍在讨论中。

更多关于驱逐差表现者的信息，请参阅单独文档。

提款余额报告

释放 bond 并计算退出惩罚（如有）需要用到 validator 的提款余额。该余额由 CSM bot 或 Node Operator 自己通过 EIP-4788 以无需许可的方式提交报告。

🫡 结语

如果你有任何疑问，或认为本文有遗漏之处，欢迎在下方留言。

附录 1：Emergency brakes

为保障协议安全，建议引入以下 emergency brakes：

• 禁用来自 staking router 的 deposits；
• 禁用 NO 创建；
• 禁用 deposit data 上传；
• 禁用 rewards distribution roots 提交；
• 禁用 rewards claim；

上述部分方法可以交给一个专用多签（multisig）来执行，以便在 CSM 早期阶段快速响应。

附录 2：方法-角色映射

* 在模块运行满 1 年后过期

** 多签

附录 3：Early Adoption 阶段

对于条件富有吸引力的 Node Operators 来说，无需许可进入面临的一个挑战是，可能会出现某个大型参与者占据 staking module 中所有席位的情况。为了应对这一挑战，CSM 主网生命周期的第一阶段被设计为 Early Adoption 阶段。该阶段计划使用 Merkle proof 作为进入 CSM 主网的入场凭证。除了获得加入资格外，这些 Node Operators 还将享有“首个 validator bond 折扣”。这样可以确保在 Early Adoption 阶段，经过验证的 solo-stakers（来自 Rated 的名单并由 Lido DAO 评估）能够以小幅优惠加入。

更多关于 Early Adoption 阶段机制的说明，请参阅详细文档。

附录 4：相关文档

• 简单 bond ADR
• 一个性能阈值还是多个？
• CSM 早期采用
• CSM Node Operator 权益的重置条件
• 驱逐差表现者
• 一种处理 unbonded validators 的新方法
• CSM optimistic vetting 队列
• CSM 集成的一种可能方案

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