构建者审查：以太坊腐烂的核心

构建者审查：以太坊腐烂的核心

感谢 Mike, Justin 和 Toni 的审查和讨论

tl;dr

• 以太坊现在面临“构建者审查”，即区块构建者审查用户的交易。
• 审查损害了金融协议、预言机更新、隐私，甚至用户体验。
• “包含列表”：一种将控制权转移给提议者以对抗审查的提议解决方案。
• 临时解决方案包括中继构建的包含列表和部分区块中继。
• 实施包含列表对构建者的影响仍然不确定，但充满希望。

介绍

随着 mev-boost PBS 模型的引入，我们将审查交易的大部分能力从提议者转移到 区块构建者。构建者可以（并且正在）审查用户的交易……

以下是你应该关心的原因，以及我们已经拥有的解决方案：

为什么审查不好？

审查是指阻止或延迟用户使用以太坊区块链的能力。 实际上，这意味着阻止（或延迟）任何涉及地址的交易被添加到区块链中。

有两种类型的审查：

• 强审查 - 完全阻止交易上链
• 弱审查 - 延迟交易，使其长时间无法被包含。

在本文中，我们将讨论弱审查。

根据 Vitalik 的说法，如果审查在以太坊上盛行，很多事情可能会出错。在 一篇关于该主题的 2015 年文章 中，Vitalik 深入探讨了审查是一个问题的几个原因：

金融协议审查

许多 DeFi 协议在以太坊上运行。 其中大多数依赖于用户发送交易以保持 经济保证 完好无损的能力。 一个例子是像 Aave 这样的借贷协议，它依赖于 MEV 机器人来触发不健康头寸的清算。

如果所有清算尝试都被审查延迟，Aave 可能会留下坏账。

预言机更新审查

在我们有任何中心化预言机的良好替代方案之前，我们需要考虑预言机更新交易可能被审查的可能性。如果预言机更新被延迟 几分钟， 后果可能是灾难性的。

例如：如果一个协议依赖于 10 个预言机提供商的中位数投票，这些提供商都对一个价格进行投票，那么攻击者可以审查除他们自己之外的所有投票，从而导致绝对的预言机价格操纵。 正如我们在 Mango Markets Hack 中看到的那样，预言机操纵可能导致 数百万美元 的损失。

[新] 强制包含审查

Vitalik 在他的标志性 Endgame 文章 中提到了最后一个原因。

虽然未包含在 Vitalik 的原始文章中，但近期乐观 rollup 的兴起带来了一个新问题。如果 rollup 排序器（中心化、共享式或去中心化式）审查用户，他们将无法逃离 rollup，除非在以太坊上强制包含。

如果用户受到审查，他们需要某种方式来强制从 rollup 中提取资金，或者强制将其交易包含到 L2 中。 — Rollups Aren’t Real - Jon Charbonneau

如果强制包含交易在以太坊上受到审查，用户将延迟从审查 rollup 中提取资金。这大大增加了依赖中心化排序器的风险。

Jon Charbonneau 总结道：

即使 rollup 运营商正在审查用户，他们也应该能够强制包含他们的交易，以保持抗审查性。 — Rollups Aren’t Real - Jon Charbonneau

隐私

当今以太坊中关于审查的主要担忧之一是 tornado cash 制裁。 对这些交易的明确审查意味着用户对链上隐私服务的访问权限减少了。重要的是要注意，tornado cash 制裁设定的先例是，政府有可能取消一群使用以太坊的人的银行服务。

总结

像往常一样，Vitalik 说得最好：

综上所述，反审查甚至与公民自由无关； 而是为了使共识参与者更难以从事大规模的市场操纵阴谋 — 审查问题 - Vitalik Buterin

同样重要的是要认识到，小规模的审查会对以太坊的 用户体验和 可信中立性 产生负面影响。

去中心化加密经济系统中的抗审查性不仅仅是确保 Wikileaks 捐款或 Silk Road 5.0 不会被关闭的问题； 实际上，它是确保许多不同金融协议有效运行的必要属性。 — 审查问题 - Vitalik Buterin

理想情况下，即使延迟交易也应该非常昂贵（尽可能接近不可能）。

为什么构建者审查不好？

由于提议者是在 PBS 中选择他们发布的区块的人（甚至在 某些类型的 enshrined PBS 模型 中也是如此），为什么我们应该关心构建者是否审查？ 是否有些提议者会直接忽略构建者并构建自己的区块？

