通过更多反相关激励来支持去中心化质押 - 权益证明

该文章提出了一种通过惩罚验证者在同一时间发生故障的相关性来激励以太坊协议中更好去中心化的方法。文章通过分析验证者在同一集群中发生共同故障的实际数据,证明了这种相关性确实存在。然后,文章提出了一个具体的惩罚方案,该方案根据当前槽中错过的槽数量与最近槽的平均值之比来调整罚款,以减少大型验证者的优势。

内容提示:初步研究。希望看到独立的复现尝试。

代码:https://github.com/ethereum/research/tree/master/correlation_analysis

在协议中,激励更好去中心化的一种策略是惩罚相关性。也就是说,如果一个参与者出现不当行为(包括意外情况),他们受到的惩罚将更大,同时出现不当行为的其他参与者(以总 ETH 衡量)越多。理论是,如果你是一个大型参与者,你所犯的任何错误更有可能在你控制的所有“身份”中复制,即使你将你的币分散到许多名义上独立的账户中。

这种技术已经在以太坊的 slashing(以及可以说是 inactivity leak)机制 中使用。然而,仅在高度特殊的攻击情况下才会出现的边缘情况激励,可能不足以激励去中心化。

本文建议将类似的防相关性激励扩展到更“平凡”的失败,例如错过证明,几乎所有验证者至少偶尔会犯这种错误。理论是,包括富裕个人和 staking pools 在内的大型 staker 将在同一互联网连接甚至同一物理计算机上运行许多验证者,这将导致不成比例的相关失败。这样的 staker 可以始终为每个节点建立独立的物理设置,但如果他们最终这样做,这将意味着我们已经完全消除了 staking 中的规模经济。

理智检查:同一“集群”中不同验证者的错误实际上是否更可能相互关联?

我们可以通过结合两个数据集来检查这一点:(i)来自最近 epoch 的证明数据,显示哪些验证者应该在每个 slot 期间进行证明,以及哪些验证者实际进行了证明,以及(ii)将验证者 ID 映射到包含许多验证者的公开已知集群的数据(例如,“Lido”,“Coinbase”,“Vitalik Buterin”)。你可以在 这里这里这里 找到前者的转储,在 这里 找到后者的转储。

然后,我们运行一个脚本,计算共同失败的总数:同一集群内的两个验证者被分配到同一 slot 进行证明,并在该 slot 中失败的实例。

我们还计算预期共同失败:如果失败完全是随机机会的结果,“应该发生”的共同失败的数量。

例如,假设有 10 个验证者,其中一个集群大小为 4,其余的都是独立的,并且有 3 个验证者失败:两个在该集群内,一个在该集群外。

这里有一个共同失败:第一个集群中的第二个和第四个验证者。如果该集群中的所有四个验证者都失败了,那么将有_六个_共同失败,每个可能的六个对各一个。

但是“应该”有多少个共同失败?这是一个棘手的哲学问题。一些回答方法:

  • 对于每个失败,假设共同失败的数量等于该 slot 中其他验证者的失败率乘以该集群中的验证者数量,然后将其减半以补偿重复计算。对于上面的例子,这给出了 \frac{2}{3}。
  • 计算全局失败率,将其平方,然后对于每个集群,将其乘以 \frac{n * (n-1)}{2}。这给出了 (\frac{3}{10})^2 * 6 = 0.54。
  • 在每个验证者的整个历史记录中随机重新分配每个验证者的失败。

每种方法都不是完美的。前两种方法未能考虑到不同的集群具有不同的质量设置。与此同时,最后一种方法未能考虑到不同 slot 具有不同的_内在困难_所引起的相关性:例如,slot 8103681 有大量未包含在单个 slot 中的证明,可能是因为该区块发布的时间异常晚。

\ 882×227 11.8 KB

请参阅此 python 输出中的“10216 ssfumbles”。

我最终实现了三种方法:上述前两种方法,以及一种更复杂的方法,我将“实际共同失败”与“虚假共同失败”进行比较:在这种失败中,每个集群成员都被具有相似失败率的(伪)随机验证者替换。

我还明确区分了 fumblesmisses。我将这些术语定义如下:

  • Fumble:当验证者在当前 epoch 中错过证明,但在上一个 epoch 中正确证明时
  • Miss:当验证者在当前 epoch 中错过证明,并且在上一个 epoch 中也错过时

目标是区分 (i) 正常运行期间的网络小故障,以及 (ii) 离线或出现长期故障这两种截然不同的现象。

我还同时对两个数据集进行此分析:max-deadlinesingle-slot-deadline。第一个数据集仅当证明根本未包含时才将验证者视为在一个 epoch 中失败。如果证明未在_单个 slot 内_被包含,则第二个数据集将验证者视为已失败。

这是我使用前两种方法计算预期共同失败的结果。SSfumbles 和 SSmisses 在这里指的是使用 single-slot 数据集的 fumbles 和 misses。

Fumbles Misses SSfumbles SSmisses
Expected (algo 1) 8602090 1695490 604902393 2637879
Expected (algo 2) 937232 4372279 26744848 4733344
Actual 15481500 7584178 678853421 8564344

对于第一种方法,“Actual”行是不同的,因为为了提高效率,使用了更受限制的数据集:

Fumbles Misses SSfumbles SSmisses
Fake clusters 8366846 6006136 556852940 5841712
Actual 14868318 6451930 624818332 6578668

