FOCIL共识层与执行层工作流程 - 权益证明/区块提议者

\ Screenshot 2024-09-30 at 14.48.261546×1548 390 KB

作者：Thomas Thiery，于 2024年9月30日

感谢 Julian, Terence, Jihoon, Jacob 和 Anders 为本文提供的意见和反馈。

简介

Fork-Choice enforced Inclusion Lists (FOCIL，由分叉选择强制执行的包含列表) 是一种旨在通过强制及时包含交易来增强以太坊的审查抵抗和链中立性的机制。自从其诞生以来，我们的重点已经转移到开发一个 EIP 并在 共识层 (CL) 和执行层 (EL) 上指定其实现。本文档概述了 FOCIL 的工作流程，详细说明了包括 IL 委员会成员、节点、提议者和证明者在内的各个参与者的角色和责任。它还解决了潜在的边缘情况和缓解策略，以确保机制的稳健性。

角色与参与者

IL 委员会成员

• 插槽 n，t = 0 到 9s：IL 委员会成员构建其本地 IL 并通过 P2P 网络广播它们，在处理完插槽 n 的区块并确认其为 Head 后。如果在 t = 8s 之前没有收到区块，他们应该运行 get_head，并根据其节点的规范 Head 构建并发布其本地 IL。

默认情况下，本地 IL 通过从公共 mempool 中选择原始交易来构建，按优先级费用排序，直到达到本地 IL 的最大 gas 限制（如果我们认为本地 IL 主要消耗带宽，我们也可以设置 bits 限制）。可以选择应用其他规则来最大化内容审查抵抗 (CR)，例如优先处理在 mempool 中等待时间最长的有效交易。

节点

• 插槽 n，t = 0 到 9s：节点从 P2P 网络接收本地 IL，并且仅转发和缓存通过 CL P2P 验证规则的那些 IL。

• 插槽 n，t = 9s，IL 冻结截止时间：节点冻结其本地 IL 视图，停止转发和缓存新的本地 IL。

CL P2P 验证规则：

• 本地 IL 中的交易数量不超过允许的最大 gas 限制。
• 本地 IL 的插槽与当前插槽匹配。不匹配当前插槽的本地 IL 应被忽略。
• IL 的父哈希被识别。
• IL 在本地 IL 冻结截止时间（例如，9s）内收到。
• 从该 IL 委员会成员处收到的本地 IL 不超过两个（请参阅下面的本地 IL 伪造部分）。
• 本地 IL 由验证者正确签名。
• 验证者是 IL 委员会的成员。

提议者

• 插槽 n，t = 11s：提议者冻结其本地 IL 视图，并要求 EL 通过从其视图中添加交易来更新其执行负载（确切的时间将在运行一些测试/基准测试后确定）。可以选择添加一个 RPC 端点，允许提议者从其 peer 请求缺少的本地 IL（例如，通过委员会索引）。

通过 (1) 在本地 IL 冻结截止时间和提议者必须广播带有更新的执行负载的区块的时刻之间留出足够的时间，以及 (2) 可能添加一种机制，让提议者可以通过 RPC 端点从 peer 请求缺少的本地 IL，我们确保提议者的 IL 聚合包含所有观察到的本地 IL 的交易，从而消除了对 FOCIL 研究帖子 中描述的 Δ 参数的需求。

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

证明者

• 插槽 n+1，t = 0 到 4s：证明者监控 P2P 网络以查找提议者的区块。在检测到该区块后，他们检查其缓存的本地 IL 中的所有交易是否都包含在提议者的执行负载中。Valid 函数验证执行负载是否满足 IL 有效性条件，无论是在所有交易都存在时，还是在发现任何缺失的交易在追加到负载末尾时无效时。在这些情况下，证明者使用 EL 来验证缺失交易的有效性。

由于我们将 Δ 设置为 0（或者更确切地说，完全去掉了该参数），因此提议者的执行负载必须至少包含来自证明者本地 IL 的所有交易。因此，证明者不需要来自提议者的 IL 聚合来执行此检查。

缓解措施和边缘情况

失效

通过让证明者使用 Valid 函数来检查每个缺失的交易在添加到执行负载的末尾时是否有效，我们确保 FOCIL 与账户抽象兼容。

为了处理失效的情况——包括由完全账户抽象 (AA) 引入的那些情况——证明者使用 Valid 函数来验证执行负载中每个缺失的交易。他们检查每个缺失的交易在使用 EL 追加到执行负载的末尾时是否有效。

通过在执行负载的后置状态上下文中评估缺失的交易，证明者可以准确地确定提议者是否错误地从 IL 中省略了任何有效的交易。如果发现缺失的交易在追加时无效——由于较早的交易引起的状态更改——则不会因忽略它而惩罚提议者，并且满足 IL 有效性条件。

这种方法有效地处理了失效场景，并提供了一种强大的机制，可以适应交易有效性的复杂性，确保尽可能包含来自本地 IL 的所有有效交易。

伪造

为了减轻本地 IL 的伪造，证明者应在冻结截止时间后停止缓存本地 IL，但继续监控 P2P 网络并转发来自同一 IL 委员会成员的多个本地 IL。如果提议者或证明者检测到某个委员会成员已广播多个本地 IL（即，已伪造），则他们应忽略来自该成员的所有本地 IL。

我们还引入了一个 P2P 网络规则，该规则限制节点转发每个验证器索引的本地 IL 不超过两个。此方法可确保有关伪造的信息传播，同时防止垃圾邮件，从而使最大带宽增加保持在最多 2×。

还值得注意的是，IL 聚合在 FOCIL 中不存在作为显式对象；相反，提议者直接将来自本地 IL 的交易包含到执行负载中。因此，没有 IL 聚合会导致伪造。

IL 填充

我们还考虑了 IL 填充，即构建者用他们计划稍后使其失效的交易来 flood mempool——例如，通过耗尽帐户的 ETH 以防止基本费用支付或导致交易回滚。但是，这种攻击是有风险的，因为构建者必须在目标区块之前将这些交易提交到 mempool，而不知道他们是否能确保构建它的权利。这意味着另一个构建者可能会赢得该区块，包括和执行旨在失效的交易，从而使攻击的代价高昂且不切实际。

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