说得对，但不幸的是，我们不能在长期或短期内仅仅依赖于这个假设。 让我们看看原因：

长期

未来对以太坊协议的升级（例如无状态验证器）可能会减少启用 mev-boost 的提议者的费用，从而抑制自建。

仅此一项就令人担忧，但在未来，提议者完全不可能在本地构建（例如，某些类型的 enshrined PBS）。

短期

即使在短期内，mev-boost PBS 的激励结构也会抑制抗审查性。 问题是：所有提议者都面临一个选择：

• 将所有交易纳入权出售给构建者 - 以获得 MEV 区块奖励，或者，
• 在本地构建普通区块，牺牲所有 MEV 奖励 - 并包含被审查的交易

通过出售交易纳入权，提议者放弃了强制纳入交易的任何能力。 因此，提议者必须依赖构建者来实现抗审查性。 因此，当前的 PBS 模型依赖于以下属性来实现抗审查：

• 淘汰: 非审查构建者可以持续赢得 MEV 拍卖（产生更好的区块）。 这意味着可审查的交易仍将被定期纳入。
• 或，利他主义： 提议者定期牺牲更高的区块奖励以在本地构建。

如果淘汰没有发生，我们仍然可以退回到利他主义，反之亦然。 不幸的是以太坊协议今天并没有激励这两种属性：

我们不能依赖淘汰， 因为可审查的交易通常具有非常低的 MEV 价值。 近几个月来，我们已经看到作为非审查构建者的优势并不显着。 根据 Ultrasound Money 中继，多个顶级构建者正在审查。 我们不能承担主要构建者正在审查的风险。

我们也不能依赖利他主义。 鉴于 PBS 区块的价值是普通区块的 3.52 倍，因此大约 93% 的提议者选择使用 PBS 并不奇怪。 通过迫使任何利他主义的提议者牺牲 70% 的潜在奖励，我们正在抑制利他主义的提议者。 从本质上讲，我们使利他主义变得昂贵。

需要注意的是，Flashbots 增加了一项 功能，即区块需要值的最低 ETH 金额，提议者才会选择它而不是自建。 这并不意味着选择区块来源的选择不那么绝对，只是提议者可能正在对自建做出更明智的决定。

构建者现在审查多少？

合并后，Flashbots 中继拥有很大的市场份额，但正在审查。 研究人员开始将审查问题视为中继问题。 以上所有关于审查的问题也适用于中继。 中继审查问题主要通过社会共识解决 - 抵制审查中继并资助非审查中继……

但最近，构建者审查问题变得更加令人担忧。 我们将无法通过社会共识阻止构建者审查，因为构建者受到的激励非常不同。 本文的目标之一是传播对构建者审查的认识。 为了有效地做到这一点，我们需要知道我们正在处理什么。

感谢像 Toni Wahrstätter 和 Justin Drake 这样的以太坊研究人员的出色贡献，我们可以通过简单地访问几个网站来监控构建者审查。

向我展示数据

你要求的。

Censorship.pics 作者：Toni

Ultrasound 中继统计，由 Ultrasound.money 团队

请提供一些数字……

我们最关心的数字（对于本文而言）是构建者审查主导地位百分比。 在撰写本文时，大约40-60%。

对交易的影响

根据 Ultra Sound Relay，被审查的交易（特别是 OFAC 制裁的交易）平均需要大约 67 秒才能被纳入——比正常交易慢 6 倍。

我认为，衡量网络抗审查性的最佳方法是被审查交易平均纳入所需的时间：

来自 Metrika 的一篇精彩 文章：

你可能会问“那又怎样？” 如果被审查的交易需要几秒钟才能被纳入，那又有什么大惊小怪的？ 重要的是要认识到，除了社会共识和以太坊文化之外，没有任何东西可以阻止审查率显着提高。 由于以太坊的核心价值主张是可信的中立性，因此社会共识的保证力度不够。

构建者怎么说？

我就构建者审查问题采访了构建者。 所有回复都将保持匿名，以保护所涉及的构建者。

非审查构建者注意到他们如何处理审查中继：

当 mempool 中的交易与 OFAC 列表上的 [地址] 交互并且是下一个区块的候选者时，我们构建两个区块版本：一个包含这些交易，另一个不包含。 然后，我们会将两者分别提交给审查和非审查中继。

当被问及构建者可能审查的原因时，回复在意料之中：法律合规问题。

