增强今日的审查抵抗

补充今日的审查阻力

Data Always - 2024年7月10日

tl;dr

来自 localBlockValueBoost 边缘情况的潜在重大收入损失，以及对其有效性的缺乏实证研究，导致共识客户端为其用户做出武断的决定，而没有对审查阻力做出有意义的贡献。在目前的状态下，完全网络采用 localBlockValueBoost 将使不到 1% 的 MEV-Boost 区块恢复到本地构建，同时将超过一半的错过提议者收入集中到不到 1% 的这些恢复中。

为了允许增加 localBlockValueBoost 并提供强大的审查阻力，共识客户端应该引入错过提议者收入的限制，以防止最昂贵的边缘情况。通过适当的调整，有上限的本地价值提升可以在更低的成本下提供比 min-bid 更好的弹性，而无需修改链下协议软件。

假定受众： Ethereum 研究人员和核心开发者。你对 min-bid 和 localBlockValueBoost 的工作原理有概念性的理解。你了解提议者对 min-bid 的低采用率 以及以太坊上审查的状态。

利益冲突： 这项研究完全没有资金支持。作者接触过比特币和以太币，但声明没有其他有意义的利益冲突。

由于包含列表不再计划在 Pectra 更新 中发布，以太坊网络将在最快也要到 2025 年底才能保持强大的审查阻力保证。这种情况只会使该领域的两个主要实体受益：Titan Builder 和 Ethereum 基金会的研究人员 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]。

在此期间，以太坊社区有两种主要工具来对抗审查：

• 构建在 MEV-Boost 中的 min-bid 参数
• 构建在共识客户端中的 localBlockValueBoost 参数

围绕审查阻力的大多数讨论都倾向于关注 min-bid，但由于 MEV-Boost 是 链下协议软件，核心开发者无权更改默认值。为了更改该值，感兴趣的各方需要说服 Flashbots 和更广泛的社区，证明更改是合理的，尽管对市场结构有明显的影响。相比之下，要更改 localBlockValueBoost 的默认值，核心开发者只需要在各个客户端团队内达成共识。

注意： 构建在共识客户端中的比较因子有不同的名称。

• Prysm 和 Nimbus 中的 localBlockValueBoost
• Lighthouse 中的 builder_boost_factor
• Teku 中的 builder-bid-compare-factor
• Lodestar 中的 builderBoostFactor

本文采用了 Prysm 的 localBlockValueBoost 术语，并且分析使用了其比较区块价值的方法。

本文旨在阐明这两种工具的优点和缺点。迄今为止，涉及 localBlockValueBoost 的讨论缺乏实证甚至理论分析，并且经常将两者视为可以互换的。然而，如图 1 所示，它们涵盖的实例差异很大。

图 1：min-bid 和 localBlockValueBoost 的覆盖范围图。参数化都设置为将大约 10% 的 MEV-Boost 区块恢复到本地构建。

方法论

此分析利用 Flashbots 的 mempool dumpster，使用 Dune Analytics 提取，以将交易分为公共和私有订单流。然后，我们通过对来自公共订单流的优先级费用求和来计算本地构建的区块的理论价值。

我们选择将此分析的时间范围限制为 2023 年 10 月至 2024 年 2 月。2 月中旬，go-ethereum 开始执行严格的最低小费政策；此后，他们大大削弱了该政策。我们选择不包括之后的数据，以避免潜在的数据污染。

此方法的主要限制发生在接近 gas 限制的区块中：在此子集中，localBlockValueBoost 比较将被低估。但是，这些区块往往具有重要的 MEV，并且不太可能被恢复。此限制不影响 min-bid 恢复率，但会导致错过的收入指标略微高估其真实值。一些其他值得注意的限制是：

• 我们不考虑执行最低小费策略的执行客户端
• 如果更多区块开始在本地构建，我们不考虑搜索者行为的潜在转变（恢复到 PGA）
• Flashbots 的 mempool dumpster 遗漏了公共交易的一小部分
• 此处分析的数据都是前 Deneb 的，并且可能由于 blobs 略有变化
• 结果随市场条件和生态系统发展而变化，此分析代表了特定时间的快照，但可能无法永久准确地扩展到未来

min-bid

内置于 MEV-Boost 中的 min-bid 参数能够在没有为提议者带来巨大异常损失的情况下提供强大的审查阻力。当明确包含列表不会包含在 Pectra 更新中时，Tim Beiko 打开了一个 pull request 来更改默认值。然而，由于缺乏经验支持，该提案 Swift 被拒绝。目前，更改 min-bid 的默认值并使其可以选择退出似乎不太可能。

鼓励大型实体使用 min-bid 是社会层面可以采取的最强有力的行动。3 月，我们 跟踪了 MEV 数据中的足迹 以表明 min-bid 的使用几乎可以忽略不计——超过一半的使用来自仅仅四个 Lido 节点运营商。

