🏛️ 社区质押模块架构

2 年前更新 2 年前更新

🏛️ 社区质押模块架构

本文档描述了社区质押模块（CSM）的架构。该模块实现了 Community Staking Landscape 中提出的构想。本文的主要目的是详细介绍 CSM 的架构以及关键的设计决策。

术语 validator、key、validator key 和 deposit data 在本文中含义相同。

∑ 概览

CSM 是一个无需许可的质押模块，旨在吸引社区质押者作为节点运营者（Node Operator）参与 Lido on Ethereum 协议。加入 CSM 成为 Node Operator 的唯一要求是能够运行验证者并提供一笔 bond（保证金）。在密钥有效的前提下，质押份额会按照密钥提供的顺序依次分配。Bond 并不直接与验证者的实际质押相关联，而是作为一种安全抵押品。Bond 是 Node Operator 自身的属性，因此它是该 Node Operator 名下所有验证者的共同抵押品。这也使得 bond 金额可以逐步降低：Node Operator 拥有的验证者越多，单个验证者对应的 bond 就越少。Node Operator 的收益来自 bond 的 rebase（质押重基）以及质押奖励中归属于 Node Operator 的部分。当验证者的表现超过阈值时，Node Operator 的质押奖励部分会被社会化（平均化）。如果验证者因累计共识层（CL）惩罚导致余额低于存款金额，或发生了执行层（EL）奖励被窃取的情况，相应损失将从 Node Operator 的 bond 中扣除。Node Operator 应按照协议要求退出验证者，也可以选择自愿退出。

📓 术语表

• Staking router（SR）是 Lido on Ethereum 协议中的一个智能合约，负责在不同模块之间分配质押资产并分发奖励。

• Staking module（SM）是连接到 staking router 的一个智能合约或一组智能合约，负责：

  • 维护底层的运营者和验证者集合；
  • 处理运营者的加入与退出；
  • 管理验证者的存款、提款和退出；
  • 维护模块及其参与者的费用结构与分配。

• Bond 是 Node Operator 为应对自身不良行为或不佳表现而提供的 ETH 或 stETH 抵押品。

• Lido DAO 是一个去中心化自治组织，通过治理代币（LDO）的投票权来决定受其控制的流动性质押协议的关键参数。

• Node Operator（NO）是指运行验证者的个人或实体。

• Lido 是 Lido on Ethereum 协议的核心合约，负责存储协议状态、接受用户提交，并包含 stETH 代币。

• stETH 是一种由 Lido 铸造的 ERC-20 代币，代表 totalPooledEther 的份额。

• Deposit data 是指提交给 DepositContract 的验证者公钥及存款签名所组成的结构。在本文中也称为 keys。验证者的私钥完全由 Node Operator 自己创建、存储和管理。

• DepositContract 是官方的验证者存款合约。

• DepositSecurityModule 或简称 DSM，是一组智能合约和链下组件，用于缓解相关漏洞。

• 当某个验证者对应的当前 Node Operator bond 不足以覆盖其风险时，该验证者被视为 “unbonded”（未受保证金覆盖）。

• 当验证者在收到协议退出信号后未能及时退出时，该验证者被视为 “stuck”（卡住）。

• Curated module 是第一个 Lido 质押模块，此前称为 Node Operators Registry。

• EasyTrack 是一套智能合约和一种基于否决权的替代投票模型，用于简化常规的 DAO 操作。

• AccountingOracle 是一个合约，负责收集由链下预言机提交的关于 Lido 参与验证者及其余额状态的信息、协议金库（即提款金库和执行层奖励金库）中积累的资金数量、已退出和 stuck 验证者的数量、协议能够处理的提款请求数量等信息，并负责分发节点运营者奖励。

🌎 概述

CSM 是一个提供带 bond 的无需许可准入机制的质押模块。该模块旨在为独立的社区质押者（如独立质押者或家庭质押者）提供一条清晰便捷的路径，使其能够加入 Lido on Ethereum（LoE）协议的 Node Operator 集合。Bond 要求是一项至关重要的安全与一致性保障工具，它使得无需许可的准入机制在不会损害底层质押协议（LoE）的安全性、可靠性的前提下成为可能。

