Lido SR、模块与NO类型

注意：本文档仍远未完成（WIP）

## Motivation

Lido 协议（在不同层级，从 Staking Router 到 Modules，再到 Node Operators（或 Clusters）本身）能够区分不同类型的 Node Operators（NOs）（即与形态、规模、属性相关的分类），这是一个普遍存在的需求。能够区分不同类型的 NOs，将使协议能够根据特定要求或标准，对不同类型的 NOs 采取不同的处理方式。

这一能力可以立即应用于以下场景：让拥有 stake 的 Operators（例如拥有声誉证明（Proof of Reputation）、抵押品（Collateral）等）与风险敞口较小、或难以辨别是否为 Sybil 的 permissionless operators 具有不同的风险画像。基于这些不同的风险画像，modules 可以基于这样的思路来定制其功能：NOs 先有一个"默认"类型，然后通过某种机制被"分类"，从而被允许以不同的方式与模块交互，或根据其特性与表现获得不同的待遇（perks）或惩罚（penalties）。例如，模块可以借此明确区分（可能的）Independent Operators 与 Unknown 或 Professionals，从而让一个模块服务所有这些类别的 NOs，而不必针对不同的 NO 类型分别创建和部署不同的模块。

## Classification Mechanism

总的来说，（最终）应该有一种统一的方式，让 Staking Router 和 Modules 理解 NO 类型。这可以通过一个"全局"NO 注册表来实现，但目前还没有这样的机制。在此之前，Modules 可以在"本地"推断 NO 类型。由于 CSMv2 目前正在开发中，我们可以考虑改进 CSMv1 中已有的机制来实现这一 NO 识别过程，并将其作为一种技术机制，让其他模块也能从中受益。

在 CSM v1 中，存在一种粗略的机制来区分两类 Node Operators：符合 Early Adoption 条件的 Operator（基本上可以视作可能的 Independent Operators 与 CSM 测试网用户的代理指标），以及其他所有人。在技术层面，这一机制是通过 CSM 中的 bonding curve 功能（即为 EAers 创建第二条 bonding curve）与 EarlyAdopters 机制结合实现的。在 CSM v2 中，这种通用机制可以进一步抽象，以实现不同类型之间非常丰富的差异化，并让 CSM v2 成长为一个具有极强扩展潜力的 permissionless 模块——对模块核心只需做最小改动，剩下只需在边缘层面调整针对 NO 类型的配置。在 CSM 代码中，可以使用 NO 的 `bondCurveId` 作为代理指标（proxy）来推断 `NOType`。在 CSMv2 中，我们可以延续这一做法，但将一套抽象的 perks 和安全机制附加到该 `bondCurveId`（即 `NOType`）上。

在 CSMv2 中，计划引入 "Entry Gate"（入口门禁）的概念。本质上，create/add node operator 方法将不再是 permissionless 的，而是变成可分配给一组白名单 "Gates" 的 permissioned 方法。可以把这些 Gates 想象成夜店门口的保安：在放参加派对的人（这里指 NOs）进场之前，他们会先检查一些条件。Gates 是智能合约，但通过 Gate 实现的 NOs"识别"与"验证"机制并不一定需要是链上代码（例如，Gate 可以是一个处理来自 oracle 信息的合约，也可以是一个由背后人员审核申请及相关数据的 multisig，还可以是某种针对各类证明类型的 (ZK) 证明验证机制，等等）。由于 Gates 是模块核心"外部"的机制，未来其他模块甚至其他协议也可以复用同样的机制。将向模块注册表添加新 Node Operators 的权限分配给某个 Gate 后，模块还可以定义该 Gate 可以创建哪些 NO 类型。

