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

允许验证者委员会强制在每个区块中包含一组交易

摘要

FOCIL 实现了一种强大的机制，通过保证及时的交易包含来维护 Ethereum 的抗审查性。

FOCIL (Fork-choice enforced Inclusion Lists - 分叉选择强制包含列表) 构建过程简单，分为以下几个步骤：

• 在每个 slot 中，选择一组验证者作为包含列表 (IL) 委员会成员。每个成员根据他们对 mempool 的主观看法构建和传播一个 IL。
• 下一个 slot 的提议者和所有证明者监视、存储和转发可用的 IL。
• 提议者（或者，如果区块不是由提议者在本地构建的，则由构建者）在其区块中包含来自所有收集到的 IL 的交易。然后，提议者将包含 IL 交易的区块广播到网络的其余部分。
• 证明者只有在提议者的区块包含来自所有存储的 IL 的交易时才投票。

动机

为了保护 Ethereum 验证者集合免受中心化力量的影响，构建区块的权利已被拍卖给称为 构建者 的专业实体。这导致少数复杂的构建者主导区块生产，导致网络抗审查性的恶化。为了解决这个问题，研究的重点是通过允许验证者对构建者施加约束，来改进 Ethereum 的交易包含保证。这是通过经由 IL 强制包含交易到区块中来实现的。

高级概述

FOCIL 是一种基于委员会的、分叉选择强制的包含列表 (IL) 设计，它改进了先前的 IL 机制和区块协同创建提案。它解决了与贿赂/敲诈攻击、IL 伪造、账户抽象 (AA) 和交易失效相关的问题。

角色和参与者

本节概述了 FOCIL 的工作流程，详细说明了各个参与者的角色和职责：IL 委员会成员、验证者、构建者、提议者和证明者。

IL 委员会成员

• Slot N，t=0 到 8s： IL 委员会成员通过包含公共 mempool 中待处理的交易来构建他们的 IL，并在处理完 slot N 的区块并确认其为头部后，通过 P2P 网络广播它们。如果在 t=7s 之前未收到任何区块，他们应该运行 get_head，并基于节点的本地头部构建和发布他们的 IL。

IL 委员会成员可以遵循不同的策略来构建他们的 IL，如 IL 构建 中所述。

验证者

• Slot N，t=0s 到 9s：验证者从 P2P 网络接收 IL，并存储（1）所有通过 CL P2P 验证规则的新 IL，以及（2）委员会成员 IL 伪造的任何证据（即，如果从同一委员会成员收到多个 IL）。

• Slot N，t=9s 到 Slot N+1，t=4s：在 t=9s 的视图冻结截止时间之后，验证者：

  1. 不存储截止时间后收到的新 IL。
  2. 继续按照 CL P2P 验证规则将 IL 转发给对等节点。
  3. 记录发生在视图冻结截止时间之后的任何 IL 伪造证据。

在 Slot N+1，t=4s 的证明截止时间之后，验证者忽略任何与前一个 slot 的 IL 委员会相关的新 IL，并停止记录前一个 slot 的 IL 的伪造证据。

构建者

• Slot N，t=0s 到 11s：构建者（即，执行本地区块构建的提议者或外部构建者）从 P2P 网络接收 IL，转发和缓存那些通过 CL P2P 验证规则的 IL。可选地，可以添加一个 RPC 端点，以允许构建者从其对等节点请求缺少的 IL（例如，在 t=10s 时按委员会索引）。

• Slot N，t=11s： 构建者冻结其 IL 视图，并要求 EL 通过添加其视图中的交易来更新其执行 payload（确切的时间将在运行一些测试/基准测试后确定）。

提议者

• Slot N+1，t=0s： 提议者通过 P2P 网络广播其区块，其中包含满足 IL 交易的最新执行 payload。

证明者

• Slot N+1，t=4s： 证明者监视 P2P 网络以查找提议者的区块。检测到该区块后，他们验证所有来自其存储的 IL 的交易是否都包含在提议者的执行 payload 中，除非发送者伪造了 IL。基于他们在前一个 slot 的 t=9s 时的 IL 冻结视图，证明者检查执行 payload 是否满足 IL 条件。这可以通过确认所有交易都存在，或者通过确定任何缺少的交易在附加到 payload 末尾时是否无效来完成。在这种情况下，证明者使用 EL 执行 nonce 和余额检查，以验证缺少的交易，并检查区块中是否有足够的空间来包含交易。

CL P2P 验证规则