🤓 模块特性

所有质押模块都必须遵循相同的 IStakingModule 接口。这必然导致各模块之间存在大量通用或相似的组件与逻辑，CSM 也不例外。例如，其密钥存储组件就基于现有的 Curated module。不过，以下几个方面有所不同，值得单独说明。

Exited 与 Withdrawn

Curated module 将验证者的“exited”（已退出）状态（包括 Slashed and Exited 和 Unslashed and Exited）视为记账流程中最后一个具有实际意义的状态，因为在此状态之后，验证者不再需要承担信标链（Beacon chain）上的任何职责（少数延迟参与同步委员会的情况除外）。而 CSM 则需要了解每个验证者确切提款余额，以决定是否进行 bond 惩罚。因此，该模块仅使用会计预言机（Accounting Oracle）报告的“exited”计数器来向 staking router 返回正确的“active”（活跃）密钥数量，并实现了无需许可的报告方法：一旦验证者进入 Withdrawable 状态（实际报告在验证者完成提款后触发），即可报告其提款余额。

质押分配队列

Node Operator 必须提供 bond 才能向 CSM 上传新的验证者密钥。合理的做法是按照与 bond 提交顺序类似的顺序来分配质押。为此，CSM 采用了 FIFO（先进先出）质押分配队列。当 Staking Router 请求密钥进行存款时，将从队列中取出接下来的 X 个密钥，并保持其 bond 提交顺序。

针对 “stuck” 密钥的替代措施

Node Operator 存在 “stuck” 密钥，这通常意味着其违反了 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 属性，用于跟踪尚未入队的密钥数量。

🔄 CSM 验证者生命周期

描述 CSM 架构的最佳方式是跟随验证者的完整生命周期进行讲解。

🚪 步骤 1. 加入 CSM

加入 CSM 流程

创建 Node Operator

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

Deposit data 准备与上传

CSM 接受与 Curated module 相同格式的 deposit data（validator pubkey + deposit signature），主要区别在于：必须在提交 deposit data 之前或同时提交 bond。

deposit signature 必须签署 (deposit_message, domain) 的根。其中 domain 用于标识链，而 deposit_message 由以下元组构成：

• validator pubkey；
• 带有实际 Lido Withdrawal Vault contract 地址的 withdrawal_credentials；
• 32 ETH 的金额。

Bond

在下文中，术语 “bond” 具有以下含义：

Bond — 一种安全抵押品，Node Operator 必须在将验证者密钥上传至 CSM 之前提交。该抵押品用于弥补因 Node Operator 自身不当行为可能造成的损失。一旦验证者从信标链退出且所有已发生损失得到弥补，该抵押品即可被取回或用于上传新的验证者密钥。

Bond 是 Node Operator 的属性，而非验证者的属性。Bond 以 stETH 形式存储。Node Operator 可以用 ETH、stETH 和 wstETH 来支付 bond。提交的 ETH 会被质押，wstETH 会在提交过程中被解包，以确保 stETH 成为 bond 的唯一存储形式。

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

为方便读者理解，上图也可以从“单个验证者所需 bond”的角度重新绘制，而不是只看验证者总数。

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

现有的 Node Operator 也可以在不额外上传 deposit data 的情况下补充 bond，以便弥补惩罚造成的缺口，或预先存入 bond 资金以备后续使用。

Unbonded 验证者

引入术语 “unbonded” 来表示那些其对应 bond 未能完全覆盖风险的验证者。考虑到 bond 是面向 Node Operator 名下所有验证者的共同抵押品，unbonded 验证者可以通过下图所示方式来确定。在下面的示例中，验证者 N+1 处于 unbonded 状态。

负 stETH rebase 的潜在后果

