# EIP-7805 (FOCIL) > EIP-7805是一项以太坊核心改进提案，旨在通过使用验证者委员会创建强制执行的“包含列表”(ILs)来增强抗审查性…… - Canonical URL: https://iq.wiki/zh/wiki/eip-7805-focil - Categories: Projects & Protocols - Tags: DeFi, Infrastructure - Created: 2026-01-26T01:07:01.019Z - Last updated: 2026-01-26T01:07:01.019Z - Source: IQ.wiki — the world's largest blockchain and crypto encyclopedia (https://iq.wiki) --- **EIP-7805**，正式名称为“分叉选择强制执行的包含列表（FOCIL）”，是一项旨在增强[以太坊](https://iq.wiki/wiki/ethereum)网络抗审查性的核心[以太坊改进提案](https://iq.wiki/wiki/ethereum-improvement-proposal-eip)。[\[1\]](#cite-id-09Nj6uuMGFbQZmB2) [\[2\]](#cite-id-v2A24J6ILU7SqVYt) 该提案在创建时处于“草案”状态，它引入了一种机制，以确保提交到公共内存池的有效交易能够及时包含在链上。它通过创建一个验证者委员会来提议交易的“包含列表”（ILs）来实现这一点，然后通过修改协议的核心分叉选择规则来强制执行这些列表。该系统旨在抵消提议者-构建者分离（PBS）的中心化效应，并加强网络的可信中立性。[\[1\]](#cite-id-09Nj6uuMGFbQZmB2) ## 概述 EIP-7805 的主要动机源于以太坊在实施提议者-构建者分离 (PBS) 后区块生产市场的演变。PBS 的引入是为了将区块的提议者（[验证者](https://iq.wiki/wiki/validator)）的角色与区块的构建者复杂且资源密集型的角色分离。虽然 PBS 成功地实现了其目标，但也导致了一小部分高度专业化的“构建者”的出现，他们构建了网络上的大部分区块。这种权力的集中为交易审查创造了潜在的途径，少数勾结或被胁迫的构建者可以系统地延迟或排除区块链上的特定交易。 [\[2\]](#cite-id-v2A24J6ILU7SqVYt)​ EIP-7805 通过重新赋予更广泛的去中心化验证者权力来解决这一风险。它为他们提供了一种工具，可以集体对区块构建者施加约束，保证任何有效的交易最终都可以被包含在链上。核心原则是，证明新区块的验证者只会投票支持符合由随机选择的同行委员会生成的包含列表的区块。这使得构建者生产审查区块在经济上不可行，因为它会被诚实的证明者忽略，并最终从规范链中孤立。该提案旨在提供强大的包含保证，而不会重新引入 PBS 旨在解决的复杂性。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) [\[2\]](#cite-id-v2A24J6ILU7SqVYt)​ ## 历史和发展 EIP-7805提案由 Thomas Thiery、Francesco D'Amato、Julian Ma、Barnabé Monnot、Terence Tsao、Jacob Kaufmann 和 Jihoon Song 等研究人员和开发者团队于 2024 年 11 月 1 日正式创建。[\[1\]](#cite-id-09Nj6uuMGFbQZmB2) 2024 年 11 月 4 日，在以太坊魔法师联盟论坛上发起了一个公开讨论帖，以收集社区反馈并讨论设计。[\[2\]](#cite-id-v2A24J6ILU7SqVYt) 从其引入开始，该提案被归类为“标准跟踪：核心”EIP，处于“草案”状态，表明它提出了对以太坊核心共识规则的更改，并且需要进行全网硬分叉才能实施。论坛上的讨论迅速开始探讨潜在的挑战和未来的增强功能。一个关键主题是将交易归因于特定验证者，这导致了当月晚些时候提出的名为“FOCILIS”的匿名保护扩展。[\[1\]](#cite-id-09Nj6uuMGFbQZmB2) [\[2\]](#cite-id-v2A24J6ILU7SqVYt) ## 技术机制 FOCIL为验证者、构建者和客户端引入了一套新的规则和责任，这些规则和责任被整合到以太坊的基于槽位的共识周期中。在`slot N`期间，会并发执行在`slot N+1`中强制包含区块的整个过程。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) # ## 核心概念 该机制建立在几个关键思想之上： * **包含列表 (IL):** 由委员会成员根据其公共内存池视图编译的交易列表。这些是成员认为应该包含在下一个区块中的交易。 * **IL 委员会:** 在每个时隙中，随机选择 16 个验证者组成 IL 委员会。他们唯一的职责是创建 IL 并将其广播到网络。 * **分叉选择强制执行:** 提案的力量来自修改分叉选择规则，验证者使用该规则来决定哪个链是规范链。在 FOCIL 下，证明验证者将拒绝未正确满足 IL 包含要求的区块，从而有效地阻止不合规区块被最终确定。 * **有条件包含:** 强制执行不是绝对的。构建者仅需要在包含时有效的交易（例如，正确的 nonce，足够的发送者余额）以及区块中剩余足够的 gas 时，才需要包含 IL 中的交易。无效或不适合的交易不是必需的。 这些核心概念通过涉及多个网络参与者的协调工作流程来实现。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) # ## 角色和工作流程 FOCIL流程涉及每个12秒时段内的精确时间线，协调 IL 委员会、通用验证者、区块构建者和下一个区块的提议者的行动。为 `slot N+1` 中的区块生成 IL 的过程在 `slot N` 期间展开。 | Slot N 中的时间线 | 角色 | 职责 | | :--- | :--- | :--- | | **t=0s – 8s** | **IL 委员会成员** | 在观察了 `slot N` 的区块后，16 名委员会成员中的每一位都会独立地从其本地内存池创建一个包含列表，并将签名的列表广播到 P2P 网络。 | | **t=0s – 9s** | **所有验证者** | 监听、验证、存储和转发他们从委员会成员收到的所有有效 IL。他们还会监控是否存在重复证明（单个成员发送多个不同的 IL）的证据。 | | **t=9s** | **所有验证者** | 在“视图冻结”截止日期，验证者停止接受当前时段的新 IL。这创建了一个稳定的、共享的 IL 集合，该集合将用于验证 `slot N+1` 中的*下一个*区块。 | | **t=0s – 11s** | **区块构建者** | 从网络收集所有可用的 IL。他们使用这些列表来构建 `slot N+1` 的合规区块有效负载。 | | **t=11s** | **区块构建者** | 构建者冻结其 IL 视图并最终确定执行有效负载，确保它包含来自收集列表中的所有可包含的交易。 | | **t=0s (Slot N+1)** | **区块提议者** | `slot N+1` 的提议者广播新区块，其中包含构建者的合规执行有效负载。 | | **t=0s – 4s (Slot N+1)** | **证明者** | 收到 `slot N+1` 区块后，该时段的所有证明者都会将其与来自 `slot N` 的 IL 的冻结视图进行交叉引用。仅当区块正确包含所有必需的 IL 交易时，他们才会对该区块进行投票（证明）。 | 这种时间紧凑的工作流程确保及时生成和传播包含列表，以便构建者构建合规区块，然后由更广泛的证明者网络及时验证。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) # ## 协议层面的变更 EIP-7805的实施需要在共识层（CL）、执行层（EL）以及连接它们的引擎API之间进行协调更改。 ## ## 共识层 (CL) 修改 * **分叉选择规则：** CL的分叉选择逻辑已更新，仅当区块满足包含列表条件时，才被视为有效的证明。未通过此检查的区块将被证明者忽略。 * **新的数据结构：** 引入了两个新的容器：`InclusionList`，其中包含插槽号、委员会成员索引和事务列表；以及`SignedInclusionList`，它是委员会成员签名的`InclusionList`。 * **P2P 网络：** 创建了一个新的全局gossip主题，用于广播`SignedInclusionList`对象，确保它们可以在网络中快速传播。还添加了一个新的RPC方法，允许节点请求他们可能错过的特定IL。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) ## ## 执行层 (EL) 修改 * **新的有效性检查：** EL被赋予一项新的职责。当处理一个新的区块负载时，它必须检查是否遗漏了任何来自提供IL的交易，尽管这些交易是可以包含的。 * **可包含性定义：** 如果一个交易满足两个条件，则被定义为“可包含的”：（1）区块有足够的剩余gas来容纳它，并且（2）该交易对于区块创建的最终状态是有效的（即，发送者具有正确的nonce和足够的资金）。 * **新的错误状态：** 如果EL发现一个可包含但未包含的交易，它将返回一个新的状态`INCLUSION_LIST_UNSATISFIED`给CL。然后CL知道拒绝该区块。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) ## ## Engine API 增强 为了促进CL和EL之间的通信，Engine API通过以下新方法进行了扩展： * `engine_getInclusionListV1`：允许CL从EL请求IL。 * `engine_updatePayloadWithInclusionListV1`：CL在区块构建期间使用它将构建器的聚合IL传递给EL。 * 现有的`engine_newPayload`方法被修改为接受IL交易作为参数，并处理新的`INCLUSION_LIST_UNSATISFIED`状态。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) # ## 关键参数 该提案定义了几个常量来管理该机制： | 参数 | 值 | 描述 | | :--- | :--- | :--- | | `IL_COMMITTEE_SIZE` | `16` | 每个时隙中为 IL 委员会选择的验证者数量。 | | `MAX_BYTES_PER_INCLUSION_LIST` | `8192` (8 KiB) | 单个 IL 的最大大小，限制网络带宽和存储需求。 | | `DOMAIN_IL_COMMITTEE`|`0x0C000000`| 用于防止 IL 签名在其他上下文中重放的唯一签名域。 | 选择这些参数是为了平衡审查阻力与网络开销和性能。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) ## 原理和设计原则 FOCIL 的设计遵循几个关键原则，旨在创建一个强大且复杂度最低的解决方案。 * **基于委员会的来源：** 使用由 16 个验证者组成的委员会，而不是单个实体（如提议者）来获取交易，这使得系统更具弹性。贿赂或攻击单个委员会成员是无效的，因为只需要一个诚实的成员就可以将交易纳入 IL。攻击整个委员会要困难得多，成本也高得多。 * **分叉选择强制执行：** 将强制执行直接与分叉选择规则联系起来是尽可能最强的保证。它使合规性成为共识协议的核心部分，这意味着构建者无法绕过它，否则他们的区块将被网络拒绝。 * **构建者的灵活性：** 该 EIP 通过两种方式为构建者提供灵活性。首先，通过**条件包含**，构建者不会因为遗漏已失效的交易而受到惩罚。其次，**“区块中任何位置”** 规则意味着构建者可以将 IL 交易放置在区块中的任何位置，从而使他们能够继续优化 MEV 而不受干扰，从而避免为 IL 创建复杂的链下排序市场。 * **没有直接激励：** 该提案故意省略了新的费用市场或对 IL 委员会成员的直接经济奖励。它依赖于 `1-out-of-N` 诚实假设（N 个委员会成员中至少有一个是诚实的）以及验证者希望维护网络健康和中立性的一般利他主义。这避免了设计一个新的、无法被博弈的激励系统的巨大复杂性。 这些设计选择旨在提供强大的抗审查能力，同时最大限度地减少对现有区块生产生态系统的干扰。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) ## 安全考虑和挑战 FOCIL提案引入了新的共识交互和依赖关系，这带来了潜在的安全考虑。 * **共识活性：** 该机制的主要活性风险是IL传播的延迟可能导致区块生产的延迟。如果构建者在其截止日期之前未收到IL，则可能会生成不合规的区块，然后该区块将被拒绝，从而可能导致空或错过的插槽。时间线包括验证者视图冻结（t=9秒）和构建者截止日期（t=11秒）之间的缓冲区，以减轻这种情况。 * **IL含糊不清：** 恶意委员会成员可能会尝试通过广播同一插槽的多个不同IL来破坏网络。指定的缓解措施是节点转发来自单个成员的最多两个不同的IL，但如果检测到来自该成员的IL超过两个，则忽略来自该成员的所有IL。这包含了因含糊不清的验证者而造成的潜在带宽影响和混乱。 * **有效载荷构建复杂性：** 用于满足IL约束的简单构建器算法可能在计算上是密集的。对于IL中的大量交易，在构建区块时重复检查其有效性可能会很慢。EIP的作者建议采用更有效的策略，即构建者在将交易添加到区块时跟踪IL中涉及的帐户的`nonce`和`balance`更改，从而可以更快地进行有效性检查。 * **验证者可归属性：** 社区中讨论的一个重大挑战是，FOCIL在验证者的身份和他们选择包含在其IL中的交易之间创建了一个公开的链上链接。这可能会产生“寒蝉效应”，即验证者越来越不愿包含来自有争议或受制裁实体的交易，因为担心法律或社会影响。具有讽刺意味的是，这可能会破坏系统的反审查目标。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2) [\[2\]](#cite-id-v2A24J6ILU7SqVYt) ## 提议的扩展和未来方向 为了应对验证者可归属性挑战，社区开始讨论保护隐私的增强功能。 # ## FOCILIS 提出的最突出的扩展是 **FOCILIS（具有不可区分提交的FOCIL）**。这个概念于2024年11月下旬在 [Ethereum](https://iq.wiki/wiki/ethereum) Magicians 论坛上提出，旨在允许委员会成员匿名提交包含列表（IL）。 * **机制：** 验证者不再使用其私钥签署 IL，而是生成零知识证明（ZKP）。该证明将表明他们是当前时隙 IL 委员会的合法成员，而不会泄露其具体身份。拟议的构造被描述为类似于 Semaphore，一种以隐私为中心的信令协议。 * **防止双重投票：** 为了防止匿名验证者提交多个 IL，FOCILIS 将使用无效器系统。每个委员会成员将提交一个唯一的、一次性使用的 ID，确保每个成员每个时隙只能生成一个有效的证明（因此也只能生成一个有效的 IL）。 讨论线程中的共识倾向于务实的、分两个阶段的实施。首先部署更简单的、完全归属的 FOCIL，以提供即时的抗审查性。[同时](https://iq.wiki/wiki/meanwhile)，将继续研究 FOCILIS 和其他“匿名包含列表（anon-ILs）”，目标是在未来的网络升级中部署隐私保护版本。 [\[2\]](#cite-id-v2A24J6ILU7SqVYt) ## 向后兼容性 EIP-7805 是一项向后不兼容的提案，只能通过计划好的全网络硬分叉激活。这些更改从根本上改变了共识层的区块验证规则，需要更新所有客户端软件（CL 和 EL）。但是，这些更改包含在协议的后端中，不会改变用户交易的结构或现有智能合约的功能。因此，预计此次升级不会破坏面向用户的应用程序，也不需要最终用户或合约开发者采取任何行动。 [\[1\]](#cite-id-09Nj6uuMGFbQZmB2)