构建者可能会因重大风险（例如法律后果）而进行审查，这些风险可能从巨额罚款到监禁不等。

构建者还指出，构建者进行审查可能还有其他原因：

垂直整合的构建者（也是搜索者）可能会审查竞争对手的交易以获得优势。

为了在未来的区块中最大化利润（例如，延迟预言机更新，以最大化利润的方式组合可能相互交互的交易）。

当被问及可能的解决方案以及将抗审查性纳入以太坊的潜力时，构建者意识到了其中的权衡：

我认为，协议级别的抗审查性是一把双刃剑。 虽然它可以为具有严格法规的司法管辖区的节点运营商和区块构建者提供合理的推诿，但如果监管机构划清界限，它也可能会冒着推动实体放弃参与的风险。

解决方案：包含列表

一切希望并未破灭！ 大胆的研究人员已经设计出解决构建者审查问题的机制。 我们称这些为：“包含列表”。

包含列表也称为：

• ILs
• crLists（CR 是抗审查性）
• 转发包含列表
• 真棒😉

总结一下设计目标：

我们希望做到让提议者能够通过强制包含某些交易来对抗审查，但我们不想以带宽密集的方式（或）通过要求他们牺牲 MEV 来对利他主义的提议者不利…… — PBS 抗审查性 替代方案 - Francesco

简单来说：我们的目标是将审查能力（以及不审查的责任）转移回提议者，同时仍然限制提议者的审查能力。

包含列表的基本思想很简单。 包含列表是提议者创建的必须包含在相应区块中的交易列表。 如果未包含这些交易，则该区块将无效。

这就是你理解包含列表如何具有抗审查性所需要了解的全部内容。 我们将在以下各节中探讨更多细节：

包含列表如何有效地防止构建者审查？

如上所述，当今 PBS 的根本问题是利他主义的成本很高。 有了包含列表，任何与提议者偏好不一致的区块都将无效。

我们不是在防止构建者审查，而是在删除构建者的选择。 如果构建者想要审查交易，他们根本无法构建有效的区块。 如果提议者生成有意义的包含列表，审查构建者可能会被迫退出市场。 我们正在_通过_使利他主义成本低廉（非常低廉，但不一定免费）来解决淘汰问题。

包含列表如何也限制提议者审查？

Vitalik 写道：

PBS 的全部意义在于它不需要提议者老练。 我们不希望创建一个重新引入提议者老练的好处的机制，从而激励提议者进入更多的协议外拍卖关系或加入矿池。 — 研究状态 - Vitalik Buterin

包含列表的一个优雅特性是，它们对于提议者来说实现起来非常简单。 通过简单地包含任何在 mempool 中等待时间超过几个 slot 的有效交易，提议者可以以最小的额外成本显着提高以太坊的抗审查性。 重要的是要注意，提议者不必在某些类型的交易和其他类型的交易之间进行选择。

实际上，这意味着提议者可以包含受害者交易，而无需花费任何资源来尝试检测哪些交易可能被审查。 尽管提议者不能可信地声称他们不知道他们在包含列表中包含哪些交易，但选择的成本并不高。

至此，一位精明的读者可能会想知道，如果构建者拒绝构建他们的区块，提议者为何要在他们的包含列表中包含被审查的交易。 通过创建 IL，提议者有效地限制了他们区块的构建者市场。 这就是为什么研究人员发明了应用于下一个区块的提议者的“转发包含列表”。 指当前区块的包含列表称为“即时包含列表。”

在最近一篇关于包含列表的文章中，研究人员提出了以下属性：

属性 1：转发包含列表提高了链的抗审查性 (CR)，而即时包含列表则不然。

论点如下。 即时 IL 由诚实的提议者制作，但它们不会提高抗审查性，因为诚实的提议者无论如何都不会连接到审查构建者。 贪婪的提议者不会制作即时 IL，因为这会“关闭”他们连接的审查构建者。 审查提议者也不会为自己制作即时 IL，因此审查量与没有即时 IL 的情况相同。

另一方面，贪婪的提议者不会为自己制作即时 IL，而是为其他人制作转发 IL。 此列表可能适用于诚实的提议者，对于他们来说，该列表是“冗余的”：诚实的提议者无论如何都不会连接到审查构建者。 CR 的增加来自诚实或贪婪的提议者为其他贪婪的提议者制作列表。 这些受到列表约束的提议者，在连接到所有构建者时，将不再收到审查构建者的出价，因此 CR 得到了提高。

