如果提议者提议区块的时间晚了，会对见证有何影响？

原文标题：《On Attestations, Block Propagation, and Timing Games》

撰文：Nero_eth

如今，提议者的时序博弈已经很常见了，很多研究也都在分析这一现象。

本篇文章将带大家了解提议者时序博弈的演变，并分析其对见证者的影响。通过对 Lido、Coinbase 和 Kiln 的节点运营商的案例研究，我们将深入探讨区块提议的时序博弈及其对以太坊共识的影响。

截至 2024 年 8 月，区块构建市场在很大程度上被外包处理，其中约 90% 的区块是由 mevboost 区块构建者构建的。其中， Titan Builder 和 Beaverbuild 构建了大约 80% 的区块。

Kiln 是推动时序博弈的主要实体之一，在单个 slot 内，其将区块提议推迟了 3-3.5 秒。

在当前的 mevboost 环境中，区块传播主要通过中继器完成。虽然提议者在从中继器接收到区块后仍会传播它，但中继器通常具有更好的网络连接，因此可以更快地完成传播。然而，时序仍然由提议者控制，他们可以延迟其「getHeader」调用以进行时序博弈。

这张图表展示了时序博弈的演变。我们可以看到，随着时间的推移，Kiln 验证者提议的区块在 slot 内是相对滞后的。

这会对网络产生影响：由 Kiln 提议者提出的区块，错过/错误的区块头投票率显著更高。

之前的分析显示，等待时间越长，错过区块头投票的预期数量越高（「80% 的见证发生在 slot 中的第 5 秒」）。Kiln 在非常晚的时候提议区块，导致一些见证者错过它们，并且反而投票给父区块。每个 slot 大约会分配 32,000 个验证者，这将导致约 10% 错误的区块投票率。

让我们来看看三个大型节点运营商的见证行为，并比较它们如何对不同时间内提议的区块做出反应。下图显示了 slot 内正确和及时的区块头投票分布秒数。

对于早期区块，我们观察到 Lido 和 Coinbase 在投票模式上呈现出一种特有的「U」形，这可能是由于不同的地理位置或客户端软件造成的。相比之下， Kiln 显示出一个明显的峰值，比 Coinbase 和 Lido 的第一个峰值略有滞后。然而，对于较晚的区块，Kiln 的见证者也显示出「U」形模式。

当区块在 slot 中第 4 秒首次出现时（由于是 P2P 网络，每个节点接收到区块的时间不同），Lido 见证者比 Kiln 或 Coinbase 见证者提前最多 2 秒进行见证。这种模式并不一定表明 Kiln 在执行「个人策略」。相反，这可能归因于客户端的不同或地理位置的不同。

到底是谁影响了谁？

在下图中，我们比较了不同提议者下节点运营商的表现。例如，y=1 上方的绿色部分表明，当 Kiln 作为提议者提议区块时，Lido 见证者将更容易错过区块头投票。然而，当 Lido 作为提议者时，Lido 见证者在见证区块最及时。虚线 1 表示所有实体作为提议者时错过区块头投票的平均份额。低于 1 的柱状图意味着与平均值相比，特定实体与各自提议者联合时错过的区块头投票较少。

值得注意的是，节点运营商在处理其自己提议的区块时表现最好。

快速总结一下我们看到的内容：

在其他运营商作为提议者提议区块时，大多数运营商表现都相对稳定。

在 Kiln 作为提议者提议区块时，Figment、Lido、Kraken 和 EtherFi 表现较差。

在 Kiln 作为提议者提议区块时，只有 Kiln 和 Binance 表现更好。

Kiln 作为见证者表现很好。早期分析表明，在涉及到高性能验证者时，Kiln 表现优异。有关 Kiln 见证表现的更多详细信息，请参阅这篇分析。

但 Kiln 引发了压力。现在我们知道，Kiln 提议的区块给其他见证者带来了压力，但并未给 Kiln 的见证者带来压力。

目前，很难对「How」作出解释。一个可能的解释是 Kiln 的验证者高度集中，共址运行，或者具有非常密集的对等连接。另一种原因可能是通过定制的对等网络/私人网络或通过其他额外的通信层连接它们的验证者进行协调行为。后一种被认为更具中心化特性，因为它更加强调规模经济。

当我们观查 Lido 和 Coinbase 在各自作为提议者提议区块时的（正确且及时的）见证时间时，我们可以观察到类似的模式。

有趣的是，Kiln 开发了一种从 3.8 秒到 6.1 秒的「U」形分布用于它们自己的晚期区块，而Lido在4.2秒出现一个峰值，Coinbase在 slot 中的第4秒开始出现一个高原，并在第6秒出现一个小的峰值。

防止自己的提议的区块被重组

让我们将注意力转向被重组的区块。从节点运营商的角度来看，一个策略可能是永远不为重组自己的区块投票。简单地说，「如果提议者是我，永远不要将父区块投票为区块头」。

在接下来的部分中，我将使用「本地区块」来代表「自己提议的区块」。

下图是为重组区块投票的见证者与为父区块投票的见证者的百分比。红色部分显示了该实体投票给重组区块的见证者的百分比。

Kiln 表现出了异常行为。当大多数节点运营商的见证者诚实地为正确的区块头投票而不是本地区块时，Kiln 的见证者却并不这么做。超过 10% 的 Kiln 见证者试图通过为本地区块投票来将其保持在链上。如果采用这样的策略，它们可能会由于为错误的区块头投票而产生损失。然而，这些策略通常在以太坊社区中受到鄙视：「不要玩弄共识」。

该图表使用了365天的数据。因此，如果在过去一年内实施了一些复杂的策略，红色部分的比例会相应较小。

但我们如何看待其他层面的协作？

关于见证的协作，作为社区，我们似乎接受了运行在同一节点上的验证者为相同的 checkpoints 投票的事实。

我们可能不希望采取任何跨越物理机器边界的努力来提高验证者之间的协作。这应当是每个人都可以构建的。这种协作可能有不同的形式：

级别1 – 回退机制与静态对等连接：为多个物理机器提供一个中央备用/备份节点。这也可以是一个断路器，一些特别容错的机器，作为信息的私人中继器。具有改进对等连接、私人网络或类似设置的设置也可能属于此类别。

级别2 – 如果-否则规则：在某些 slot 中等待更长时间的硬编码规则。那些将安装在多个物理机器上，允许它们基于预定义规则「协作」。

级别3 – 僵尸网络：有一个中心化的预言机与所有验证者通信，并提供投票的 checkpoints 以及它们应在何时发布的时间戳。

在我看来，后两种形式的协作（级别2和3）是有问题的，节点运营商应当承担责任。最后，对于涉及静态对等连接和私人网络的策略可能存在灰色地带。

这样的设置可能会被用于运行（恶意）策略，例如：

确保跨多个物理机器从不对不同的 checkpoints 投票。

确保永远不会对重组自己提议的区块投票。

基于连续的提议者进行协作（诚实重组客户端（y/n））。

审查某个方的见证。

不为某方的区块投票。

其他。

在讨论协作时，区分两种类型是重要的：

协作行为发生在从同一物理机器运行的验证者之间。

协作行为源于运行相同的修改后的客户端软件或依赖于相同的中心化预言机。

反对复杂协作验证者行为的潜在解决方案是 EIP-7716：反相关处罚，该提案建议根据验证者之间的相关性来调整处罚。