当验证者从 P2P 网络接收 IL 时，他们在转发或缓存它们之前执行一系列验证检查。这些规则通过（1）限制 IL 的字节大小和（2）将 IL 提议限制在由 IL 委员会成员组成的小委员会中，从而严格限制带宽（传播 IL 所消耗的主要资源）来防止拒绝服务攻击。其他相关资源的消耗（例如验证时间）是最小的，因为在 IL 传播上执行的唯一重要的检查是签名验证。在此阶段，没有对 IL 中交易进行 EL 验证。这意味着允许 IL 包含任何交易（有效或无效），因为验证者不执行 EL 端的有效性检查。此设计选择旨在避免额外的计算开销。

1. IL 的 slot 与当前或前一个 slot 匹配。
2. IL 中引用的 IL 委员会的 root 与其 slot 的预期 IL 委员会 root 匹配。
3. 从此 IL 委员会成员收到两个或更少的 IL（请参阅下面的 IL 伪造部分）。
4. IL 由验证者正确签名。
5. 验证者是 IL 委员会的成员。
6. IL 的大小不超过允许的最大大小（例如，MAX_BYTES_PER_INCLUSION_LIST = 8 KiB）。

规范

执行层

在执行层，为新的 payload 引入了额外的检查。在执行完 payload 中的所有交易后，我们检查 IL 中的任何尚未存在于 payload 中的交易是否可以有效包含（即，通过 nonce 和余额检查）。如果任何交易都是这种情况，则会向 CL 返回错误。虽然该区块是有效的，但 CL 不会证明它。

令 B 表示当前区块。 令 S 表示执行 B 中最后一笔交易后的执行状态。 令 gas_left 是执行 B 后剩余的 gas。

对于 IL 中的每笔交易 T，执行以下操作：

1. 检查 T 是否存在于 B 中。如果 T 存在，则跳转到下一笔交易，否则继续下一步。

2. 检查 B 是否有足够的剩余 gas 来执行 T。如果 T.gas > gas_left，则跳转到下一笔交易，否则继续下一步。

3. 通过检查 T.origin 的 nonce 和余额来针对 S 验证 T。

   • 如果 T 无效，则继续到下一笔交易。

   • 如果 T 有效，则终止流程并返回 INVALID_INCLUSION_LIST 错误。

Engine API 变更

我们对 Engine API 进行了以下更改：

• 添加 engine_getInclusionListV1 端点以从 ExecutionEngine 检索 IL。
• 添加 engine_updatePayloadWithInclusionListV1 端点，以使用应用于构建区块的 IL 更新 payload。 这将正在进行的 payload 构建过程的 8 字节 payloadId 以及 IL 本身作为参数。
• 修改 engine_newPayload 端点以包含 IL 委员会成员确定的 IL 中的交易参数。如果 IL 不满足，则必须返回 INVALID_INCLUSION_LIST 错误。

IL 构建

构建 IL 的规则由实施者酌情决定。例如，他们可以通过各种方式从公共 mempool 中选择交易，例如随机选择、按优先费用选择或根据它们已挂起的时间选择。IL 的最大大小为 MAX_BYTES_PER_INCLUSION_LIST = 8 KiB，适用于所有 RLP 编码的交易。

共识层

完整的共识更改可以在以下 GitHub 存储库中找到。它们分为：

• 信标链 更改。
• 分叉选择 更改。
• P2P 更改。
• 诚实验证者指南 更改。

信标链更改

预设

新容器

class InclusionList(Container):
    slot: Slot
    validator_index: ValidatorIndex
    inclusion_list_committee_root: Root
    transactions: List[Transaction, MAX_TRANSACTIONS_PER_PAYLOAD]

class SignedInclusionList(Container):
    message: InclusionList
    signature: BLSSignature

分叉选择更改

• 存储在视图冻结截止时间之前通过 gossip 观察到的 IL。
• 如果从同一个 IL 委员会成员观察到多个 IL，则将该委员会成员标记为伪造者，并忽略来自他们的任何进一步的 IL。
• 仅当来自非伪造者的所有存储的 IL 满足 IL 条件时，才证明来自当前 slot 的信标区块。

P2P 更改

• 用于广播 SignedInclusionList 对象的新全局主题。
• 用于基于 IL 委员会索引请求 SignedInclusionList 的新 RPC 主题。

原理

核心属性