题外话：关于 min-bid 使用情况的更新。

自我们之前的文章以来，Sigma Prime 已经恢复使用 min-bid，并且 Attestant 已将其参数从 0.035 ETH 更新为 0.07 ETH，以匹配其他 Lido 节点运营商。Stakin 在 6 月初停止使用 min-bid。这些更改可以在图 2 中看到。因此，由于 min-bid，现在大约 10% 的 Lido 区块被恢复，或者占网络上所有区块的 3%。

图 2：Lido 节点运营商获得的最低 MEV 支付图。通过监控 MEV 分布中的缺失数据，我们可以实证地监控哪些运营商使用或不使用 min-bid。

目前使用 min-bid 的唯一主要非 Lido 实体是 Upbit 和 Daniel Wang。他们共同恢复了网络上 0.6% 的区块，使标记实体 min-bid 的使用率提高到所有区块的 3.6%。这大约占网络上所有本地区块构建的 40%。

为了衡量 min-bid 设置的有效性，我们转换 获胜 MEV 出价的分布 以构建理论区块恢复的概况。在图 3 中，我们看到对于经常引用的 0.05 值，将恢复 45% 到 55% 的区块，这比引入 min-bid 时 高 30-50%。

图 3：如果所有提议者都使用给定的 min-bid 参数，每月 MEV-Boost 区块的理论份额将被恢复。

区块恢复的份额是研究人员和网络关心的宏观指标，但提议者集合更关心与选择构建自己的区块相关的财务影响。如图 4 所示，在 ETH/USD 汇率为 4,000 美元的情况下，采用 Beiko 的提案将使提议者集合每月损失 500 万到 700 万美元（每年 6000 万到 8400 万美元）。这大致相当于每个验证者每年 60-80 美元（0.05% APR），并且大约占平均提议者 执行层奖励 的 10% 或其 总奖励 的 1.5%。

图 4：如果所有验证者都采用 min-bid，则提议者集合的理论月度成本。

min-bid 的最大优势在于，它对每个区块提议者可能遭受的错过收入的幅度设置了严格的约束。这导致相对公平的损失，如图 5 所示，总成本分布在整个参与验证者集合中。

图 5：选择 min-bid 值的错过收入分配的洛伦兹曲线。吉尼系数范围从 0.27（min-bid：0.01）到 0.35（min-bid：0.07）。

min-bid 的缺点是中继无法了解提议者构建的区块的价值。因此，从公共订单流中获得大部分价值但超过 min-bid 参数价值的区块仍将通过 MEV-Boost 构建，即使收益可能很小。

例如，如果将 min-bid 设置为 0.05，我们将看到一个具有 0.045 ETH 私有订单流且没有公共订单流的区块被恢复，从而导致提议者损失 0.045 ETH。同时，一个具有 0.01 ETH 私有订单流和 1 ETH 公共订单流的区块将不会被恢复，尽管损失仅为 0.01 ETH 且不到区块价值的 1%。

localBlockValueBoost

由于没有简单的方法可以更改 min-bid 默认值，因此核心开发人员转而使用 localBlockValueBoost 作为权宜之计。由 Fredrik Svantes 提出并由 Prysm、Teku 和 Lodestar 实施的值为 10%——该值的选择没有提供对其恢复率或作为审查手段的有效性的实证分析。

Lighthouse 和 Nimbus 仍在讨论更改默认值的可能性，但两者似乎都不太可能采取行动。

要开始了解 localBlockValueBoost 是否可以成为有效的工具，我们首先必须了解来自私有订单流与公共订单流的奖励分配。绘制 MEV-Boost 区块值与公共订单流值的密度图，我们在图 6 中看到 10% 的默认提升错过了分布的核心，并且不太可能产生有意义的影响。

图 6：2023 年 10 月至 2024 年 2 月期间由 MEV 构建者构建的区块的公共订单流份额的核密度估计。

在图 7 中，我们模仿用于 min-bid 的分析，通过从 MEV-Boost 区块中提取公共订单流的值，并为 localBlockValueBoost 的不同参数化创建理论恢复率概况。我们发现，完全网络采用 10% 的默认值将导致大约 0.75% 的 MEV-Boost 区块在 2023 年 10 月至 2024 年 2 月期间恢复到本地构建。

图 7：如果所有提议者都使用给定的 localBlockValueBoost 参数，每月 MEV-Boost 区块的理论份额将被恢复。

Teku 和 Prysm 拥有 57% 的总市场份额，分别在 3 月 26 日和 3 月 27 日的发行版中更改了其默认值。此后，如图 8 所示，本地构建区块的份额呈下降趋势，并且随着市场动态的变化而下降了多达 40%。很明显，现状并没有产生预期的效果，现在是时候重新评估默认值了。

