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

以太坊中文
发布于 2024-03-29 23:24
阅读 105

文章提出了通过惩罚验证者在同一时间的不当行为（包括意外情况）来激励以太坊协议中更好的去中心化。文章分析了验证者在同一集群中出现错误时，彼此之间是否更容易相关，并提出了一个简单的惩罚方案：对在特定 slot 中未参与 attestation 的验证者进行惩罚，惩罚程度与该 slot 中失败的验证者数量相对于最近 slot 的平均值成正比。

**内容提示：初步研究。 希望看到独立的复制尝试。**

**代码：[https://github.com/ethereum/research/tree/master/correlation\_analysis](https://github.com/ethereum/research/tree/master/correlation_analysis)**

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

以太坊已经在 [slashing（以及可以说是非活动泄漏）机制](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#aside-anti-correlation-penalties-in-eth2) 中采用了这种技术。 然而，仅在高度特殊的攻击情况下才会出现的边缘情况激励可能不足以激励去中心化，而这种情况在实践中可能永远不会出现。

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

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

我们可以通过结合两个数据集来检查这一点：(i) 来自最近 Epoch 的 **证明数据**，显示哪些验证者应该在每个 Slot 中证明，以及哪些验证者实际上确实进行了证明，以及 (ii) 将验证者 ID 映射到包含许多验证者的公开已知 **集群** 的数据（例如“Lido”、“Coinbase”、“Vitalik Buterin”）。 你可以在[这里](https://data.ethpandaops.io/efresearch/attesters.txt)、[这里](https://data.ethpandaops.io/efresearch/immediate_attesters.txt) 和[这里](https://data.ethpandaops.io/efresearch/committees.txt)找到前者的转储，在[这里](https://data.ethpandaops.io/efresearch/clusters.csv)找到后者的转储。

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

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

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

![](https://img.learnblockchain.cn/2025/08/06/e103e9e08c8e2aedd5d5fa0e004b8429f5cb2af2.png)

这里有一个共同失败：第一个集群中的第二个和第四个验证者。 如果该集群中的所有四个验证者都失败了，则会有 **六个** 共同失败，每个可能的 pair 对应一个。

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

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

每种方法都不是完美的。 前两种方法未能考虑到不同的集群具有不同的质量设置。 同时，最后一种方法未能考虑到因不同 Slot 具有不同的 **固有难度** 而产生的相关性：例如，Slot [8103681](https://beaconcha.in/slot/8103681) 有大量未包含在单个 Slot 中的证明，这可能是因为区块发布的时间异常晚。

[![](https://img.learnblockchain.cn/2025/08/06/c34994d5a8fe647e304a91b98a72361eeb532c48.png)\\
882×227 11.8 KB](https://ethresear.ch/uploads/default/original/2X/c/c34994d5a8fe647e304a91b98a72361eeb532c48.png “”)

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

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

我还明确地分离出 **Fumble** 和 **Miss**。 我将这些术语定义如下：

- **Fumble**：当验证者错过当前 Epoch 中的证明，但在前一个 Epoch 中正确证明时
- **Miss**：当验证者错过当前 Epoch 中的证明，并且在前一个 Epoch 中也错过时

目标是将 (i) 正常运行期间的网络中断和 (ii) 下线或出现长期故障这两种截然不同的现象分开。

我还同时对两个数据集进行此分析：**max-deadline** 和 **single-slot-deadline**。 第一个数据集仅当证明从未被包含时才将验证者视为在一个 Epoch 中失败。 第二个数据集仅当证明没有在 **单个 Slot 内** 包含时才将验证者视为失败。

以下是我使用前两种计算预期共同失败的方法得到的结果。 此处的 SSfumbles 和 SSmisses 是指使用单 Slot 数据集的 Fumble 和 Miss。

|  | 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\[i\]=misses\[i\]∑i−1j=i−32misses\[j\]。 限制它：p \\leftarrow min(p, 4)p←min(p,4)。 对该 Slot 的证明的惩罚应与 pp 成正比。 也就是说，**在 Slot 中不进行证明的惩罚应与在该 Slot 中失败的验证者数量与其他最近的 Slot 相比成正比**。

这种机制的一个优点是它不易受到攻击：没有一种情况是失败 **减少** 你的惩罚，并且操纵平均值以产生影响需要你自己制造大量失败。

现在，让我们尝试实际运行它。 这是对于四种惩罚方案的大型集群、中型集群、小型集群和所有验证者（包括非集群）的总惩罚：

- **`basic`**：每次错过惩罚一个点（即类似于现状）
- **`basic_ss`**：相同，但需要单 Slot 包含才能不算作错过
- **`excess`**：惩罚 `p` 点，其中 `p` 如上计算
- **`excess_ss`**：惩罚 `p` 点，其中 `p` 如上计算，需要单 Slot 包含才能不算作错过

以下是输出：

```hljs scss

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 倍（在单 Slot 数据集中约为 1.2 倍）。 使用“excess”方案，这降至约 1.3 倍（在单 Slot 数据集中约为 1.1 倍）。 通过多次其他迭代，使用略有不同的数据集，**excess 惩罚方案统一缩小了“大个子”相对于“小个子”的优势**。

## 发生了什么？

每个 Slot 的失败数量很少：通常只有几十个。 这比几乎任何“大型 Staker”都要小得多。 事实上，这小于大型 Staker 在 **单个 Slot 中** 活跃的验证者数量（即其总量的 1/32）。 如果大型 Staker 在同一台物理计算机或互联网连接上运行许多节点，那么任何失败都可能会影响其所有验证者。

这意味着：当大型验证者出现证明包含失败时，他们会单独移动当前 Slot 的失败率，进而增加他们的惩罚。 小型验证者不会这样做。

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

## 进一步分析的主题

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

## 迷你常见问题解答

**问**：但这难道不会导致 Staking 池在架构上实现基础设施的去中心化，而不在政治上实现自身的去中心化吗，而后者是我们目前更关心的吗？

**答**：如果他们这样做，那么会增加他们的运营成本，使单独 Staking 相对更具竞争力。 目标不是单独强制进行单独 Staking，目标是使激励的经济部分更加平衡。 政治去中心化似乎很难或不可能在协议中激励；对于这一点，我认为我们只需要依靠社会压力、starknet 类的空投等等。 但是，如果可以调整经济激励措施以支持架构去中心化，那么对于政治上分散的项目（它们无法避免在架构上分散）来说，启动会更容易。

**问**：难道这不会最伤害“中型 Staker”（不是大型交易所/池的富人），并鼓励他们转移到池中吗？

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

**问**：后 MAXEB 时代，大型 Staker 不会通过将所有 ETH 合并到一个验证者中来规避这一点吗？

**答**：比例惩罚公式将计算 ETH 的总数量，而不是验证者 ID 的数量，因此，无论是拆分到 1 个验证者、2 个验证者还是 125 个验证者，行为方式相同的 4000 个质押 ETH 都将被视为相同。

**问**：无论细节如何，增加更多在线激励是否会进一步增加优化压力，从而导致中心化？

**答**：参数可以设置成，平均而言，在线激励的大小与今天相同。

- [相关 Attester 惩罚的具体提案](https://learnblockchain.cn/article/19422)
- [规模不经济：反相关惩罚 (EIP-7716)](https://learnblockchain.cn/article/19393)

>- 原文链接： [ethresear.ch/t/supportin...](https://ethresear.ch/t/supporting-decentralized-staking-through-more-anti-correlation-incentives/19116/12)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

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

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

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

以太坊已经在 slashing（以及可以说是非活动泄漏）机制中采用了这种技术。然而，仅在高度特殊的攻击情况下才会出现的边缘情况激励可能不足以激励去中心化，而这种情况在实践中可能永远不会出现。

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

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

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

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

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

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

这里有一个共同失败：第一个集群中的第二个和第四个验证者。如果该集群中的所有四个验证者都失败了，则会有六个共同失败，每个可能的 pair 对应一个。

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

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

每种方法都不是完美的。前两种方法未能考虑到不同的集群具有不同的质量设置。同时，最后一种方法未能考虑到因不同 Slot 具有不同的 固有难度 而产生的相关性：例如，Slot 8103681 有大量未包含在单个 Slot 中的证明，这可能是因为区块发布的时间异常晚。

[\ 882×227 11.8 KB](https://ethresear.ch/uploads/default/original/2X/c/c34994d5a8fe647e304a91b98a72361eeb532c48.png “”)

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

我还明确地分离出 Fumble 和 Miss。我将这些术语定义如下：

Fumble：当验证者错过当前 Epoch 中的证明，但在前一个 Epoch 中正确证明时
Miss：当验证者错过当前 Epoch 中的证明，并且在前一个 Epoch 中也错过时

目标是将 (i) 正常运行期间的网络中断和 (ii) 下线或出现长期故障这两种截然不同的现象分开。

我还同时对两个数据集进行此分析：max-deadline 和 single-slot-deadline。第一个数据集仅当证明从未被包含时才将验证者视为在一个 Epoch 中失败。第二个数据集仅当证明没有在 单个 Slot 内 包含时才将验证者视为失败。

以下是我使用前两种计算预期共同失败的方法得到的结果。此处的 SSfumbles 和 SSmisses 是指使用单 Slot 数据集的 Fumble 和 Miss。

	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[i]=misses[i]∑i−1j=i−32misses[j]。限制它：p \leftarrow min(p, 4)p←min(p,4)。对该 Slot 的证明的惩罚应与 pp 成正比。也就是说，在 Slot 中不进行证明的惩罚应与在该 Slot 中失败的验证者数量与其他最近的 Slot 相比成正比。

这种机制的一个优点是它不易受到攻击：没有一种情况是失败减少你的惩罚，并且操纵平均值以产生影响需要你自己制造大量失败。

现在，让我们尝试实际运行它。这是对于四种惩罚方案的大型集群、中型集群、小型集群和所有验证者（包括非集群）的总惩罚：

basic：每次错过惩罚一个点（即类似于现状）
basic_ss：相同，但需要单 Slot 包含才能不算作错过
excess：惩罚 p 点，其中 p 如上计算
excess_ss：惩罚 p 点，其中 p 如上计算，需要单 Slot 包含才能不算作错过

以下是输出：


                   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 倍（在单 Slot 数据集中约为 1.2 倍）。使用“excess”方案，这降至约 1.3 倍（在单 Slot 数据集中约为 1.1 倍）。通过多次其他迭代，使用略有不同的数据集，excess 惩罚方案统一缩小了“大个子”相对于“小个子”的优势。

发生了什么？

每个 Slot 的失败数量很少：通常只有几十个。这比几乎任何“大型 Staker”都要小得多。事实上，这小于大型 Staker 在 单个 Slot 中 活跃的验证者数量（即其总量的 1/32）。如果大型 Staker 在同一台物理计算机或互联网连接上运行许多节点，那么任何失败都可能会影响其所有验证者。

这意味着：当大型验证者出现证明包含失败时，他们会单独移动当前 Slot 的失败率，进而增加他们的惩罚。小型验证者不会这样做。

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

进一步分析的主题

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

迷你常见问题解答

问：但这难道不会导致 Staking 池在架构上实现基础设施的去中心化，而不在政治上实现自身的去中心化吗，而后者是我们目前更关心的吗？

答：如果他们这样做，那么会增加他们的运营成本，使单独 Staking 相对更具竞争力。目标不是单独强制进行单独 Staking，目标是使激励的经济部分更加平衡。政治去中心化似乎很难或不可能在协议中激励；对于这一点，我认为我们只需要依靠社会压力、starknet 类的空投等等。但是，如果可以调整经济激励措施以支持架构去中心化，那么对于政治上分散的项目（它们无法避免在架构上分散）来说，启动会更容易。

问：难道这不会最伤害“中型 Staker”（不是大型交易所/池的富人），并鼓励他们转移到池中吗？

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

问：后 MAXEB 时代，大型 Staker 不会通过将所有 ETH 合并到一个验证者中来规避这一点吗？

答：比例惩罚公式将计算 ETH 的总数量，而不是验证者 ID 的数量，因此，无论是拆分到 1 个验证者、2 个验证者还是 125 个验证者，行为方式相同的 4000 个质押 ETH 都将被视为相同。

问：无论细节如何，增加更多在线激励是否会进一步增加优化压力，从而导致中心化？

答：参数可以设置成，平均而言，在线激励的大小与今天相同。

原文链接： ethresear.ch/t/supportin...

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

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。