由于 bond 以 stETH 形式存储，存在因负 stETH rebase 导致 bond 金额减少的风险。这可能会导致一些 Node Operator 无法领取奖励（因为实际 bond 金额低于要求），甚至使验证者变为 unbonded 状态。该问题在 Bond Mechanics in Lido ADR 中有详细描述。就本文而言，需要指出的是，由于负 stETH rebase 发生的概率较低，且 Lido DAO 掌握着一笔专门基金可用于覆盖相关损失，因此 CSM 不需要为此采取额外的应对措施。

Deposit data 验证与失效（又称 vetting 与 unvetting）

鉴于即将到来的 DSM v1.5 升级，CSM 将采用乐观 vetting 方式。上传的 deposit data 将被默认视为有效，除非 DSM 报告其无效。当检测到无效的 deposit data 时，DSM 会调用 decreaseOperatorVettedKeys，将 vettedKeys 指针回退到第一个无效 deposit data 之前的位置。

可存款密钥

能否使用对应的 deposit data 进行存款，取决于几个因素。这些信息反映在 Node Operator 的 depositableKeys 属性中。该属性表示从 Node Operator 密钥存储中最后一条已存入记录之后开始，按顺序提取并可供 staking router 用于存款的 deposit data 记录数量。该数量的计算方式如下：

• 未设置 targetLimit 时：vettedKeys - the number of depositedKeys - unbondedKeys。
• 已设置 targetLimit 时：min(vettedKeys,targetLimit) - the number of depositedKeys - unbondedKeys；若该 Node Operator 的 stuckKeys != 0，则该值为 0。

质押分配队列

CSM 中的质押分配队列是一个传统的 FIFO（先进先出）队列。Node Operator 以 {noId, keysCount} 批次的形式在队列中排队，等待轮到他们。

当队列处理到 Node Operator 的批次时，CSM 会根据公式 min(depositableKeys, keysInBatch) 来确定该批次中可以实际存入的密钥数量。

可能会存在这样的情况：Node Operator 的一些密钥并未进入队列，因为在队列遍历时，这些密钥当时并不满足可存款条件，因此被跳过。此时，normalizeQueue 方法允许 Node Operator 将所有当前可存入的密钥重新放回队列。

关于 CSM 中的 deposit data 存储，有几个关键指针，其中包括 totalKeys 和 vettedKeys。在乐观 vetting 方式下，只要没有无效 deposit data 的报告，这两个指针在大多数情况下应保持一致（totalKeys == vettedKeys）。因此，deposit data 可以通过以下两种方式进入队列：

• 上传 deposit data 后，如果此时 totalKeys == vettedKeys；
• 调用 normalizeQueue 方法后，处理那些在上传时未进入队列（即上传时 totalKeys != vettedKeys）或在队列遍历期间被跳过的密钥。

此外，还有一些方法可以检查队列中接下来的 X 个元素，并将其中不包含可存款密钥的元素移除。这些方法是必要的，以确保即使在极端情况下（例如队列被大量不可存款密钥严重“污染”），队列仍能正常工作。

关于该队列的详细描述，请参阅专门文档。

删除 Deposit data

只要 deposit data 尚未被用于存款，Node Operator 就可以自愿删除已上传的 deposit data。每删除一个密钥，都会从 Node Operator 的 bond 中扣除 keyRemovalCharge，以覆盖与队列处理相关的最大可能运营成本。Deposit data 可以按连续的批次进行删除（例如，删除索引 5 到 10 之间的记录）。

如果协议已经基于某条 deposit data 完成了对验证者的质押，那么 Node Operator 将无法再删除该 deposit data。此时，停止验证职责的唯一途径是在共识层（CL）上退出验证者。一旦验证者完成全部提款，Node Operator 即可取回多余的 bond。

🤑 步骤 2. 奖励

奖励概览

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

• Node Operator 奖励；
• Bond 奖励。