— 包含列表的乐趣 - Barnabé Monnot

现在，转发包含列表很棒，但我们可以做得更好…… 我将让 Toni Wahrstätter 解释：

作为回顾。 让提议者为自己的区块设置 IL 意义不大，而且完全依赖于利他主义将审查交易纳入自己的区块中。

拥有转发 IL 是有意义的，允许当前提议者约束下一个提议者。 这意味着当前提议者可以创建 IL，当前提议者本身或下一个提议者都必须满足该 IL。

一个 slot 转发 IL 的问题在于，拥有多个验证器的各方有经济动机不约束下一个提议者， 如果下一个提议者由同一实体控制。 — 累积、非过期的包含列表 - Toni Wahrstätter

解决方案？ 允许包含列表为交易指定区块截止时间，以便它们可以包含在下一个 n slot 中。 有了这一点，提议者就不会冒险限制自己。 关于具体实施细节的更多研究正在进行中。

临时解决方案

在以太坊推出完全成熟的转发累积非过期协议强制包含列表（whew）之前，这个问题仍然需要解决。

中继构建的包含列表

中继构建的包含列表 (abbr RCILs) 是一种新颖的包含列表模型，可在当前的 mev-boost 系统中运行，并且只需进行最少的修改。

我们已经让中继充当受信任的第三方，那么为什么不利用这一点并要求中继代表提议者构建包含列表？ 提议者可以在他们的验证器注册中注册中继构建的包含列表，这将触发中继强制执行该列表。 — 抵抗~并非~徒劳； mev-boost 中的 CR

部分区块中继

增加当前 mev-boost 系统抗审查性的一种选择是 来自 EigenLayer 的 mev-boost+。

在部分区块中继中，提议者拍卖区块顶部 (ToB)，同时为自己保留区块其余部分 (RoB)。 — EigenLayer 研究

EigenLayer 提出的部分区块中继系统非常复杂，如果你想了解更多信息，请阅读 这篇文章。

现在进行审查的构建者是否会在包含列表到位后进行审查？

这是包含列表研究中的一个开放性问题。 如果构建者现在进行审查，他们会对协议强制执行的包含列表感到足够满意以停止审查吗？ 他们会怎么做？

构建者会提前看到包含列表，并且构建者可以拒绝构建包含他们不想构建的包含列表的区块。 这会立即激励提议者拥有空的包含列表，以最大化构建者为其构建区块的机会。 — Vitalik Buterin

目前，研究人员假设以下情况：

对于存在非空包含列表的 slot，审查构建者不会构建包含列表中交易的区块。 — 包含列表的乐趣 - barnabe

构建者对此有何看法？

一位关于抗审查性的构建者说：

我认为，协议强制执行的抗审查性更有可能为节点运营商提供理由，说明他们无法控制交易包含，而不会推动监管机构强制执行彻底的禁令。

构建者指出：

通过正确实施的 IL，构建者的审查应该会大大减少。

当被问及 IL 实施后会有多少百分比的构建者主导地位进行审查时，乐观情绪显而易见：

很难估计，但我认为在 IL 实施后，继续审查的比例将低于 5%。

其他构建者则更加怀疑：

我看到的一种未来是，今天进行审查的构建者不会竞标具有 IL 的区块，这些 IL 具有他们通常会审查的 tx。

构建者指出，对其区块构建算法的性能影响可以忽略不计。 对于这些构建者的开发者来说，重要的是构建者声称：

对我们的区块构建算法所需的修改将是最小的。

一位构建者提出了一个关于私有订单流的好观点：

[转发包含列表] 在公共mempool上运行，而公共mempool正在枯竭。 大约 10-15% 的 tx 甚至没有在 mempool 中发生。 Mempool 存在缺陷，这已经进行了详细讨论（我怀疑其作为公共池的长期未来）。

这目前并不相关，因为任何受制裁的交易都在 mempool 中，但这在遥远的将来可能是一个问题。

结论

审查不好。 构建者审查不好。 包含列表好。 包含列表慢？ 是的，但没关系。

在完成所有这些工作后，我们会得到什么？ 我们得到了一条链，其中区块生产仍然是中心化的，但区块验证是无需信任且高度去中心化的，并且专门的反审查魔法可以防止区块生产者进行审查。 — 终局 - Vitalik Buterin

参考资料 + 延伸阅读

• 以太坊
• 区块链

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