EIP-7547: 包含列表

添加一个包含列表机制，以允许强制交易包含。

摘要

抗审查性是区块链的核心价值主张。包含列表旨在提供一种机制来提高以太坊的抗审查性，允许提议者指定一组必须及时包含的交易，以便后续区块被认为是有效的。

动机

自从合并以来，验证者已经开始将几乎所有的区块生产外包给一组专业的构建者，他们竞争以提取最多的 MEV（这通常被称为提议者-构建者分离）。截至 2023 年 10 月，近 95% 的区块是由构建者而不是提议者构建的。虽然所有提议者都可以通过 mev-boost 生态系统访问有竞争力的区块，但外部构建区块的一个主要缺点是构建者最终决定包含或排除哪些交易。在没有任何强制交易包含机制的情况下，提议者面临着一个艰难的选择：他们要么对包含的交易没有任何发言权，要么在本地构建区块（因此对交易有最终决定权）并牺牲一些 MEV 奖励。

包含列表旨在允许提议者保留一些权力，提供一种强制包含交易的机制。最简单的设计是 slot N 提议者指定一个必须包含在其 slot 产生的区块中的交易列表。然而，这在激励上是不相容的，因为如果提议者对其行为设置了一些约束，构建者可能会选择放弃构建区块。这就引出了“前向”包含列表的想法，其中由 slot N 提议者指定的交易在 slot N+1 区块中强制执行。前向包含列表的简单实现提出了一个潜在的暴露免费数据可用性的问题，这可能被利用来膨胀链的大小而不支付必要的 gas 成本。免费数据可用性问题通过对 nonce 重用的观察以及允许为每个 slot 指定多个包含列表来解决。在解决了激励兼容性和免费数据可用性问题后，我们可以更安全地进行包含列表的实现。

规范

常量

引用对象

class InclusionListSummaryEntry(Container):
    address: ExecutionAddress
    gas_limit: uint64

class InclusionListSummary(Container)
    slot: Slot
    proposer_index: ValidatorIndex
    summary: List[InclusionListSummaryEntry, MAX_TRANSACTIONS_PER_INCLUSION_LIST]

class SignedInclusionListSummary(Container):
    message: InclusionListSummary
    signature: BLSSignature

class InclusionList(Container)
    summary: SignedInclusionListSummary
    transactions: List[Transaction, MAX_TRANSACTIONS_PER_INCLUSION_LIST]

class ExecutionPayload(Container):
    ...
    inclusion_list_summary: List[InclusionListSummaryEntry, MAX_TRANSACTIONS_PER_INCLUSION_LIST]
    inclusion_list_exclusions: List[uint64, MAX_TRANSACTIONS_PER_INCLUSION_LIST]

class ExecutionPayloadHeader(Container):
    ...
    inclusion_list_summary_root: Root
    inclusion_list_exclusions_root: Root

class BeaconBlockBody(Container):
    ...
    inclusion_list_summary: SignedInclusionListSummary

共识层

高级概述

slot N 提议：

• 提议者广播一个签名区块和一个用于 slot N+1 的包含列表（摘要和交易对象）。
• 交易将被包含在 slot N 或 slot N+1 中。
• 摘要包括交易的原始地址和它们各自的 gas 限制。
• 摘要是已签名的，但交易不是。

slot N 验证：

• 验证者只有在看到至少一个该 slot 的包含列表时，才会考虑区块用于验证和分叉选择。
• 如果包含列表交易在 slot N 开始时不可执行，或者交易的 maxFeePerGas 没有比当前 slot 高至少 12.5%（以确保交易在 slot N+1 中有效），他们会认为该区块无效。

slot N+1 验证：

• slot N+1 的提议者构建他们的区块，以及来自 slot N 提议者的签名摘要。
• payload 包括来自 slot N payload 的交易索引列表，这些索引满足签名包含列表摘要中的某个条目。
• 如果满足以下条件，则认为 payload 有效：(a) 满足执行条件，包括满足包含列表摘要并且从执行层的角度来看是可执行的，并且 (b) 满足共识条件，包括先前区块的提议者签名。

具体更改

信标链状态转换规范：

• 新增 inclusion_list 对象： 引入一个新的 inclusion_list 供提议者提交和节点处理。
• 修改 ExecutionPayload 和 ExecutionPayloadHeader 对象： 更新这些对象以满足包含列表要求。
• 修改 BeaconBlockBody： 修改为缓存包含列表摘要。
• 修改 process_execution_payload 函数： 更新此过程以包括对包含列表摘要满足情况的检查。

信标链分叉选择规范：

• 新增 is_inclusion_list_available 检查： 引入一个新的检查以确定包含列表在可见性窗口中是否可用。
• 新增 通知操作： 实现一个新的调用来通知执行层 (EL) 客户端关于一个新的包含列表。如果 EL 客户端认为包含列表无效，则相应的区块被认为是无效的。

