CSM罢工机制

lido__ 发布于 2025-02-11 阅读 15

本文讨论了Lido CSM（社区质押模块）中验证者违规行为的应对措施，并重点提出了针对长期表现不佳验证者的罢工系统。文章逐一分析了MEV窃取、错误MEV配置、卡住验证者、长期表现不佳、队列污染、故意错过区块提议和同步委员会、以及罚没（Slashing）等违规情况，指出除长期表现不佳外，其余违规已有或计划有充分应对措施。罢工系统由CSM性能预言机负责，每帧为表现低于阈值的验证者记录一次罢工，6个月内的罢工达到3次，任何人均可通过无权限方法触发退出并没收节点运营者债券中的固定罚金。文章还讨论了提前退出避免罚款的可能性、攻击向量（如2次罢工后退出再重新加入）及其风险接受理由。

本文档已关闭！

请评论并参考 [https://learnblockchain.cn/article/27223](https://learnblockchain.cn/article/27223)

## 前言

无需许可（permissionless）系统面临的挑战之一是确保参与者行为得当。简单来说，他们应当遵守规则。一旦违反规则，就应当有相应的应对措施。

在 CSM 中，违反规则的可能途径有以下几种：

- MEV 偷取（使用了错误的 `feeRecipient`）
- 错误的 MEV 配置（不允许的 relay，vanilla 区块 > 0.07 ETH）
- 卡住的验证者
- 长时间表现不佳（低于阈值、离线）
- CSM 队列污染
- 故意错过区块提议或同步委员会任务
- Slashing

下面我们逐一看看这些违规行为以及当前可用的应对措施。

#### MEV 偷取

现有的 CSM 版本已全面覆盖这一违规行为。CSM 委员会会检测并报告 MEV 偷取的相关事实。在协商期内，节点运营者可以补偿被偷取的资金并支付额外罚款。如果未补偿，Lido DAO 将通过 Easy Track 动议确认罚款，并从节点运营者的质押金中销毁该罚款。此后出现的任何未绑定质押金的验证者都会被 VEBO 要求退出。如果未退出，这些验证者会被标记为卡住，且在验证者退出之前，不会分配任何节点运营者奖励。在 Lido 协议层面实施 EIP-7002 后，卡住的验证者将被强制驱逐。

当前的应对措施确保：

- 为 stETH 持有者补偿被偷取的资金；
- 对实施偷取的节点运营者，要求其未绑定质押金的验证者退出（并在 EIP-7002 之后进行驱逐）；
- 如果被偷取金额超过可用质押金，则要求所有验证者退出；

鉴于此，该违规行为无需采取额外措施。

#### 错误的 MEV 配置

目前，除了通知运营者（如果他们提供了联系方式）之外，这一违规行为没有任何应对措施。

这种情况并不理想，可以通过政策更新来改进，明确节点运营者因该违规行为受到惩罚的条件。新增内容可能是：“如果重复违反 Block Proposals SNOP，则可能会报告惩罚，并且节点运营者可能被罚 0.1 ETH（额外的偷取罚款）”。该惩罚可由现有的 CSM 委员会使用与上一节相同的技术来报告。

#### 卡住的验证者

术语“stuck validator”指的是在 VEBO 发出退出请求后仍未退出的验证者。目前，如果节点运营者存在卡住的验证者，其节点运营者奖励将被取消。在 EIP-7002 之后，这些验证者可以被驱逐，并可施加相应惩罚。

这里无需额外措施。

#### 长时间表现不佳

CSM 目前不涵盖这一类型的违规行为。这里提出一个新的记过（strike）系统作为应对措施。该系统本身将在下文介绍。

#### CSM 队列污染

简而言之，这种情况是指上传多个验证者密钥然后删除它们，从而在 CSM 队列中制造无效的存款队列条目。

目前，CSM 对每个删除的密钥收取 `keyDeletionFee`，使这种攻击在经济上不可行。`keyDeletionFee` 会被转入 Lido DAO 金库，用于补偿相关的维护成本（调用 `cleanDepositQueue` 方法）。

这里无需额外措施。

#### 故意错过区块提议或同步委员会任务

无论有意无意，错过的区块提议和同步委员会目前都不由 performance oracle 统计。但是，在更新的 CSM Performance Oracle 版本中，区块提议以及参与同步委员会期间的证明（attestations）将被计入性能指标。

这里无需额外措施。

#### Slashing

Slashing 可能是 CSM 验证者能犯下的最严重违规行为。幸运的是，当前 CSM 代码已全面覆盖这一违规行为。由 slashing 造成的任何损失都会在验证者提款报告时得到补偿。

借助 EIP-7251，针对 32 ETH 验证者的初始 slashing 罚款将从 1 ETH 降至 1/128 ETH。这一降幅将体现为 CSM 运营者质押金的相应减少。从代码角度看，单独的 slashing 报告将被移除，所有由 slashing 造成的罚款都将在验证者提款报告时得到补偿（提款余额与 32 ETH 之间的差额将从节点运营者的质押金中销毁）。

这里无需额外措施。

### 总结

综上所述，唯一缺少应对措施的违规行为是“长时间表现不佳”。为此，提议引入一套记过系统，以确保对该违规行为作出充分应对。

## 记过系统目标

- 在保留性能余量的同时，保护协议免受系统性不良表现者的影响；
- 抑制系统性的不良表现；
- 不为协议增加额外的运营成本；

## 总体描述

当前版本的 CSM 尚未解决的问题之一，就是如何驱逐表现不佳的验证者。尽管这些验证者不会获得节点运营者奖励，但质押金 rebase 仍会继续，这类验证者仍会对整体 LoE 协议 APR 产生负面影响。因此，与其他无许可协议相比，对 LoE 协议发动理论攻击的成本更低。

如 [CSM Architecture](https://learnblockchain.cn/article/27206) 所附[文档](https://learnblockchain.cn/article/27209)中所述，解决该问题的最佳方式之一，是向 CSM 引入不良表现记过系统。

### 记过分配

提议由单一角色负责分配表现记过——即 CSM Performance Oracle。

每个周期中，CSM Performance Oracle 会提交一个额外的树根，其中包含验证者的“记过”信息。一次记过意味着该验证者在本周期中表现低于阈值。在更新这棵树时，CSM Performance Oracle 会参考旧树中的历史值。所有超过 6 个月的记过都会被清除。

记过树的叶子形式为 `{noID, validatorPubkey, [strikeTimestamps]}`。

将记过分配给验证者而非节点运营者的主要原因，是为了保持性能测量的一致性。目前，CSM Performance Oracle 是针对每个验证者单独评估表现的。因此，记过也应当是验证者的一项属性，以确保能够精准驱逐表现不佳的验证者。

需要特别指出的是，记过并非惩罚，而是一种不良表现指标，节点运营者应将其视为改进自身表现的信号。

### 固定不良表现罚款

在最初的提案中，使用了 [“performance tax”](https://learnblockchain.cn/article/27209#Missed-profit-confiscation) 这一术语。然而，这一数值可能难以精确计算。因此，将最初术语更名为“不良表现罚款”，并将其设定为固定值，似乎是合理的。如果验证者因记过次数足够多而被驱逐，该固定值就会从节点运营者的质押金中没收。

提议为“不良表现罚款”设定一个可配置的固定值，由 Lido DAO 在网络条件变化时负责设置/更新实际值。这种做法能让 Lido 协议及时更新“不良表现罚款”的数值。

### 因记过而驱逐

一旦记过次数达到 3 次（即 6 个月内的 3 次记过），无许可方法即可触发验证者退出，并从节点运营者的质押金中没收“不良表现罚款”。

由于在新的乐观审查（optimistic vetting）方法中，CSM 密钥存储中的节点运营者密钥索引可能会发生变化（被删除的密钥会与密钥存储中的最后一个密钥互换位置），因此需要向无许可方法提供节点运营者存储中的当前密钥索引，并检查叶子中的密钥与存储中的密钥是否一致。

```solidity
function ejectBadPerformingValidator(uint64 noId, bytes32 proof, uint256 keyIndex, bytes32 strikesData) {
	validatorKey = getNoKey(noId, keyIndex);
	checkKey(proof, validatorKey);
	assertStrikesCount(strikesData);
	checkProof(proof, strikesData);
	requestEjection(validatorKey);
	confiscateEjectionFee(noId, strikesData);
	confiscateBadPerfPenalty(noId, strikesData);
}
```

由于使用 EIP-7002 驱逐验证者会产生费用，该费用应从节点运营者的质押金中没收，并转入 Lido DAO 金库，以支付相应的运营支出。

### 在第三次记过之前退出

节点运营者可以选择在获得第三次记过之前退出其验证者，这样可以避免被没收“不良表现罚款”。

> 需要特别指出的是，所有直接损失都会被没收，而且表现不佳的周期内本来就不会分配任何质押奖励。

鉴于记过系统的目标是“在保留性能余量的同时，保护协议免受系统性不良表现者的影响”，允许表现不佳的验证者自愿退出协议是合理的，这能有效减少协议中表现不佳的验证者数量。

此外，若在验证者退出时也要考虑已分配的记过，就需要提款报告流程与 CSM Performance Oracle 直接关联，这实际上会使退出变成需要许可的操作，并高度依赖 CSM Performance Oracle 的运行。

### 可能的攻击向量

#### 在 2 次记过后退出并重新加入

这个攻击向量看起来可能对协议危害很大，因为它基本上可以让人无限期表现不佳，而协议方面却没有任何应对措施。

然而，魔鬼藏在细节中。要对协议的有效性产生显著影响，恶意行为者需要控制协议验证者的相当大比例（> 1%）。如果所有这些验证者在 2 个 Performance Oracle 周期内都表现低于阈值，他们都会被分配记过，并应在第三次报告之前自愿退出。一旦退出，他们就需要再次加入。为此，他们需要被排在 CSM 存款队列的末尾，然后被存入，以重复攻击。在现实条件下，这个过程可能需要相当长的时间，甚至可能不可行，因为队列中排在他们前面的其他验证者会先被存入。

因此，假设攻击者不是 CSM 的唯一使用者，所描述的攻击很可能会随着每一轮周期而变得越来越无效。

#### 每 6 个周期中有 2 个周期表现不佳

这种情况与其说是攻击，不如说是一种常规的不良表现场景。验证者确实可以在每 6 个周期中有 2 个周期表现低于阈值，并完全避免额外的惩罚。考虑到每 6 个周期内需要有 4 个周期表现良好，这种情况的危害性比上述情况更小。

一种可能的解决方案是让记过无限期有效。然而，这不会产生有意义的效果，因为验证者可以在 2 次记过后退出，然后如上所述重新创建。

提议接受与该攻击向量相关的风险，因为它发生的概率很低、对协议的影响很小，而且没有实施这种攻击的经济动机。归根结底，表现良好并从 CSM 资金乘数中获益，要有利可图得多。

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

本文档已关闭！

请评论并参考 https://learnblockchain.cn/article/27223

前言

无需许可（permissionless）系统面临的挑战之一是确保参与者行为得当。简单来说，他们应当遵守规则。一旦违反规则，就应当有相应的应对措施。

在 CSM 中，违反规则的可能途径有以下几种：

MEV 偷取（使用了错误的 feeRecipient）
错误的 MEV 配置（不允许的 relay，vanilla 区块 > 0.07 ETH）
卡住的验证者
长时间表现不佳（低于阈值、离线）
CSM 队列污染
故意错过区块提议或同步委员会任务
Slashing

下面我们逐一看看这些违规行为以及当前可用的应对措施。

MEV 偷取

当前的应对措施确保：

为 stETH 持有者补偿被偷取的资金；
对实施偷取的节点运营者，要求其未绑定质押金的验证者退出（并在 EIP-7002 之后进行驱逐）；
如果被偷取金额超过可用质押金，则要求所有验证者退出；

鉴于此，该违规行为无需采取额外措施。

错误的 MEV 配置

目前，除了通知运营者（如果他们提供了联系方式）之外，这一违规行为没有任何应对措施。

卡住的验证者

这里无需额外措施。

长时间表现不佳

CSM 目前不涵盖这一类型的违规行为。这里提出一个新的记过（strike）系统作为应对措施。该系统本身将在下文介绍。

CSM 队列污染

简而言之，这种情况是指上传多个验证者密钥然后删除它们，从而在 CSM 队列中制造无效的存款队列条目。

目前，CSM 对每个删除的密钥收取 keyDeletionFee，使这种攻击在经济上不可行。keyDeletionFee 会被转入 Lido DAO 金库，用于补偿相关的维护成本（调用 cleanDepositQueue 方法）。

这里无需额外措施。

故意错过区块提议或同步委员会任务

这里无需额外措施。

Slashing

这里无需额外措施。

总结

综上所述，唯一缺少应对措施的违规行为是“长时间表现不佳”。为此，提议引入一套记过系统，以确保对该违规行为作出充分应对。

记过系统目标

在保留性能余量的同时，保护协议免受系统性不良表现者的影响；
抑制系统性的不良表现；
不为协议增加额外的运营成本；

总体描述

如 CSM Architecture 所附文档中所述，解决该问题的最佳方式之一，是向 CSM 引入不良表现记过系统。

记过分配

提议由单一角色负责分配表现记过——即 CSM Performance Oracle。

记过树的叶子形式为 {noID, validatorPubkey, [strikeTimestamps]}。

需要特别指出的是，记过并非惩罚，而是一种不良表现指标，节点运营者应将其视为改进自身表现的信号。

固定不良表现罚款

在最初的提案中，使用了 “performance tax” 这一术语。然而，这一数值可能难以精确计算。因此，将最初术语更名为“不良表现罚款”，并将其设定为固定值，似乎是合理的。如果验证者因记过次数足够多而被驱逐，该固定值就会从节点运营者的质押金中没收。

因记过而驱逐

一旦记过次数达到 3 次（即 6 个月内的 3 次记过），无许可方法即可触发验证者退出，并从节点运营者的质押金中没收“不良表现罚款”。

function ejectBadPerformingValidator(uint64 noId, bytes32 proof, uint256 keyIndex, bytes32 strikesData) {
	validatorKey = getNoKey(noId, keyIndex);
	checkKey(proof, validatorKey);
	assertStrikesCount(strikesData);
	checkProof(proof, strikesData);
	requestEjection(validatorKey);
	confiscateEjectionFee(noId, strikesData);
	confiscateBadPerfPenalty(noId, strikesData);
}

由于使用 EIP-7002 驱逐验证者会产生费用，该费用应从节点运营者的质押金中没收，并转入 Lido DAO 金库，以支付相应的运营支出。

在第三次记过之前退出

节点运营者可以选择在获得第三次记过之前退出其验证者，这样可以避免被没收“不良表现罚款”。

需要特别指出的是，所有直接损失都会被没收，而且表现不佳的周期内本来就不会分配任何质押奖励。

可能的攻击向量

在 2 次记过后退出并重新加入

这个攻击向量看起来可能对协议危害很大，因为它基本上可以让人无限期表现不佳，而协议方面却没有任何应对措施。

因此，假设攻击者不是 CSM 的唯一使用者，所描述的攻击很可能会随着每一轮周期而变得越来越无效。

每 6 个周期中有 2 个周期表现不佳

一种可能的解决方案是让记过无限期有效。然而，这不会产生有意义的效果，因为验证者可以在 2 次记过后退出，然后如上所述重新创建。

原文链接： hackmd.io/@lido/r1rLoBVX...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

0 条评论

前言

MEV 偷取

错误的 MEV 配置

卡住的验证者

长时间表现不佳

CSM 队列污染

故意错过区块提议或同步委员会任务

Slashing

总结

记过系统目标

总体描述

记过分配

固定不良表现罚款

因记过而驱逐

在第三次记过之前退出

可能的攻击向量

在 2 次记过后退出并重新加入

每 6 个周期中有 2 个周期表现不佳

相关文章

0 条评论