中继包含列表 - 权益证明/区块提议者

由 Michael 和 Kubi（Gattaca）共同撰写。特别感谢 Thomas, Julian, Toni, Ladi, Justin, Auston 和 Max 的反馈和建议。反馈不一定代表认可。

概述

本文档介绍了中继包含列表（relay inclusion lists，rILs），这是一种无需引入协议变更、新的信任假设或显著的技术复杂性即可立即提高 Ethereum 审查阻力的方案。该设计旨在作为非审查中继的新默认功能，并提供退出选项以适应验证者的偏好。

我们首先详细说明中继包含列表如何在保持验证者风险回报平衡的同时提高 Ethereum 的审查阻力。然后，我们提出一个用于构建中继包含列表的规则，该规则高效且能抵抗异常值，同时执行程序与现有的区块验证无缝集成。文档最后展望了有希望的未来方向。

总的来说，该文档详细描述了在中继中生成、验证和执行包含的确切程序。它反映了 EIP-7805 (FOCIL) 规范，以确保协议兼容性和运营完整性，从而以一种低风险的方式为区块生产系统在未来协议内实现包含列表做好准备。

[\\ 874×701 38.8 KB](https://ethresear.ch/uploads/default/original/3X/e/0/e048a3c8ab4d33140a0e4bc016754381b135c70c.png "")

分发和推出

支持中继包含列表的中继默认会为它们传递的所有区块生成和执行一个来自 mempool 中待处理交易的包含列表。希望退出的验证者可以通过中继注册 API，以一个额外的偏好字段明确表明他们的偏好。

中继包含列表使验证者能够立即提高 Ethereum 的审查阻力，而无需承担任何额外的风险或信任假设，因为包含列表的编译和执行被委托给中继，验证者在签署区块头时对其内容保持不可见。另一种链外方法是 IL-Boost，它委托区块构建，但在提议者层面保留了包含列表的构建。

我们注意到该系统与验证者的经济激励一致。在实践中，它将反映为更完整的区块，这会因为其更大的数据足迹而带来轻微的延迟权衡。如果所有中继都采用该设计，这种权衡将在相对基础上最小化，因为竞价曲线将发生变化以适应这种边际和可预测的延迟开销；换句话说，最佳竞价会更早提交。如果某些中继不采用该设计，验证者将通过标准区块拍卖获得保障，这将继续产生最高收益的区块。

总的来说，该设计不对验证者施加额外的要求，并允许他们在不改变风险/回报曲线的情况下提高 Ethereum 的审查阻力。因此，该系统对所有参与者都具有可访问性和吸引力，从单人质押者到大型节点运营商。

包含列表的生成和通信

中继通过应用确定性的包含规则，独立地从 mempool 交易中生成包含列表。该规则的核心目的是通过仅观察 mempool 来最大化包含的可预测性；具体来说，是待处理交易的到达时间和优先费用。

我们提出了一个初步的、简单的两步规则：

1. 归一化等待时间和优先费用：

对于mempool中的每笔交易t，计算：

S\_w(t) = \\frac{w(t)}{\\tilde{w}}, \\quad S\_f(t) = \\frac{f(t)}{\\tilde{f}}

其中：

• w(t) 是交易 t 在mempool中的等待时间。
• f(t) 是交易 t 的优先费用。
• \tilde{w} and \tilde{f} 分别是mempool中所有待处理交易的等待时间和优先费用的中位数。
  2. 计算总分并根据交易大小进行调整：

每笔交易最初被分配一个总分：

S(t) = S\_w(t) + S\_f(t)

然后根据大小调整分数 S(t)，以便为大型交易提供更高的边际定价：

D(t) = \\frac{S(t)}{size(t)}

其中 size(t) 是以字节为单位衡量的交易大小。然后按照 D(t) 的降序对交易进行排序。

中继然后构建一个最大大小为 8 千字节的包含列表，以符合 EIP-7805 (FOCIL) 规范，方法是包括排名最高的交易，直到没有足够的边际空间用于进一步包含。

通过中位数进行归一化可以避免因经济原因（即由于支付不足）而未被包含的交易产生的偏差。该规则在计算上是有效的，因为使用标准算法可以快速地为典型的 mempool 大小执行中位数计算和交易排序。试图通过垃圾邮件发送低费用交易来干扰中位数的攻击者只会增加其他交易的优先级分数；一种更简单、更便宜的实现包含的方法就是支付更多。

按密度分数对交易进行排序对每个区块空间消耗单元施加了更高的边际价格。这种基于市场的方法鼓励包含许多较小的交易，从而最大程度地增加尽可能多的发起者的参与。消耗更多区块空间的大型交易仍然可以通过相应地提高其优先费用来快速包含。

理想情况下，在所有中继中统一应用包含规则；实际上，最重要的是每个中继都将其包含列表填充到最大大小（如果在 mempool 中有足够的交易），以排除优化延迟（即精简区块）的倾斜的 IL 实现。中继行为通过提议者强制执行，提议者可以选择退出优化审查阻力以外因素的中继。通过考虑优先费用，包含规则在经济上是理性的并且激励对齐。

包含列表在每个Slot开始之前计算，并且中继公开一个 HTTP API 端点，构建者可以使用该端点来获取已完成的包含列表。对构建者没有施加排序约束；包含列表上的交易可以以最有效的方式排序到区块中。

区块验证和执行

区块有效性是根据 FOCIL 标准强制执行的；具体来说，只有当满足以下条件时，提议给中继的区块才是有效的：

1. 交易包含检查

   • 中继提供的 IL 中列出的每笔交易要么：
     • 显式包含在构建者交付的区块中。
     • 在根据区块的最终后状态执行后，可验证地无效。

2. 模拟交易验证

   • 中继模拟针对区块的后状态执行每个未包含在区块中的 IL 交易。
     • 如果区块省略了任何包含列表交易，而该交易在根据其最终后状态进行验证时，将通过所有预执行有效性检查——正确的签名、链 ID、nonce、足够的余额和内在 gas，则该区块无效。
     • 由于inherent无效（例如，nonce不匹配、余额不足）而导致模拟失败的交易不会使区块无效。
   • IL 的模拟和验证是在区块验证的模拟部分完成的。

这种方法使 FOCIL 标准适应当前的链外 PBS 管道，而无需引入额外的阶段；区块模拟只是为每个未包含在区块中的 IL 交易略微扩展了一笔交易。对于跳过可信构建者的模拟阶段的乐观中继，不会产生任何开销。

执行和处罚

根据 FOCIL 标准，符合包含列表被视为有效性条件。不符合的最低结果是不被接受，对于乐观的构建者，可能会强制执行处罚。

我们建议对不符合的乐观构建者执行的处罚应将 IL 反映为一个不可分割的有效性条件，并导致没收构建者抵押品中的区块价值。中继可以选择暂时降级不符合的构建者，直到追踪到错误为止，以避免过度的抵押品燃烧。

未来方向

Blob 类型交易的包含列表

将来，该设计可能会扩展到包括 blob。这将扩大当前设计的审查阻力，同时改善 L2 的及时数据可用性。

更大的包含列表

中继包含列表可以大于以提议者为中心的包含列表，因为它们不受验证者带宽约束的直接限制。当前的设计反映了 FOCIL 大小调整，以确保具有中继 IL 的区块在 PBS 拍卖中具有竞争力的价格，并且将来可以扩展以适应更大的总大小。

多中继包含列表

在当前设计下，每个中继都维护自己的包含列表。寻求为其区块保留最大可选性的构建者可以选择将不同的区块发送到每个中继，以反映中继提供的 IL。

将来，通过从多个包含列表的交集中形成包含列表，可以实现更强大的审查保证。这通过强制统一应用包含规则来确保中继之间的公平竞争，并且可以很容易地通过用于编译包含列表的交易排名来计算。通过消除构建者计算每个中继的定制区块或包含包含列表的并集的需求，这也将减少构建者的冗余。

在这种情况下，每个中继都可以 gossip 一个扩展列表，然后通过获取交集将其确定性地缩减为统一的标准大小列表。实际上，这可以通过使用简单的 gossip 协议升级中继来实现。

链接

• 分叉选择强制包含列表 (FOCIL)：一个简单的基于委员会的包含列表提案

• EIP-7805：分叉选择强制包含列表 (FOCIL)

• 不可拥堵的包含列表：链中立性、预确认和提议者承诺之间的紧张关系

• il-boost/README.md at main · eserilev/il-boost · GitHub

• 区块约束共享：多中继包含列表及其他

• 原文链接： ethresear.ch/t/relay-inc...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～