信标链 P2P 规范：

• 新增 用于包含列表的 gossipnet 和验证规则： 定义新的规则来处理 gossip 网络和验证中的包含列表。
• 新增 用于包含列表的 RPC 请求和响应网络： 建立一个新的网络来发送和接收包含列表。

验证者规范：

• 新增 inclusion_list 的职责： 提议者准备并签署包含列表。
• 修改 BeaconBlockBody 的职责： 更新准备信标区块体的职责以包括 inclusion_list_summary。

执行层

• 新增 get_inclusion_list： 引入一个新的函数供提议者检索包含列表。
• 新增 new_inclusion_list： 定义一个新的函数供节点验证包含列表的执行侧。
• 修改 forkchoice_updated： 使用 payload_attribute 更新该函数，以将包含列表摘要作为属性的一部分包含在内。
• 修改 new_payload： 更新该函数，供 EL 客户端验证 payload_transactions 是否满足 payload.inclusion_list_summary 和 payload.inclusion_list_exclusions。
• 新增 验证规则： 基于 Execution-API 规范中引入的更改来实现新的验证规则。

理由

我们考虑了此 EIP 中存在的一些设计决策。

1. ReducedSummary 与 Summary
   • 最初的提案试图通过使用 ReducedSummary 和 Rebuilder 来提高数据效率。这允许重建完整的摘要。
   • 这给规范增加了很多复杂性，因此在这个初始版本中，我们应该考虑只使用常规的 Summary 并将其包含在后续的区块中。
2. Gas 限制与无限制。
   • 一个考虑因素是包含列表是否应该具有 gas 限制或使用区块的 gas 限制。
   • 具有单独的 gas 限制简化了复杂性，但开启了验证者外包其包含列表构建以进行 साइड payment 的可能性（例如，如果一个区块已满，提议者可以拍卖包含列表中的空间，以保证包含在后续区块中）。
   • 或者，包含列表可以成为区块 gas 限制的一部分，只有在区块 gas 限制未满时才满足。但是，这可能导致下一个区块提议者故意填满区块以忽略包含列表的情况，尽管可能会付出浪费 gas 的代价。
3. 包含列表排序。
   • 我们假设包含列表在 slot N 区块的顶部处理。包含列表中的交易针对 slot N 的预状态进行评估，但仅保证包含在 slot N+1 中。
4. 包含列表交易排除。
   • 在 slot N 提出的包含列表交易可以在同一 slot 中得到满足（例如，通过包含在 ExecutionPayload 中）。这是验证者使用 mev-boost 的副作用，因为他们不知道他们提出的区块的内容。
   • 因此，存在一个排除字段，节点查看 payload 的 inclusion_list_exclusion 字段中的每个交易，并确保它与当前包含列表中的交易匹配。当存在匹配时，我们从包含列表摘要中删除该交易。
5. mev-boost 兼容性。
   • mev-boost 没有重大更改。像任何其他硬分叉一样，mev-boost、中继和构建者必须调整他们的信标节点。
   • 构建者必须知道不满足包含列表摘要的执行 payload 将无效。
   • 中继可能具有额外的职责，以在将这些约束传递给验证者进行签名之前验证这些约束。
   • 当收到标头时，验证者可以检查 inclusion_list_summary_root 是否与其本地版本匹配，并在不匹配时跳过构建区块，而是使用本地区块。
6. 使用按范围或按根同步。
   • 为了认为一个区块有效，同步到最新头的节点还必须具有包含列表。
   • 在同步期间无法处理没有包含列表的区块。
   • 为了解决这个问题，有一个名为 MIN_SLOTS_FOR_INCLUSION_LIST_REQUEST 的参数。如果区块的 slot 加上此参数低于当前 slot，节点可以跳过包含列表检查。
   • 这类似于 EIP-4844，其中节点如果超出保留窗口，则跳过 blob 侧车数据可用性检查。

向后兼容性

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

安全考虑

主要潜在问题是围绕包含列表的激励。如果 slot N 提议者构建的包含列表对 slot N+1 提议者的奖励产生负面影响，则 slot N+1 提议者可能会尝试贿赂 slot N 提议者以发布一个空列表。这不是对协议的直接攻击，而是一种利润分享机制，包含列表将不会被使用。似乎无论采用何种抗审查机制，这些承诺游戏都可能被玩弄，但这仍然是一个积极的研究领域。

版权

在 CC0 下放弃版权及相关权利。

Citation

Please cite this document as:

mike (@michaelneuder), Vitalik (@vbuterin), Francesco (@fradamt), Terence (@terencechain), potuz (@potuz), Manav (@manav2401), "EIP-7547: 包含列表 [DRAFT]," Ethereum Improvement Proposals, no. 7547, October 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7547.