Dune

点击“运行”以获取结果

@data_always with Dune

图 8：最终确定的本地构建区块占每日插槽的份额。在 3 月下旬 Teku 和 Prysm 发布后，我们没有看到任何增加，这表明 localBlockValueBoost 默认值的更改所产生的任何影响已被市场条件的变化所掩盖。

来源：https://dune.com/queries/3798898/6497710

通过 localBlockValueBoost 进行恢复的绝对成本目前很低，因为恢复的区块很少。不幸的是，损失的分配严重倾斜。以 2024 年 1 月为例，如果采用 100% 的采用率，提议者的总损失仅为 9.71 ETH，但 3.57 ETH (37%) 仅来自五个区块（占恢复的 0.3%）。为各种参数化生成洛伦兹曲线，我们在图 9 中看到，在较低的提升值下，大多数错过的收入都隔离在小部分恢复中。

图 9：选择 localBlockValueBoost 值的错过收入分配的洛伦兹曲线。吉尼系数范围从 0.81（localBlockValueBoost：10%）到 0.42（localBlockValueBoost：100%）。

直接比较

为了直接比较这两个可调参数，我们在表 1 中列出了触发等效数量恢复所需的值。我们发现，通过 localBlockValueBoost 获得弹性比通过 min-bid 获得弹性贵 20%–30%。

表 1：参数和平均错过收入（括号中）以恢复等效数量的 MEV-Boost 区块。我们发现 localBlockValueBoost 是一种明显更昂贵的审查阻力工具。基于 2023 年 10 月 1 日至 2024 年 2 月 29 日的数据。

在检查恢复额外区块块的成本时，我们发现 localBlockValueBoost 在整个可能合理恢复的区块块范围内都明显更昂贵。此外，由于发生昂贵的恢复的边缘情况，成本也更不稳定。

图 10：2023 年 10 月至 2024 年 2 月期间 localBlockValueBoost 和 min-bid 的每次额外恢复的比较平均成本。我们发现 localBlockValueBoost 在整个感兴趣的领域中更昂贵且变化更大。

修复 localBlockValueBoost

localBlockValueBoost 的问题都源于高价值的边缘情况。这些异常值放大了恢复的统计成本和情感成本，并使将参数的默认值提高到足以实现有意义的审查阻力的水平变得不切实际。一种自然的解决方案是采用一个额外的参数 maxLocalBoostValue，该参数可用于排除这些异常值并限制区块提议的最大错过收入。

在图 11 中，我们绘制了增加损失上限后的恢复率变化。我们发现，对于低于 30% 的 localBlockValueBoost 默认值，0.01 的 maxLocalBoostValue 足够大，可以消除边缘情况，而不会对恢复率产生有意义的影响。如果共识客户端想要将 localBlockValueBoost 大幅提高，则需要将 maxLocalBoostValue 设置为 0.02 或 0.03 才能将 20% 或更多的区块恢复到本地构建。

图 11：如果在 2023 年 10 月至 2024 年 2 月期间所有提议者都使用 localBlockValueBoost 和 maxLocalBoostValue 参数，则 MEV-Boost 区块的理论份额将被恢复。

一旦消除了昂贵的异常值，恢复的平均成本就可以与 min-bid 的每次恢复的理论成本保持一致或低于该成本。

图 12：2023 年 10 月至 2024 年 2 月期间每次额外恢复的比较平均成本。向 localBlockValueBoost 添加每个区块的最大损失可以将成本降低到与通过 min-bid 进行恢复的理论成本相匹配。

未解决的问题

• 更改默认值依赖于“默认值具有粘性”的假设。是否有任何经验证据表明这一点是否正确？

• 如果在共识客户端而不是 MEV-Boost 中实施了 min-bid，我们可以对损失应用类似的上限。这将如何影响 min-bid 的损失概况？

• 在 localBlockValueBoost 趋于无穷大的限制中，maxLocalBoostValue 在整个领域中占据主导地位，并且我们最终得到了 MEV 区块值与本地区块值的绝对（而不是相对）比较。放弃相对比较而仅仅依赖绝对比较是否更有效？

• 是否值得增加 maxLocalBoostValue 的更多复杂性？localBlockValueBoost 和 maxLocalBoostValue 的组合是一个分段函数，但我们可以制定两个状态之间的平滑过渡，该过渡最初的行为类似于 vanilla localBlockValueBoost，并且在限制中接近与 maxLocalBoostValue 的直接比较（感谢 Alejo Salles 促使进一步优化）。

• 自 5 月以来，网络上的 私有订单流 大幅增加，尤其是在 DEX 交易 中。这对恢复率有多大的影响？

• • *

附录 A：Min-Bid 为 0.07 时的损失分配

• 原文链接： hackmd.io/@dataalways/ce...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～