“expected”和“fake clusters”列显示了如果集群是不相关的,基于上述技术,集群内“应该有多少”共同失败。“actual”列显示了实际有多少共同失败。统一地,我们看到了集群内“过度相关失败”的有力证据:同一集群中的两个验证者在同一时间错过证明的可能性明显高于不同集群中的两个验证者。

我们如何将其应用于惩罚规则?

我提出了一个简单的草案:在每个 slot 中,令 p 为当前错过 slot 的数量除以过去 32 个 slot 的平均值。也就是说,p[i] = \frac{misses[i]}{\sum_{j=i-32}^{i-1}\ misses[j]}。限制它:p \leftarrow min(p, 4)。该 slot 证明的惩罚应与 p 成正比。也就是说,在某个 slot 没有进行证明的惩罚应该与该 slot 中失败的验证者数量与_最近其他 slot 相比_成正比

这种机制有一个很好的特性,即它不容易受到攻击:没有失败会_减少_你的惩罚的情况,并且操纵平均值以产生影响需要你自己造成大量失败。

现在,让我们尝试实际运行它。以下是大型集群、中型集群、小型集群和所有验证者(包括非集群)在四种惩罚方案下的总惩罚:

  • basic:每次 miss 惩罚一分(即类似于现状)
  • basic_ss:相同,但要求 single-slot 包含才能不算作 miss
  • excess:惩罚 p 分,其中 p 的计算如上
  • excess_ss:惩罚 p 分,其中 p 的计算如上,要求 single-slot 包含才能不算作 miss

这是输出:

                   basic          basic_ss       excess         excess_ss
big                0.69           2.06           2.73           7.96
medium             0.61           3.00           2.42           11.54
small              0.98           2.41           3.81           8.77
all                0.90           2.44           3.54           9.30

使用“basic”方案,big 比 small 有 ~1.4 倍的优势(在 single-slot 数据集中为 ~1.2 倍)。使用“excess”方案,这降至 ~1.3 倍(在 single-slot 数据集中为 ~1.1 倍)。通过多次其他迭代,使用略有不同的数据集,excess 惩罚方案一致地缩小了“大人物”相对于“小人物”的优势

发生了什么?

每个 slot 的失败次数很少:通常只有几十个。这比几乎任何“大型 staker”都要小得多。事实上,这比大型 staker 在单个 slot 中活跃的验证者数量还要少(即他们总库存的 1/32)。如果大型 staker 在同一物理计算机或互联网连接上运行多个节点,那么任何故障都有可能影响他们的所有验证者。

这意味着:当大型验证者出现证明包含失败时,他们会独自移动当前 slot 的失败率,从而反过来增加他们的惩罚。小型验证者不会这样做。

原则上,大型 staker 可以通过将每个验证者放在单独的互联网连接上来避免这种惩罚方案。但这牺牲了大型 staker 在能够重复使用相同物理基础设施方面的规模经济优势。

进一步分析的主题

  • 找到其他策略来确认这种效应的大小,即同一集群中的验证者异常可能同时出现证明失败
  • 尝试找到理想的(但仍然简单,以免过度拟合且不易被利用)奖励/惩罚方案,以最大限度地减少大型验证者相对于小型验证者的平均优势。
  • 尝试证明关于此类激励方案的安全属性,理想情况下确定一个“设计空间区域”,在该区域内,怪异攻击(例如,在特定时间策略性地离线以操纵平均值)的风险太高而不值得
  • 按地理位置聚类。这可以确定该机制是否也创造了地理上去中心化的激励。
  • 按(执行和信标)客户端软件聚类。这可以确定该机制是否也创造了使用少数客户端的激励。

迷你常见问题解答

:但这难道不会导致 staking pools 在架构上实现基础设施的去中心化,而没有在政治上实现自我去中心化吗?我们现在更关心的难道不是后者吗?

:如果他们这样做,那会增加他们的运营成本,使 solo staking 相对更具竞争力。目标不是单方面地强制执行单人 staking,目标是使激励的经济部分更加平衡。在协议中激励政治去中心化似乎非常困难或不可能;对于这一点,我认为我们将不得不依靠社会压力、类似 starknet 的空投等。但是,如果可以调整经济激励以支持架构去中心化,那将使政治上去中心化的项目(这些项目无法避免在架构上去中心化)更容易启动。

:这难道不会最伤害“中型 staker”(不是大型交易所/pools 的富裕个人),并鼓励他们转移到 pools 吗?

:在上表中,“small”部分指的是拥有 10-300 个验证者的 staker,即 320-9600 ETH。这包括大多数富人。而且正如我们所看到的,这些 staker 今天遭受的惩罚明显高于 pools,并且模拟显示了拟议的调整后奖励方案将如何在这些验证者和真正的大型验证者之间实现平等。从数学上讲,拥有 100 个验证者 slot 的人每个 slot 只有 3 个,因此他们不会极大地影响一轮的惩罚因子;只有远高于此值的验证者才会。

:在 MAXEB 之后,大型 staker 不会通过将他们所有的 ETH 合并到一个验证者中来绕过这个问题吗?

:比例惩罚公式将计算 ETH 的总量,而不是验证者 ID 的数量,因此,如果 4000 个 staked ETH 的行为方式相同,那么无论它是在 1 个验证者、2 个验证者还是 125 个验证者之间拆分,都将被视为相同。

:无论细节如何,增加更多在线激励难道不会进一步施加优化压力,从而导致中心化吗?

:可以设置参数,使平均而言,在线激励的大小与今天相同。

  • 原文链接: ethresear.ch/t/supportin...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文, 用中文传播以太坊的最新进展