CSM 性能预言机指标更新

本文档已关闭！

请在 https://hackmd.io/@lido/csm-v2-internal 上评论和参考。

目前，CSM Performance Oracle 使用被包含的 attestation 比率（不考量包含延迟和正确性）作为 CSM 验证器的性能代理指标：

$$ P_{\text{validator}} = \frac{A_{\text{included}}}{A_{\text{assigned}}} $$

该指标是验证器活跃度的极佳代理指标，因为每个以太坊验证器应在每个 epoch 提交一次 attestation。然而，当前方法未将另外两项验证器职责纳入考量：区块提议和同步委员会参与。这些职责的频率远低于 attestation，但对网络至关重要。随着 CSM 不断发展，并且其在 Lido 以太坊协议中的质押份额不断增加，我们需要一个更稳健、更准确的性能代理指标。

统一性能评分

以已完成职责与已分配职责之间的关系来表示性能评分，已被证明是稳健且易于理解的。本文提议保留这一方法，同时将区块提议和同步委员会职责纳入其中。由此得到的公式如下：

$$ P_{\text{validator}} = C_a \times A_{\text{eff}} + C_b \times B_{\text{eff}} + C_s \times S_{\text{eff}} $$

其中 $C_a, C_b, C_s$ 是权重系数，$A_{\text{eff}}, B_{\text{eff}}, S_{\text{eff}}$ 分别是 attestation、区块提议和同步委员会的有效性评分。

beaconcha.in 也采用类似的方法来计算验证器效率。

权重系数

权重系数的定义如下（根据 eth2book）：

$$ C_a = 5464,\quad C_b = 864,\quad C_s = 264 $$

然而，这些系数假设的是在长时间段内验证器被分配了全部三项职责时所获得的奖励。由于 CSM Performance Oracle 的评估窗口相对较短，因此需要考虑窗口内并非所有职责都被分配的情况。

所有三项职责

$$ C_a = 5464,\quad C_b = 864,\quad C_s = 264 $$

Attestation 和区块提议

$$ C_a = 5462,\quad C_b = 862,\quad C_s = 0 $$

Attestation 和同步委员会

$$ C_a = 5456,\quad C_b = 0,\quad C_s = 256 $$

仅有 Attestation

$$ C_a = 1,\quad C_b = 0,\quad C_s = 0 $$

有效性评分

Attestation

attestation 有效性最通用的计算方式是：

$$ A_{\text{eff}} = \frac{A_{\text{actualReward}}}{A_{\text{maximalReward}}} $$

实际的 attestation 奖励通过此处描述的复杂算法计算。可以看到，实际奖励取决于多个因素，例如投票正确性和包含延迟。由于节点运营者是在家中而非顶级数据中心进行验证，这些因素并不完全受其控制。以太坊客户端的选择也可能影响 attestation 的奖励表现。

由于 CSM 主要关注在家中进行验证的运营者，因此有必要将 attestation 提交率作为 attestation 有效性指标：

$$ A_{\text{eff}} = \frac{A_{\text{included}}}{A_{\text{assigned}}} $$

这种方法容易受到一种边缘情况的影响，即在提交率很高的同时，存在很大比例的错误 attestation 投票。然而，这种情况只可能在明确的恶意意图下发生，因为目前所有以太坊客户端都是为了实现最大性能而设计的，未经特定的代码或配置修改不会出现这种行为。任何恶意情况仍然可以通过 beaconcha.in 或 rated.network 等工具检测到，并通过惩罚节点运营者、将其从验证器集合中驱逐来应对。

区块提议

对于区块提议，情况简单明了。节点运营者应维护好自身配置，确保即使从远程位置运营也能及时提交有效区块。这一要求源于区块生产是任何验证器的重要职责。与 attestation 中单个无效或延迟的投票不会干扰网络不同，区块提议是一项二元职责——区块要么被提议，要么未被提议。因此，区块提议的有效性可以计算如下：

$$ B_{\text{eff}} = \frac{B_{\text{proposed}}}{B_{\text{assigned}}} $$

同步委员会

同步委员会是验证器一项非常罕见的职责。该职责的有效性可按如下公式计算：

$$ S_{\text{eff}} = \frac{S_{\text{included}}}{S_{\text{assigned}} - B_{\text{missed}}} $$

