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

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

概述

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

我们将详细说明中继包含列表如何在保持验证者风险回报平衡的同时，提高以太坊的抗审查性。然后，我们提出了一种构建中继包含列表的规则，该规则既高效又具有应对异常值的能力，并且其执行程序与现有的区块验证无缝集成。本文档最后展望了有希望的未来方向。

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

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

分发和推广

支持中继包含列表的中继，默认情况下将为他们交付的所有区块生成并执行一个包含列表，该列表来自内存池中待处理的交易。希望选择退出的验证者可以通过中继注册 API 显式地表明这一偏好，作为一个额外的偏好字段。

中继包含列表使验证者能够立即提高以太坊的抗审查性，而不会产生任何额外的风险或信任假设，因为包含列表的编译和执行被委派给中继，而验证者在签署区块头时对其内容一无所知。另一种链下方法是 IL-Boost，它委托区块构建，但保留了提议者级别的包含列表构建。

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

总的来说，该设计不对验证者施加额外的要求，并允许他们提高以太坊的抗审查性，而无需在风险/回报曲线上进行转移。因此，该系统对所有参与者都具有可访问性和吸引力，从单人质押者到大型节点运营商。

包含列表的生成和通信

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

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

1. 标准化等待时间和优先级费用：

对于内存池中的每个交易 t，计算：

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

其中：

• w(t) 是交易 t 在内存池中的等待时间。
• f(t) 是交易 t 的优先级费用。
• \tilde{w} 和 \tilde{f} 分别是内存池中所有待处理交易的等待时间和优先级费用的中位数。
  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) 规范，方法是包含排名最高的交易，直到没有足够的边际空间用于进一步包含。

通过中位数进行标准化可以避免由于经济原因（即由于付款不足）而未被包含的交易造成的偏差。该规则在计算上是高效的，因为对于典型的内存池大小，可以使用标准算法快速执行中位数计算和交易排序。试图通过发送低费用交易来干扰中位数的攻击者只会增加其他交易的优先级分数；达到包含的更简单、更便宜的方法就是支付更多。

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

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

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

区块验证和执行

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

1. 交易包含检查

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

2. 模拟交易验证

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

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

执行和处罚

根据 FOCIL 标准，符合包含列表被视为有效性条件。不符合会导致至少不被接受，并且对于乐观的构建者，可能会强制执行处罚。

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

未来方向

Blob 类型交易的包含列表

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

更大的包含列表

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

多中继包含列表

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

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

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

链接

• Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal （强制分叉选择的包含列表（FOCIL）：一个简单的基于委员会的包含列表提议）

• EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL) （EIP-7805：强制分叉选择的包含列表（FOCIL））

• Uncrowdable Inclusion Lists: The Tension between Chain Neutrality, Preconfirmations and Proposer Commitments (不可拥堵的包含列表：链中立性、提前确认和提议者承诺之间的张力)

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

• Block Constraints Sharing: Multi-Relay Inclusion Lists & beyond (区块约束共享：多中继包含列表及其他)

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