该文章提出了一种通过惩罚验证者在同一时间发生故障的相关性来激励以太坊协议中更好去中心化的方法。文章通过分析验证者在同一集群中发生共同故障的实际数据,证明了这种相关性确实存在。然后,文章提出了一个具体的惩罚方案,该方案根据当前槽中错过的槽数量与最近槽的平均值之比来调整罚款,以减少大型验证者的优势。
内容提示:初步研究。希望看到独立的复现尝试。
代码: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 具有不同的_内在困难_所引起的相关性:例如,slot 8103681 有大量未包含在单个 slot 中的证明,可能是因为该区块发布的时间异常晚。
请参阅此 python 输出中的“10216 ssfumbles”。
我最终实现了三种方法:上述前两种方法,以及一种更复杂的方法,我将“实际共同失败”与“虚假共同失败”进行比较:在这种失败中,每个集群成员都被具有相似失败率的(伪)随机验证者替换。
我还明确区分了 fumbles 和 misses。我将这些术语定义如下:
目标是区分 (i) 正常运行期间的网络小故障,以及 (ii) 离线或出现长期故障这两种截然不同的现象。
我还同时对两个数据集进行此分析:max-deadline 和 single-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 包含才能不算作 missexcess
:惩罚 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 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!