Node Operator 奖励来自 LoE 协议在共识层和执行层奖励中所占的份额。这些奖励按一个完整 32 ETH 验证者奖励的百分比来计算。Node Operator 奖励按照与其他质押模块相同的方式进行分配（基于每个模块的活跃验证者数量按比例分配，其中 active == deposited - exited）。每个 Accounting Oracle 报告都会将一部分新增的质押奖励分配给 CSM。这些已分配的奖励会先存储在模块上。随后，CSM Performance Oracle 会在每个 frame 周期内，通过 Merkle 树的形式提供 CSM Node Operator 的奖励分配数据，使得新一轮奖励可供领取。

Bond 奖励（即 rebase 部分）来源于 stETH 作为一种 rebasing 代币的特性，且 bond 以 stETH 形式存储。在每次 Accounting Oracle 报告后，shareRate 都会发生变化（通常是上升）。因此，同样数量的 stETH 份额现在会对应更多的 stETH 代币。

总奖励的计算公式可概括为：totalRewards = 32 * moduleFee + bondAmount * shareRateChange。更多细节可参阅这篇补充文章。

在总奖励中，bond rebase 占据了相当重要的部分。在领取奖励前，bond 和 Node Operator 奖励会进行合并。最终可领取的奖励金额计算方式为 bond + NodeOperatorRewards - bondRequired。这种方法还能确保：在领取奖励之前，协议会优先补足任何缺失的 bond。

此外，任何超出所需金额的 bond 部分也会被视为奖励。

Performance Oracle

Performance Oracle 会创建一棵包含质押奖励分配的 Merkle 树，并将树根提交到链上。为了让用户能够获取原始树的数据，该树会发布在 IPFS 和 GitHub 上。与存储多个历史树根的方式不同，每一棵新树都包含了 CSM Node Operators 迄今积累的所有 Node Operator 奖励。因此，只需要最新的一棵树，就可以确定当前的奖励分配情况。可领取的奖励金额可以计算为 totalAcquiredRewards - claimedRewards。

Performance Oracle 将“成功证明的 attestation（证明）率（考虑包含延迟）”作为衡量验证者整体表现的代理指标。协议设定了一个表现阈值来决定实际 Node Operator 奖励的分配：表现超过该阈值的验证者会被纳入分配池，其余验证者则不会被纳入。在计算 Node Operator 的份额时，会同时考虑验证者的激活和退出事件。当分配池形成后，每个验证者将获得 totalStakingRewardsAccumulated / totalValidatorsInDistributionPool 的质押奖励份额。这实际上意味着，模块在一段时间内获得的所有奖励会在表现良好的验证者之间平分。随后，每个验证者的份额会被归集到其对应的 Node Operator 名下，每个 Operator 可以一次性领取其名下所有验证者的奖励。

有必要强调的是，Performance Oracle 只管理总奖励中的一部分。即使某个验证者在某个 frame 内表现低于阈值，其 bond 奖励（rebase）也依然会被累计。关于奖励计算的具体示例，可以参见此处的表格。需要注意的是，即使在表现低于阈值的情况下，每个验证者所获得的奖励仍会高于其单独进行质押（solo staking）时的收益。

目前建议将 Performance Oracle 的报告 frame（周期）设置为 28 天。这样一个周期长度足以覆盖短暂的表现中断（如果周期过短，这种缓冲效果会降低，表现阈值的意义也会变小）。但若将 frame 设置得超过 28 天，则会导致奖励分配出现不必要的延迟。

此外，表现阈值应设置为相对于整个网络 attestation 有效性的相对值，这样可以确保非 Node Operator 所能控制的网络问题不会对其奖励分配产生不利影响。

如果你想了解更多关于 Performance Oracle 实际算法的信息，请参考这份详细文档。

👮‍♂️ 步骤 3. 惩罚

即时惩罚与延迟惩罚

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

1. 即时惩罚（适用于那些毫无歧义、可以通过无需信任的证明直接评估的惩罚）；
2. 带有挑战期的延迟惩罚（适用于可能出现误报或需要进一步调查的情况）。

延迟惩罚的挑战期是通过将惩罚实施过程中涉及的两个角色分离开来而实现的。

