单一性能阈值还是多个?

lido__ 发布于 2024-02-29 阅读 11

本文探讨了 CSM 性能预言机中性能阈值的设计选择。文章回顾了引入性能阈值的初衷,即鼓励验证者多元化而非单纯追求性能。随后比较了单一阈值与多阈值两种方法:单一阈值简单直接,只有达到阈值的验证者才能获得奖励;多阈值则通过多个阈值和削减系数实现更平滑的奖励分配,但更接近按性能比例分配。作者认为多阈值方法会削弱第一个阈值的激励作用,且参数设定复杂,因此倾向于采用单一阈值,并建议设定为 90%。文章还指出,即使验证者未达标,仍可获得债券复基奖励,这相当于第二个软阈值。

这篇文档深入探讨了 CSM Performance Oracle 中性能阈值的问题。文中考虑了引入性能阈值的动机以及多个阈值可能带来的影响。

为什么需要性能阈值?

在 CSM Performance Oracle 的原始文档中,考虑了多种质押奖励分配方案:

  • 按性能比例分配,并采用不同的性能衡量方法
  • 在表现良好的验证者之间进行社会化分配。其中,表现良好的验证者是指性能高于阈值的验证者,性能以 goodAttestationsCount / totalAttestationsSheduledForPeriod 的比率来衡量

已有几位评审者表示支持第二种方案。因此,该方案成为首选方案。

性能阈值方案可以扩展吗?

在初步讨论之后,Izzy 提出了考虑使用多个阈值而非单一阈值的方案。本文旨在研究多阈值方案的可能选项及其影响。

单一阈值方案

image

性能阈值概念最简单的实现方式是使用单一阈值。简而言之,该方案可以描述如下:

  • Lido DAO 设定性能阈值;
  • CSM Performance Oracle 使用该阈值来定义当前周期内的表现良好者;
  • CSM Performance Oracle 使用 goodAttestationsCount / totalAttestationsSheduledForPeriod 比率作为性能指标;
  • 收集到性能数据后,CSM Performance Oracle 计算应分配给每个 CSM 节点运营商的份额,计算公式为 numberOfWellPerformingVlaidatorsForOperator / totalNumberOfWellPerformingValidatorsInCSM * totalrewardSharesInFrame
  • 为了考虑验证者在周期内的激活和停用(即退出)情况,将 active_rate = slotsValidatorActive/totalSlotsFrame 添加到验证者的权重中;
  • CSM Oracle 将更新后的 Merkle 树根提交到链上;

在这种设计中,只有表现良好的验证者才有资格获得奖励分配,其他验证者则没有。这实际上让性能阈值成为一道悬崖(cliff)。

多阈值方案

image

性能阈值概念的另一种选择是多阈值方案。该方案可以概括如下:

  • Lido DAO 设定多个性能阈值以及每个阈值对应的削减系数;
  • CSM Performance Oracle 使用这些阈值将验证者划分为不同的性能区间;
  • CSM Performance Oracle 使用 goodAttestationsCount / totalAttestationsSheduledForPeriod 比率作为性能指标;
  • 收集到性能数据后,CSM Performance Oracle 按如下方式计算应分配给每个 CSM 节点运营商的份额:
    • 根据批次对验证者数量进行归一化处理,公式为 effectiveNumberOfValidatorsForNodeOperator = numberOfNOValidatorsBatch1 * 1 + numberOfNOValidatorsBatch2 * coeffBatch2 + numberOfNOValidatorsBatch2 * coeffBatch3 + ...
    • 计算节点运营商的份额:sharesForNodeOperator = effectiveNumberOfValidatorsForNodeOperator / totalEffectiveNumberOfValidators * totalCSMRewardSharesInFrame
  • 为了考虑验证者在周期内的激活和停用(即退出)情况,将 active_rate = slotsValidatorActive/totalSlotsFrame 添加到验证者的权重中;
  • CSM Oracle 将更新后的 Merkle 树根提交到链上;

与单一阈值方案相比,这种设计的奖励分配更加平滑。需要注意的是,阈值设置得越多,分配结果就越接近完全按性能比例分配。

该选择哪种方案?

最好的方法是参考引入性能阈值的最初动机

  1. 我认为这是一种有趣的方式,可以含蓄地表明运营商集合的多样化比“最大化性能”更重要(多样化的设置意味着性能会有所损失,某些客户端不够成熟,有些人在低带宽/网络连接较差的地区运营等)
  2. 我们的方案在其他方面也有一些弊端,我们可能将其视为优点,但它也会被解读为缺点(例如,单一合约方案带来的较低 Gas 费用是好事,但从去中心化的角度来看则不利)。这表明我们考虑到了这一点,并通过另一种方式鼓励去中心化来弥补这一点(我们认为这些方式更为重要)
  3. 由于我们是后发者,我们需要提供差异化的功能,我认为这确实是一个有趣的功能,而且不太可能有人比我们先做到。Lido 的规模可以让我们实现这一点,如果我们想反驳“规模 == 不好”的观点,这是一个很好的方式

话虽如此,介于单一阈值和按性能比例分配之间的任何方案,都无法完全满足最初动机中的第一点和第三点。因为使用多个阈值会降低将性能保持在第一个阈值之上的动力。此外,使用多个阈值还提出了一个复杂的问题:如何确定各个阈值和削减系数的实际值。

我的个人看法

从我个人(Dmitry G)的角度来看,最好的方案是采用单一阈值。将阈值的实际值设置得足够低,以容忍短期的性能问题(例如验证者离线 1-2 天),同时又足够高,以将协议整体 APR 保持在可接受的水平。这将直接激励运营商将其验证者的性能维持在阈值之上,而无需任何中间假设。

如果采用多阈值方案,要么我们把第一个阈值设置得过高,从而失去“短暂中断是可接受的”这一理念;要么我们在现有阈值之下再增加几个阈值,仍然会给表现不佳者分配一些奖励,从而降低目标性能的下限。

最后需要记住的一点是 Simple bonds 的设计方式。即使节点运营商低于阈值,他们仍然可以获得债券重基奖励(bond rebase rewards)。这一事实实际上增加了第二个虚拟阈值:“除非你被踢出,否则你仍然可以获得债券重基奖励,这大约相当于 CSM 运营商总奖励的 50%。”

结语

如果我们采用多阈值方案,则需要专门的分析来确定阈值的数量和实际值。

对于单一阈值方案,唯一需要确定的就是阈值的具体数值。我建议设为 90%。

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

相关文章

0 条评论