• 基于委员会：FOCIL 依赖于由多个验证者组成的委员会，而不是单个提议者，来构建和广播 IL。这种方法大大减少了贿赂和敲诈勒索攻击的范围，并加强了抗审查性。
• 分叉选择强制：FOCIL 将强制包含机制纳入分叉选择规则（共识过程的一个组成部分），从而防止任何参与者绕过该系统。证明者仅对包含来自 IL 委员会提供的一组 IL 的交易，并且满足 IL 约束的区块进行投票。任何未能满足这些标准的区块将不会被证明者投票，因此不能成为规范的。
• Same-slot：由于 FOCIL 在 slot N 期间与 slot N+1 的区块构建过程并行运行，因此对 slot N+1 的 block B 施加的约束可以包括在 slot N 期间提交的交易。这代表了对前向 IL 设计（如 EIP-7547）的严格改进，其中前向属性引入了 1-slot 的延迟。
• 条件包含：FOCIL 采用条件包含，接受可能缺少 IL 中某些交易的区块，如果他们无法将交易附加到区块末尾或如果它们已满。
• Anywhere-in-block：FOCIL 对 IL 中的交易在区块中的位置没有意见。这减少了复杂攻击者使用侧信道绕过该机制的动机。结合条件包含，这种灵活性降低了链下市场出现的吸引力。
• 无激励机制：FOCIL 没有为参与该机制的 IL 委员会成员提供明确的奖励。我们认为，为 FOCIL 实施交易费用系统所增加的复杂性是不合理的。相反，我们依赖利他行为，因为 FOCIL 仅需要 IL 委员会成员中的 1-out-of-N 诚实假设即可使该机制按预期工作。

向后兼容性

此 EIP 引入了对共识层区块验证规则集的不向后兼容的更改，并且必须伴随硬分叉。这些更改不会破坏与当前用户活动和体验相关的任何内容。

安全注意事项

共识活性

如果没有首先收到在 slot N 期间广播的 IL，则 slot N+1 的构建者无法构建规范区块。这意味着构建者（包括提议者在本地构建其区块的情况）必须与 IL 委员会成员保持良好的连接，以确保及时访问这些包含列表。此外，视图冻结截止时间（slot N 的 t=9s）与提议者必须将 block B 广播到网络其余部分的时间之间必须有足够的时间。 此缓冲区允许构建者收集所有可用的 IL 并相应地更新 block B 的执行 payload。

IL 伪造

为了减轻 IL 伪造，FOCIL 引入了一项新的 P2P 网络规则，该规则允许每个 IL 委员会成员转发最多两个 IL。如果提议者或证明者检测到同一 IL 委员会成员发送的两个不同的 IL，他们应忽略来自该成员的所有 IL。在最坏的情况下，IL gossip 子网的带宽最多可以翻倍。

Payload 构建

构建者负责构建执行 payload，必须确保满足 IL。一种天真的方法是按照构建者希望的任何方式构建初始 payload，然后执行以下算法：

1. 依次检查 post-state 中任何尚未包含的 IL tx 的有效性。如果没有找到，则 payload 构建结束。
2. 如果找到一个，将其附加到 payload 的末尾并更新 post-state。返回步骤 1。

这种简单方法的问题在于，给定一组 n 个 IL 交易，最终可能需要执行 n + (n-1) + (n-2) + ... 次有效性检查，即 O(n^2)。 例如，第n 个 tx 可能是有效的，而所有其他 tx 都无效，但其执行将余额发送给 (n-1) 个 tx 的发送者，使其有效，然后 (n-1) 个将余额发送给 (n-2) 个 tx 的发送者，依此类推。

为了有效地确保所有有效的 IL tx 都已包含在 payload 中，构建者可以采用一种简单的策略：在构建 payload 之前，他们存储所有参与 IL 交易的外部拥有的帐户 (EOA) 的 nonce 和 balance。当它们构建 payload 时，构建者会跟踪这些 EOA，维护和更新每个 EOA 的 nonce 和 balance（无论何时发生更改）——特别是当 nonce 递增（表示已执行来自该 EOA 的交易）时或当 balance 在没有 nonce 递增的情况下发生更改时（例如，在账户抽象 (AA) 交易与该 EOA 交互之后）。

这种跟踪允许构建者实时验证 IL 交易的有效性，使他们能够顺序添加交易，直到所有剩余的交易都无效（因为关联的 EOA 的 nonce 或余额没有更改）或由于 gas 不足而无法包含。 这种方法通过仅跟踪与 IL tx 的有效性相关的状态更改来最大限度地减少开销。

版权

版权和相关权利已通过 CC0 放弃。

Citation

Please cite this document as:

Thomas Thiery (@soispoke) <thomas.thiery@ethereum.org>, Francesco D'Amato <francesco.damato@ethereum.org>, Julian Ma <julian.ma@ethereum.org>, Barnabé Monnot <barnabe.monnot@ethereum.org>, Terence Tsao <ttsao@offchainlabs.com>, Jacob Kaufmann <jacob.kaufmann@ethereum.org>, Jihoon Song <jihoonsong.dev@gmail.com>, "EIP-7805: 分叉选择强制包含列表 (FOCIL) [DRAFT]," Ethereum Improvement Proposals, no. 7805, November 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7805.