必须从分母中减去错过的区块，这一点至关重要，因为同步委员会的投票只能被包含进已提议的区块中，而区块提议者与同步委员会参与者之间并不相关。

平均网络性能

利用单个验证器性能公式，网络平均性能可以计算为所有单个验证器性能的平均值：

$$ P_{\text{network}} = \frac{\sum_{i=0}^{N_{\text{validators}}} P_{\text{validator}i}}{N{\text{validators}}} $$

然而，为每个验证器逐一计算性能可能消耗大量资源。此外，还需要考虑活跃验证器数量的变化。为简化计算，可以使用一个近似的替代公式：

$$ P_{\text{network}} = C_a \times A_{\text{eff}}^{\text{network}} + C_b \times B_{\text{eff}}^{\text{network}} + C_s \times S_{\text{eff}}^{\text{network}} $$

其中：

$$ A_{\text{eff}}^{\text{network}} = \frac{A_{\text{included}}^{\text{network}}}{A_{\text{assigned}}^{\text{network}}} $$

$$ B_{\text{eff}}^{\text{network}} = \frac{B_{\text{proposed}}^{\text{network}}}{\text{Slots}_{\text{frame}}} $$

$$ S_{\text{eff}}^{\text{network}} = \frac{S_{\text{included}}^{\text{network}}}{(\text{Slots}{\text{frame}} - \text{Slots}{\text{frame,missed}}) \times 512} $$

总结

综合以上所有计算，最终算法如下：

• CSM Performance Oracle 收集网络中所有验证器的 attestation、区块提议和同步委员会参与数据；
• CSM Performance Oracle 使用以下公式计算网络的平均“统一性能评分”：

$$ P_{\text{network}} = C_a \times \frac{A_{\text{included}}^{\text{network}}}{A_{\text{assigned}}^{\text{network}}} + C_b \times \frac{B_{\text{proposed}}^{\text{network}}}{\text{Slots}{\text{frame}}} + C_s \times \frac{S{\text{included}}^{\text{network}}}{(\text{Slots}{\text{frame}} - B{\text{frame,missed}}) \times 512} $$

• CSM Performance Oracle 使用以下公式计算每个 CSM 验证器的“统一性能评分”：

$$ P_{\text{validatorCSM}} = C_a \times \frac{A_{\text{included}}}{A_{\text{assigned}}} + C_b \times \frac{B_{\text{proposed}}}{B_{\text{assigned}}} + C_s \times \frac{S_{\text{included}}}{S_{\text{assigned}} - B_{\text{missed}}} $$

• CSM Performance Oracle 使用以下值：

  • 如果所有三项职责都被分配：

    $$ C_a = 5464,\quad C_b = 864,\quad C_s = 264 $$

  • 如果分配了 attestation 和区块提议：

    $$ C_a = 5462,\quad C_b = 862,\quad C_s = 0 $$

  • 如果分配了 attestation 和同步委员会：

    $$ C_a = 5456,\quad C_b = 0,\quad C_s = 256 $$

  • 如果只分配了 attestation：

    $$ C_a = 1,\quad C_b = 0,\quad C_s = 0 $$

• CSM Performance Oracle 将 $P_{\text{validatorCSM}}$ 与 $P_{\text{network}} - P_{\text{threshold}}$ 进行比较，以决定奖励分配。

附录 1. 未来演进

CSM v2 将为已识别的独立质押者（solo stakers）引入自定义性能阈值。借助此功能，性能评分的计算可以更加精确（包括投票准确性和包含延迟），同时专门为独立质押者保持足够低的性能阈值。如果没有单独的阈值，采用低阈值的精确性能指标将允许在数据中心（DC）运营的验证器出现大量停机时间，这对协议和整个网络都是净负面。另一方面，如果采用高阈值的精确指标，则具有上述限制的居家质押者将无法获得奖励。

尽管 CSM Performance Oracle 的更新将在 CSM v2 中交付，但仍建议采用“分阶段”的做法，首先实现简化的 attestation 有效性核算。这将缩短开发与发布周期，同时也有助于收集更多关于 CSM 验证器性能的真实数据，从而为确定已识别的独立质押者的降低后性能阈值做出有依据的决策。

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