CSMv2 作为一个 permissionless 模块，在部署时至少会有一个 Gate，其工作方式与当前 CSM 相同，即通过该 Gate 调用 create node operator 方法是 permissionless 的。因此，以这种方式创建的 Node Operators 应当使模块实现"最大鲁棒性"（即对其采取所有 Operator 类型中最严格的安全与风险评估处理）。因此，"默认"的 CSMv2 gate 只能创建"默认"类型的 NO，模块机制会根据这种 NO 类型的特征（完全 permissionless、没有 Sybil 抵抗能力）进行定制。此外，还可以有一个（或一组）Gate 添加到 CSMv2（甚至可以在部署时就加入），充当（可能的）Independent Operators 的验证机制（例如，某种形式的 proof of humanity 加上过往 solo staker 参与记录的组合，或者像允许从事 solo staker 识别的团体进行背书的 Gates（ [https://www.stakersunion.com/](https://www.stakersunion.com/)））。

## NO-type-based module paramaterization

类型识别不一定局限于判断 Operator 是 Independent Operators 还是专业组织。它还可以涵盖 Node Operator 的其他方面/特征，例如该 NO 是否是一个 Cluster（一组运行 DVs 的参与者组成的群体）（因为某些模块只能看到注册表里的 "node operator"，而这个条目可能是一个 cluster），或者该 NO 是否是 DVT cluster 中可识别（或不可识别）的参与者。

例如，如果 Gate 能够审查/验证 DV Cluster 中的所有参与者都经过识别且相互独立，那么模块就可以将这种类型的 cluster 与包含 permissionless 元素、且无法验证参与者之间独立性的 cluster 区别对待。

以下是一个粗略的 NO 特征列表，可用于为不同模块定义 NO 类型：

| 特征 | 描述 | 取值 |
| --- | --- | --- |
| 分类 (Classification) | Node Operator 的通用"类型"（例如，他们是专业企业还是业余爱好者，是一群人或实体共同运行验证者，还是由某个服务（如 VaaS）而非个人或商业实体作为 NO 的基础，等等） | … |
| 基础设施 (Infrastructure) | Node Operator 的基础设施如何运行（是自己运行？还是由他人代为运行（部分）？在何处运行？等等） | … |
| 规模 (Size) | Node Operator 的（整体）规模有多大，以及我们预计该 NO 在模块中的规模会有多大 | … |
| 位置 (Location) | NO 位于何处 | … |
| 司法辖区 (Jurisdiction) | 是否存在与 node operator 相关的监管约束 | … |
| 身份 (Identity) | Operator 的身份是否为已知（如果是，可在多大程度上得到验证，等等） | … |
| 一致性 & 生态系统影响 (Alignment & Ecosystem Impact) | 通过定性评估与可能的量化指标相结合，还可以评估 NO 在社区及更广泛网络中的存在与活动所带来的更广泛影响。他们是否开发公共物品？他们是否是守护者（stewards）？他们是否支持网络的可信中立性（credible neutrality）？他们的商业实践是否公平、透明，是否符合社区和更广泛网络的价值观？ | … |

### Possible NO Types

因此，通过上述特征的各种组合，可以定义出以下可能的 NO 类型（例如用于 CSMv2）（注意：这个列表绝非详尽无遗！）。

| 类型 | 描述 |
| --- | --- |
| 默认 (Default) | 不可识别、可被 Sybil 攻击、permissionless |
| 独立运营者 (Independent Operators) | 可能的独立运营者（通过某种验证/审查/核验机制） |
| 专业 (Pro) | 经识别的专业 node operators |
| 专业（不受欢迎）(Pro (undesirable)) | 经识别、但一致性与生态系统影响评分极低的专业 node operator |
| 验证者即服务 (Validator as a Service) | 由另一个协议或 Pro NO 的 VaaS 产品提供底层支持的 Node Operators |
| DVT Cluster（permissionless） | 由未经识别的参与者共同运行验证者的 Cluster |
| DVT Cluster（抗 Sybil） | 由经识别且相互独立的参与者共同运行验证者的 Cluster |
| DVT Cluster（单一运营者，高弹性） | 使用 DVT 以高弹性（例如多地点部署）方式运行基础设施的单一 node operator |
| 公共物品运营者 (Public-good operator) | 同时（或主要）为网络提供公共物品的运营者 |
| <你的想法在这里！> | … |

### Possible Module Parameters to Parameterize based on NO Type

这里只是一些初步想法。有些在 CSMv2 中很容易实现，有些则工作量较大，可能更适合在另一个模块或 CSMv3 中使用，或者根本不会被采用。在更复杂、更健壮的机制用例明确之前，以简化方式（例如使用 strikes 系统而不是 safety matrix）实现其中一些参数是有意义的。

每个模块都应为默认情况定义这些参数，模块支持的任何其他 NO 类型都可以对这些参数进行覆盖。模块之间可以共享参数定义，但并非必须。

| 参数 | 类型 | 描述 |
| --- | --- | --- |
| NO 奖励分成 (NO Rew. Share) | 待遇 (Perk) | 归 Node Operator 所有的质押奖励份额（与其运行的验证者数量相关） |
| 验证者数量 (Num validators) | 待遇 (Perk) | NO 可以运行的验证者数量（每个 NO 条目） |
| 存款优先级 (Deposit Priority) | 待遇 (Perk) | 用于确定存款队列排序顺序的优先级值 |
| 退出优先级 (Exit priority) | 待遇 (Perk) | 用于确定退出请求排序顺序的优先级值 |
| 次级队列 (Secondary queue) | 待遇 (Perk) | NO 是否有资格进入次级存款队列 |
| 次级队列限制 (Secondary queue limit) | 待遇 (Perk) | NO 可以通过次级存款队列提交的验证者总数 |
| Bond curve | 待遇 (Perk) | NO 可以使用哪条 bond curve |
| 密钥移除费用 (Key Removal charge) | 安全机制 (Safety Mechanism) | 从活跃队列中移除密钥时收取的费用值 |
| 区块窃取费用 (Block Stealing charge) | 安全机制 (Safety Mechanism) | 针对区块窃取（即 Fee Recipient 配置错误）收取的费用值 |
| 安全矩阵 (Safety matrix) | 安全机制 (Safety Mechanism) | 该 NO 类型需要适用的安全矩阵 |

#### The Safety Matrix

TODO：纳入第一性原理

#### Example of a safety matrix (points)

思路是：每个 NO 类型都可以被分配到一个不同的矩阵，不同的安全操作（例如驱逐验证者或运营者）需要不同的积分阈值。

例如，对于 `NOType == default`：

| 参数 | 类型 | 描述 | 积分 |
| --- | --- | --- | --- |
| PointsLifetime | Int | 违规积分的"有效"时长（以 frame 为单位）（例如，如果该值为 `3`，则只计算当前及前两个 frame 内产生的积分）。 | N/A |
| SubparPerfThreshold | Int | Performance Oracle 的性能评级阈值，低于该阈值时验证者被视为表现不佳（per validator, per frame） | 40 |
| InactivePerfThreshold | Int | Performance Oracle 的性能评级阈值，低于该阈值时验证者被视为不活跃（per validator, per frame） | 60 |
| ValEjectionThreshold | Int | 验证者因表现不佳而被驱逐的积分阈值 | 70 |
| MinValsFullExit | Int | 与 `SubParperfThreshold` 或 `InactivePerfThreshold` 相关、并触发 node operator 完全退出的受影响验证者最低数量 | 2000 |
| MinValsFullExit | Int | 与 `SubParperfThreshold` 或 `InactivePerfThreshold` 相关、并触发 node operator 完全退出的受影响验证者最低数量 | 2000 |
| UncompensatedMEVPenalty | Int | 运营者在被完全驱逐之前可以承受的 MEV 惩罚次数（终身） | 2 |
| NOEjectionThreshold | Int | 超过该积分阈值后，运营者被完全驱逐（针对 `PointsLifetime` 中的相关积分） | 10000 |

例如，基于上述配置，对于 `NOType == default`，验证者在出现 >= 2 个 frame 的表现不佳（2 \* 40 > 70）或约 2 个 frame 的不活跃（2 \* 60 > 70）后会被驱逐；而对于 `NOType == independent`，`ValEjectionThreshold` 可以有不同的阈值（例如 `ValEjectionThreshold == 110`，将允许连续 3 个 frame 的表现不佳）。

#### Example of a safety matrix based (simplified strikes)

| 参数 | 类型 | 描述 | Strike 次数 |
| --- | --- | --- | --- |
| StrikeLifetime | Int | 违规 strike 的"有效"时长（以 frame 为单位）（例如，如果该值为 `3`，则只计算前一个及当前 frame 内产生的 strike）。 | N/A |
| SubparPerfThreshold | Int | Performance Oracle 的性能评级阈值，低于该阈值时验证者被视为表现不佳（per validator, per frame） | 1 |
| InactivePerfThreshold | Int | Performance Oracle 的性能评级阈值，低于该阈值时验证者被视为不活跃（per validator, per frame） | 2 |
| ValEjectionThreshold | Int | 验证者因表现不佳而被驱逐的 strike 阈值 | 3 |

更多内容即将到来……

* * *

### Refs / stuff to incorporate later

CSM v2 [https://learnblockchain.cn/article/27233](https://learnblockchain.cn/article/27233) CSMv2 Strikes [https://hackmd.io/@lido/r1rLoBVXJg](https://learnblockchain.cn/article/27220)

Gate 相关（[https://hackmd.io/-2\_u2peQRuiumZHE\_B0vhA?both#Evolution-of-the-Early-Adoption-Mechanics](https://learnblockchain.cn/article/27232#Evolution-of-the-Early-Adoption-Mechanics)），Skh 正在编写专门的文档

当前的参数列表见 [https://github.com/lidofinance/community-staking-module/blob/develop/src/CSParametersRegistry.sol](https://github.com/lidofinance/community-staking-module/blob/develop/src/CSParametersRegistry.sol)

![image](https://img.learnblockchain.cn/2026/08/01/B1A45YDO1l.png)

>- 原文链接： [hackmd.io/@lido/H1hRQuPu...](https://hackmd.io/@lido/H1hRQuPu1l)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～