第一个角色是“报告者”（reporter）。该角色的成员可以最初提交一个应触发惩罚的事实报告。在此阶段，bond 资金会被锁定，但不会被销毁或没收。“报告者”也可以在挑战结果有利于 Node Operator 的情况下，撤销其最初的报告。

第二个角色是“结算者”（settler）。该角色的成员可以最终确认（结算）之前被报告但尚未处理的惩罚。

通过分离这两种角色，可以确保一项惩罚只有在两个独立参与方都同意的情况下才能最终生效。

惩罚原因

CSM Node Operator 的 bond 可能因以下三大类原因而受到惩罚：

1. 验证者遭到了罚没（slashed）。在这种情况下，将没收其初始（最低）罚没惩罚金额。惩罚金额 = 1 ETH（即 EFFECTIVE_BALANCE / 32）；
2. Operator 窃取了执行层（EL）奖励（MEV）。惩罚金额 = 被盗金额 + 固定盗窃罚金（该惩罚可跨多个 NO 验证者适用）；
3. 验证者的提款余额低于 DEPOSIT_AMOUNT（32 ETH）。惩罚金额 = 32 - 验证者的提款余额。

第一种惩罚通过使用 EIP-4788 以无需许可的方式进行报告，用于证明验证者遭遇了罚没。该惩罚会在报告交易中立即执行。

第二种惩罚采用带有挑战期的延迟惩罚形式。一个专门的委员会（作为报告者）负责检测 MEV 窃取行为并在链上提交报告，从而锁定 bond 资金。随后通过 EasyTrack 动议进行结算（结算者），以确保 DAO 与检测委员会之间的意见一致。一旦惩罚被结算（确认），由于该行为违反了协议规则，Node Operator 的所有福利都会被重置。如果该惩罚在 retention_period（保留期）内未被结算，则被锁定的 bond 将自动解锁。

第三种惩罚是根据验证者的提款余额来计算的（具体报告流程将在下文章节描述）。该惩罚会在报告交易中立即执行。如果之前已经应用了第一种类型的初始罚没惩罚，那么在计算这一惩罚时会将其考虑在内，以避免对同一损失进行重复处罚。

机制

与 Node Operator bond 惩罚相关的机制主要有两种：

第一种机制是使用 Burner 合约销毁 stETH 份额。一旦被没收的份额被销毁，stETH 份额的总供应量就会减少。因此，shareRate 会随之上升，这实际上是将所有被销毁的 stETH 价值重新分配给了其他 stETH 持有者。

第二种机制是将被没收的 stETH 转移到 Lido DAO Treasury（DAO 金库）。这种方法适用于那些用于支付协议运营成本的罚金（例如，keyRemovalCharge）。

对于上一节中描述的所有惩罚原因，被罚没的资金都会被销毁。目前，唯一会转移到 DAO 金库的罚金是 keyRemovalCharge。

Bond 短缺

如果在处以罚金后，Node Operator 的 bond 金额低于覆盖其名下当前验证者所需的最低要求，那么该 Node Operator 未来获得的所有新奖励都将被自动用于补充其 bond，直到恢复到所需水平。Node Operator 也可以选择自行“补充” bond（提交所缺少的差额），以便能够再次开始领取奖励。

如果罚金金额超过了 Node Operator 可用 bond 的总量，那么其所有可用的 bond 资金都将被销毁。

福利重置

使用不同于默认曲线的 bond 曲线，可以被视为给予 Node Operator 的一种福利。因此，确保在该 Node Operator 表现不佳或违反规则时能够重置这些福利，就显得至关重要。在 CSM 中，存在以下 4 种会触发 Node Operator 福利重置的情况：

• 检测到并确认了执行层（EL）奖励窃取行为；
• NO 名下的某个验证者被报告发生了罚没；
• NO 名下的某个验证者因共识层（CL）余额不足而被协议驱逐（ejected）；
• 基于 Lido DAO 的决策。

不过，如果 Node Operator 是自愿退出其名下所有验证者并取回全部 bond，则其福利不会被重置，因为该 Node Operator 并未实施任何恶意或违规行为。

关于这一主题的详细研究，可参阅这份单独文档。

👋 步骤 4. 验证者退出

退出流程概览

自愿退出

鉴于 CSM 的无需许可特性，NO 可以随时自愿退出其名下验证者。

协议发起的退出

为了与核心协议及其他质押模块的机制保持一致，CSM 使用 VEBO 来请求或触发验证者的退出操作。

从核心协议层面来看，验证者的退出可能是为了满足 stETH 持有者的提款请求，也可能是根据 DAO 的决策而发起的。

从 CSM 模块自身角度来看，可以为 unbonded 的验证者请求退出。这类退出请求是通过 forcedTargetLimit 机制自动发出的。

forcedTargetLimit 目前正在 SR v1.5 中开发。简而言之，它与现有的 targetLimit 类似，但对超出该限制的验证者可以立即请求其退出，即使此时并不需要满足 stETH 持有者的提款请求。

Node Operator 需要持续关注 VEBO 事件（例如，通过使用 Ejector工具），以确保自己能够在协议要求的时间内及时退出验证者。如果 Node Operator 在收到协议退出请求后拒绝执行退出，则将对其应用以下惩罚和限制措施：

1. 将该 NO 的密钥从队列中移除，并且在 stuckKeysCount = 0 之前不得重新加入队列；
2. 如果在 Performance Oracle 的某个报告周期内，该 Node Operator 的 stuckKeysCount 曾大于 0，则在该周期内不向其分配质押奖励。

此外，在特殊情况下，Lido DAO 也可以直接触发对 Node Operator 名下验证者的退出操作。

长期表现不佳

如果某个验证者在连续的 6 个 frame 周期内，有 3 个 frame 的表现低于 Performance 阈值，则该验证者被视为“差表现者”，违反了协议中关于良好表现的规定。带有 3 次“strikes”（即表现不佳的 frame）的验证者，可以通过一种无需许可的方法被协议强制驱逐。此外，还有一种选择是从该 Node Operator 的 bond 中没收此类验证者所错过的利润。不过，这一选项目前仍在考虑之中。

如需了解更多关于驱逐差表现者的信息，请参考单独文档。

提款余额报告

验证者的提款余额信息，是用于释放 bond 以及计算任何退出惩罚（如果适用）的关键数据。该余额数据由 CSM 机器人或 Node Operator 本人使用 EIP-4788 以无需许可的方式进行报告。

🫡 结语

如果你对本文档有任何疑问，或认为内容有所遗漏，欢迎留下你的评论。

附录 1. 紧急制动

为确保协议的安全性，提案引入了以下紧急制动开关：

• 停用来自 staking router 的存款功能；
• 停用 NO 创建功能；
• 停用 deposit data 上传功能；
• 停用奖励分配根提交功能；
• 停用奖励领取功能。

上述部分方法可能会被分配给一个专门的多签钱包，以便在 CSM 早期的发展阶段能够快速响应和处理紧急情况。

附录 2. 方法-角色映射

* 在模块运行 1 年后过期
** 多签钱包

附录 3. 早期采用期

以有吸引力的条件实现 Node Operator 无需许可准入的一个潜在风险是：一个大型参与者可能会占据模块中的全部名额。为应对这一问题，提案将“早期采用期”作为 CSM 主网上线生命周期的第一阶段。在该阶段，提案建议使用 Merkle 证明作为进入 CSM 主网的准入凭证。除了拥有加入资格之外，这类 Node Operator 还将获得“首个验证者的 bond 折扣”优惠。这将确保在早期采用期内，那些经过验证的独立质押者（来自 Rated 的名单，并经过 Lido DAO 评估）能够以一定的优惠条件加入进来。

有关早期采用期机制的更多信息，请参阅此详细文档。

附录 4. 相关文档

• Simple bond ADR
• One performance threshold or more?
• CSM Early Adoption
• Reset conditions for the CSM Node Operators' benefits
• Ejecting bad performers
• A new approach to unbonded validators
• CSM optimistic vetting queue
• A possible approach to CSM integrations

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