Fork-Choice强制包含列表 (FOCIL)：一个简单的基于委员会的包含列表提议 - 权益证明 / 区块提议者

DALL·E 2024-06-05 14.58.08 - 一幅高度真实的插图，一块石头上刻有以太坊的象征，位于一个洞穴中。这块石头应该看起来饱经风霜和古老，wi1792×1024 246 KB

focil => fossil => 协议固化

作者：Thomas, Barnabé, Francesco 和 Julian - 2024 年 6 月 19 日

这个设计是在柏林与 RIG 及其朋友进行的一周小型面对面聚会中共同完成的，目的是讨论审查抵抗、发行以及 Attester-Proposer-Builder-Consensus-Execution-[在此处插入内容] 分离。

感谢 Luca、Terence、Toni、Ansgar、Alex、Caspar 和 Anders 对此提案的讨论、反馈和评论。

概要

在这篇文章中，我们介绍了 Fork-Choice enforced Inclusion Lists (FOCIL)，一种简单的基于委员会的 IL 设计。

FOCIL 分为三个简单的步骤构建：

1. 每个Slot，选择一组验证者成为 IL 委员会成员。每个成员根据他们对内存池的主观看法，传播一个 本地包含列表。
2. 区块提议者收集并将可用的本地包含列表聚合成一个简洁的 聚合，该聚合包含在其区块中。
3. 证明者根据他们自己对传播的本地列表的看法评估 聚合 的质量，以确保区块提议者准确报告可用的本地列表。

该设计通过保证及时包含交易，确保了稳健可靠的机制，以维护以太坊的审查抵抗和 链中立性 属性。

简介

为了保护以太坊验证者群体免受中心化力量的影响，构建区块的权利已被拍卖给称为构建者的专业实体。在过去的一年中，这导致少数精明的构建者主导了网络的区块生产。规模经济进一步巩固了他们的地位，使得新的参与者越来越难以获得重要的市场份额。寡头区块生产的一个直接后果是网络（弱）审查抵抗属性的恶化。今天，前三大构建者中的两个正在积极过滤掉与其区块中受制裁地址交互的交易。相比之下，更分散和异构的 90% 的验证者群体没有参与审查。

这推动了研究朝着允许验证者通过强制在其区块中包含交易来对构建者施加约束的方式发展。这些努力最近最终形成了第一个实用的 forward \text{ILs} (\text{fILs}) 实现，该实现正在考虑包含在即将到来的 Pectra 分叉中（参见设计、EIP 和 specs 这里）。然而，人们对 EIP-7547 中提出的具体机制提出了一些担忧，导致其被拒绝。

在此，我们介绍 FOCIL，一种简单的基于委员会的设计，它改进了以前的 IL 机制（Forward ILs，COMIS）或共同创建的区块（CBP），并解决了与 贿赂/勒索攻击、IL 伪造、帐户抽象 (AA) 和激励不兼容性相关的问题。另请注意 Vitalik 最近的提案“每个证明者一位的包含列表”，其中选择构建列表的委员会本质上是整个证明者集合。

设计

在本节中，我们将介绍 FOCIL 机制的核心属性（参见 图 1）。

高层次概述

每个Slot，随机选择一组验证者成为包含列表 (\text{IL}) 委员会的一部分。 \text{IL} 委员会成员负责创建公共内存池中待处理交易的本地包含列表 (\text{IL}_\text{local})。然后，本地 \text{IL} 通过全局主题广播，区块生产者必须在其区块 B 中包含来自收集的本地 \text{IL} 的规范聚合 (\text{IL}_\text{agg})。 \text{IL}_\text{agg} 的质量由证明者检查，并影响区块 B 的有效性。

Screenshot 2024-06-04 at 15.58.511364×742 103 KB

图 1. 图示了 FOCIL 机制。

机制

• 验证者选择和本地包含列表
  • 从信标委员会中选择一组验证者，成为Slot n 的 \text{IL} 委员会成员。该集合表示为 \text{IL}_\text{committee}(n) = \{ 1, \dots, m \}，其中 m 是 \text{IL} 委员会成员的数量。
  • 每个 \text{IL} 委员会成员 i \in \text{IL}_\text{committee}(n) 发布一个本地 \text{IL}，从而产生Slot n 的一组本地 \text{IL}，定义为 \text{IL}_\text{local}(n) = \{ \text{IL}_1, \dots, \text{IL}_m \}。
  • 每个本地 \text{IL}_i 包含交易：\text{IL}_i = \{ \text{tx}^1_i, \dots, \text{tx}^{j_i}_i \}，其中每个 \text{tx} 表示为 \text{tx} = (\text{tx}[\text{From}], \text{tx}[\text{Gas Limit}])，并且 j_i 指示 \text{IL}_i 中的交易数量。 From 字段表示发送者的地址，Gas Limit 字段表示交易消耗的最大 gas。这用于检查给定的交易是否可以包含在区块中 有条件 IL 属性。
• 区块生产者的角色
  • Slot n 的区块生产者（表示为 \text{BP}(n)）必须在其区块 B = (B[\text{IL}_\text{agg}], B[\text{payload}]) 中包含一个 \text{IL} 聚合，表示为 \text{IL}_\text{agg} 和一个 payload。
  • \text{IL}_\text{agg} 由交易组成：\text{IL}_\text{agg} = \{ \text{tx}^1_\text{agg}, \dots, \text{tx}^{t_\text{agg}}_\text{agg} \}，其中每个交易 \text{tx}_\text{agg} 定义为 (\text{tx}_\text{agg}[\text{tx}], \text{tx}_\text{agg}[\text{bitlist}])，并且 \text{payload} 必须包含 \text{IL}_\text{agg} 中存在的交易。
  • 位列表 \text{tx}_\text{agg}[\text{bitlist}] \in \{0, 1\}^m 指示哪些本地 $\text{IL}$ 包含给定的交易。
  • 函数 \text{Agg} 接受可用的本地 ILs \text{IL}_\text{local}(n) 集合，并输出一个“规范”聚合。提议者聚合 \text{IL}_\text{agg}^\text{proposer} 包含在区块 B 中，每个证明者通过将其与自己的 \text{IL}_\text{agg}^\text{attester} 进行比较来评估其质量，使用函数 \text{Eval}(\text{IL}_\text{agg}^\text{attester}, \text{IL}_\text{agg}^\text{proposer}, Δ) \in \{ \text{True}, \text{False} \}。

• 证明者的角色

  • Slot n 的证明者接收区块 B 并应用函数 \text{Valid}(B) 来确定区块的有效性。
  • \text{Valid} 根据 \text{Eval} 的结果以及核心 IL 属性（例如 有条件与无条件) 来编码区块的有效性。

  • 以下是一些说明 \text{IL} 相关的有效性条件的情况：

    • 如果在截止日期 d 之前提供本地 \text{IL}，但提议者不包含 \text{IL}_\text{agg}^\text{proposer}，则认为区块 B 无效。
    • 如果在截止日期 d 之前没有提供本地 \text{IL}，并且提议者不包含 \text{IL}_\text{agg}^\text{proposer}，则认为区块 B 有效。
    • 如果区块 B 已满，本地 $\text{IL}$ 在 d 之前可用，并且提议者不包含 \text{IL}_\text{agg}^\text{proposer}，则仍认为区块 B 有效。
    • 如果 \text{IL}_\text{agg}^\text{proposer} 根据 \text{Eval} 与大多数证明者的 \text{IL}_\text{agg}^\text{attester} 没有重叠，则认为区块 B 无效。

核心 FOCIL 机制可以定义为：

\mathcal{M}_\text{FOCIL}= (\text{Agg}, \text{Eval}, \text{Valid})

时间线

此处的具体时间安排仅作为示例，但需要进行更多研究以确定哪些数字有意义。

• Slot n-1 ， t = 6 ： \text{IL} 委员会发布其本地 \text{IL}，了解区块 n-1 的内容。
• Slot n-1 ， t=9 ： 存在一个本地 \text{IL} 冻结截止日期 d，之后每个人都会锁定他们观察到的本地 \text{IL} 视图。提议者通过全局主题广播 \text{IL}_\text{agg}。
• Slot n ， t=0 ： Slot n 的区块生产者发布其区块 B，其中包含 payload 和聚合的 \text{IL}_\text{agg}。
• Slot n ， t=4 ： Slot n 的证明者对区块 B 进行投票，通过比较根据他们对可用本地 \text{IL} 的本地视图计算 \text{Agg} 函数的结果（应用 \text{Eval}）并检查区块 B 是否 \text{Valid}，来决定 \text{IL}_\text{agg} 是否“足够好”。

聚合、评估和验证函数

如机制部分所述，FOCIL 依赖于三个核心函数。需要指定每个函数以确保该机制实现其目的。

• \text{Agg} 函数可能最容易定义：来自所有收集的本地 \text{IL} 的交易应确定性地聚合和去重以构建 \text{IL}_\text{agg}。我们让：

  • \text{IL}_\text{local} = \{\text{IL}_1, \text{IL}_2, \ldots, \text{IL}_m\} 是从委员会成员 m 收集的本地包含列表的集合。

  • 每个 \text{IL}_i = \{\text{tx}_i^1, \text{tx}_i^2, \ldots, \text{tx}_i^{t_i}\}

    是第 i 个委员会成员的本地包含列表中的交易。

  • 每个交易 \text{tx} 由 (\text{hash}, \text{sender}, \text{nonce}) 定义

\text{Agg}(\text{IL}_\text{local}) 可以定义为：

\text{Agg}(\text{IL}_\text{local}) = {\text{tx} | \text{tx} \in \bigcup_{i \in m} \text{tx}_{i} }

• 每个Slot n 的证明者都使用 \text{Eval} 函数来评估包含在区块 B 中的 \text{IL}_\text{agg} 的质量。每个证明者计算在他们的视图中观察到的所有本地 \text{IL} 的 \text{Agg} 函数，然后将他们生成的 \text{IL}_\text{agg}^\text{attester} 与提议者包含的 \text{IL}_\text{agg}^\text{proposer} 进行比较。然后可以定义 \text{Eval} 函数，以便如果提议者的 IL_{\text{agg}}^{\text{proposer}} 包括了证明者观察到的足够比例的交易（由参数 Δ 定义），则该函数有效：

\text{Eval}(IL_{\text{agg}}^{\text{attester}}, IL_{\text{agg}}^{\text{proposer}}, \Delta) = \begin{cases} \text{True} & \text{if } \frac{|IL_{\text{agg}}^{\text{attester}} \cap IL_{\text{agg}}^{\text{proposer}}|}{|IL_{\text{agg}}^{\text{attester}}|} \geq \Delta \\ \text{False} & \text{otherwise} \end{cases}

请注意，\text{Eval} 函数，尤其是它的参数 Δ，将决定 (1) \text{IL}_\text{agg}^\text{proposer} 的质量和我们愿意赋予提议者的代理权，以及 (2) 活跃性之间的权衡，因为如果标准设置得过于严格，我们可能会看到错过Slot的数量增加。

• \text{Valid} 函数编码 \text{IL}_\text{agg} 是否符合预定义的核心 \text{IL} 属性，例如：
  • 有条件与无条件：提议者是否应在区块中尽可能多地包含 \text{IL} 交易（只要有剩余空间），或者是否有专门为 \text{IL} 交易保留的区块空间？
  • 在区块中的位置：\text{IL} 交易应包含在区块中的什么位置？它们应放置在任何位置、区块的顶部还是区块的末尾？
  • 过期：交易一旦包含在 \text{IL} 中，会在 \text{IL} 中保留多长时间？如果跳过Slot会发生什么？

更多规则

在以下部分中，我们将介绍可以添加到核心机制中的其他规则，以指定：

• 用户应如何支付将其交易包含在其中（\text{Payment}）的费用
• 如何在 FOCIL 参与者之间分配奖励（\text{Reward}）
• 如何构建本地 \text{IL}（ \text{Inclusion}）
• \text{IL} 和 payload 交易之间的交互（\text{Priority}）。

用户竞标，\text{Payment} 和\text{Reward} 规则

• 用户根据他们为将交易包含在区块 B 中所赋予的价值进行出价。他们需要考虑 FOCIL 机制 \mathcal{M}_\text{FOCIL}，以及 EIP-1559 机制如何设置其基本费用，表示为 \mathcal{M}_\text{1559}。例如，用户 t 进行出价 b^t(v^t, \mathcal{M}_\text{FOCIL},\mathcal{M}_\text{1559}) = (\delta^t, f^t)，其中 \delta^t 是最大优先级费用，f^t 是最大总费用（即，基本费用 r + 优先级费用 \delta^t）。
• 来自所有用户的出价向量表示为 \mathbf{b} = (b^1, b^2, \dots, b^T)，其中每个 b^t 表示来自用户 t 的出价。
• \text{Payment} 规则 p(\mathbf{b}) = (p_0(\mathbf{b}), p_1(\mathbf{b}), \dots, p_t(\mathbf{b}), \dots, p_m(\mathbf{b})) 确保用户支付的费用不超过他们的优先级费用 \hat{\delta}^t = \min(\delta^t, f^t - r)。在这里，p_0(\mathbf{b}) 表示向区块生产者的付款，p_t(\mathbf{b}) 表示用户 t 向所有其他 \text{IL} 委员会成员支付的款项，其中用户的集合的大小为 m，并且区块生产者由 0 索引。

上面定义的 \text{Payment} 规则旨在概括地说明如何将用户交易支付的价值在 FOCIL 参与者（例如，\text{IL} 委员会成员、区块生产者）之间重新分配，以激励被认为对网络有益的行为，在本例中是保留其抗审查属性。激励 \text{IL} 委员会成员包含交易加强了该机制的稳健性，从而增加了 审查成本，或者说审查方必须支付的费用才能让 \text{IL} 委员会成员将其交易排除在其本地 \text{IL} 之外。深入研究构建者和 \text{IL} 委员会成员应如何获得奖励超出了本文的范围，因为以激励兼容的方式分配奖励（尤其是在拥塞期间）会变得非常复杂。

但是，以下是三个需要考虑的高级选项：

• 选项 1：所有交易优先级费用都归构建者所有，而 \text{IL} 委员会成员则不被激励在其本地 \text{IL} 中包含交易。这个简单的选项不需要对现有费用市场进行任何更改，但完全依赖于 \text{IL} 委员会成员的利他主义。我们甚至可以考虑 FOCIL 的选择加入版本，其中验证者可以选择成为一个列表的一部分，该列表可能会被选为 \text{IL} 委员会成员并以利他主义的方式参与构建 \text{IL}。但是，这既不会增加审查的成本，也不会使验证者非常愿意参与该机制。这也可能导致用户进行链外支付，希望将其交易包含在本地 \text{IL} 中。
• 选项 2：区块中包含的交易的优先级费用将给予 \text{IL} 委员会成员。为了在成员之间分配奖励，我们可以通过定义一个 \text{Reward} 规则来实施加权激励系统，以计算和分配每个成员的奖励，同时考虑其本地列表中包含的交易的数量（即，计数）和唯一性（有关更多详细信息，请参见 COMIS 帖子的附录 1）。如果交易不是 \text{IL}_\text{agg} 的一部分，则优先级费用将归构建者所有。但是，这种方法在拥塞期间使用有条件的 \text{IL} 属性时可能会出现问题，因为构建者可能会被激励用不在 \text{IL}_\text{agg} 中的交易来填充该区块，即使 \text{IL} 交易具有更高的优先级费用。为了解决这个问题，我们可能需要设计一种机制，在拥塞期间将优先级费用重定向到构建者。但是，实际实施和潜在的次要影响需要进一步研究。
• 选项 3：第三种选择是引入一个新的、单独的包含费用，该费用始终归 IL 委员会成员所有，而优先级费用始终归构建者所有。这可能会解决与拥塞相关的 选项 2 的问题，但会引入用户需要设置的另一个变量。选项 2 和选项 3 之间的一个有用区别是复杂性是强加给 IL 委员会成员还是最终用户。

另一个值得探讨的有趣问题是跨 \text{IL} 委员会成员的费用分配对 MEV-burn 等机制的影响。 选项 2 和 3 将有效地“减少燃烧”并产生与 MEV-smoothing 类似的效果，但规模较小，仅限于 \text{IL} 委员会的规模（h/t Anders）。

\text{Inclusion} 规则**

\text{Inclusion} 规则确定了 \text{IL} 委员会成员应根据哪些标准构建其本地 \text{IL}。在 FOCIL 中，我们根据 IL 委员会成员将尝试最大化其奖励的前提来定义它。假设 \text{Payment} 规则采用 选项 2，则 \text{Inclusion} 规则可能是包含在公共内存池中看到的所有交易，按优先级费用排序。

\text{Priority} 规则**

我们假设该区块将由两个组成部分组成：一个 payload 和一个由提议者包含的 \text{IL}_\text{agg}，以对需要在构建者的 payload 中包含的交易施加约束。因此，通过 \text{IL}_\text{agg} 对区块 payload 施加约束需要一个优先级规则来确定在拥塞期间会发生什么。通常，FOCIL 中的优先级规则规定，如果该区块可以用构建者的 payload 交易填充，则 \text{IL}_\text{agg} 中的交易可能会被排除。换句话说，即使 \text{IL}_\text{agg} 中的某些交易未包含，只要该区块已完全填满（即，达到 30 M gas 限制），该区块仍然有效。

注意：规则不是一成不变的，应将其理解为 FOCIL 的候选规则。规则也不一定必须是明确的。例如，我们可以定义 \text{Reward}，以便 \text{IL} 委员会的主要策略是遵守 \text{Inclusion} 规则，而无需协议进行任何形式的强制执行。

改进和缓解措施

在本节中，我们将讨论对先前 \text{IL} 提案的改进，重点是简化并解决具体的实施问题。

承诺攻击

FOCIL 和 EIP-7547 中提出的 forward IL (\text{fIL}) 设计之间的主要区别之一是，FOCIL 依赖于多个验证者的委员会，而不是单个提议者，来构建和广播 \text{IL}。这种方法对创建“良好”的聚合列表施加了更严格的约束，并显着减少了贿赂攻击的范围。攻击者现在需要贿赂整个 \text{IL} 委员会（例如，256 名成员），而不是针对单个方来影响将交易从 \text{IL} 中排除，从而大大增加了此类攻击的成本。先前的设计（例如，COMIS 和 anon-IL）也涉及多个方参与构建包含列表，但仍然依赖于聚合器来收集、聚合和去重本地 \text{IL}。在 FOCIL 中，所有证明者现在都参与强制执行和确保包含在提议者区块中的 \text{IL} 的质量，从而消除了提议者以外的单方依赖性。此外，值得注意的是，进行审查的提议者必须放弃所有共识和执行层奖励，并导致错过Slot，以避免在 \text{IL} 中包含交易。

分裂攻击和 IL 伪造

对 \text{fILs} 的另一个担忧集中在使用 \text{ILs} 进行可能的“分裂”攻击。当恶意参与者试图分裂网络的诚实视图以阻止共识时，就会发生 分裂攻击，例如定时发布或“伪造”。在以太坊上，验证者通过违反其先前向网络宣传的内容而进行伪造是一种 可扣款的罪行。如果信标链区块中包含了有关该罪行的证据，则会将恶意验证者从验证者集合中删除。快速提醒一下，在 EIP-7547 设计中，Slot n-1 的提议者负责制定 \text{IL} 以约束提议者 n，并且可以广播多个 \text{IL}（查看 No-free lunch 帖子以了解原因，以及它与解决免费数据可用性问题有何关系）。这意味着，恶意提议者可以通过 \text{IL} 伪造来分裂网络的诚实视图，而不会被扣款。但是，这不是 FOCIL 的问题，因为 \text{IL}_\text{agg} 必须是提议者 $n$ 的区块的一部分。因此，从协议的角度来看， \text{IL} 伪造等同于区块伪造，这是一种已知的、可扣款的罪行。

激励不兼容

先前的 \text{fILs} 提案没有考虑激励 \text{IL} 提议者包含“良好”的交易。依靠利他行为可能很好，但总是存在一种风险，即如果没有获得奖励的激励，只有极少数验证者会选择参与该机制。强烈认为，如果验证者因透露其偏好而有被标记为非审查实体或审查实体的风险（请参见 匿名包含列表帖子），并且如果他们没有因促进维护网络的抗审查属性而获得奖励，那么任何 \text{IL} 机制的采用都可能非常低。在 FOCIL 中，我们考虑了在 \text{IL} 委员会成员之间分配奖励的机制，并提到了两个选项（\text{Payment} 规则部分中的 选项 2 和选项 3），用于根据其本地列表中包含的交易的数量（即，计数）和唯一性来共享交易费用。我们希望继续朝着这个方向努力，并找到激励兼容的方式来增加审查成本。

同一Slot的抗审查性

通过让 FOCIL 在Slot n-1 期间与区块构建并行运行，我们可以通过在本地 \text{IL} 中包含在相同Slot内提交的交易来对该区块施加约束。这是对 \text{fILs} 设计的严格改进，其中 forward 属性对 \text{IL} 交易施加了 1 个Slot的延迟。此属性对于可能因 MEV 原因而被审查的时间敏感型交易特别有用（请参见 链上拍卖中的抗审查性 论文）。诚然，该机制并非完全实时，因为我们仍然需要强制执行“本地 \text{IL} 冻结”截止日期 d，以便区块生产者有时间在提议其区块之前考虑 \text{IL}_\text{agg} 交易。

\text{IL} 条件性

\text{ILs} 的核心属性是它们的条件性，这决定了 ILs 是否应为其交易分配专用的区块空间（ 无条件），还是与 payload 共享区块空间，并且仅在区块未满时才被包含在内（有条件的）。对于 FOCIL，我们倾向于使用有条件的 \text{ILs}，原因有几个。首先，通常最好让像构建者这样的复杂实体在组织区块空间时拥有最大的自由度，只要它们包含 \text{IL} 交易。允许他们按照自己的喜好对交易进行排序和填充区块，而不是对他们的行动空间施加过多的限制，从而降低了他们使用侧通道绕过过于僵化的机制的风险。具体来说，对于 FOCIL 来说，无条件属性实际上无法有效地强制执行，因为想要使用 \text{IL} 专用区块空间的构建者可以简单地从选定的验证者那里“购买 \text{IL} 委员会席位”，以通过本地 \text{ILs} 包含他们的交易。选择有条件的 \text{ILs} 的另一个原因是列表大小的灵活性。对于无条件的 ILs，添加的区块空间必须严格设置任意最大 \text{IL} gas 限制（例如，3M gas）。相比之下，有条件的 \text{ILs} 允许更大的 \text{IL} 大小灵活性，具体取决于区块中的剩余空间。有条件的 \text{ILs} 的已知缺点是区块填充：进行审查的构建者可能会将其区块填充到 gas 限制，以将 \text{IL} 交易排除在外。需要进行更多的研究来确定区块填充的可持续性，因为 连续的完整区块会呈指数级增加基本费用 以及此策略的总体成本。

账户抽象核算

在之前的提议中，\text{IL} 摘要被构建为约束区块的结构，而不必承诺具体的原始交易。每个 \text{IL} 摘要——或 FOCIL 的 \text{IL}_\text{agg}——条目通过包含以下字段来表示一笔交易：From 和 Gas Limit。满足 IL 摘要中的一个条目需要至少执行来自 From 地址的某些交易，除非区块中剩余的 gas 小于 Gas Limit。这个想法很简单：如果一笔交易之前是有效的，并且有足够高的 basefee，那么阻止它被包含的唯一两个因素是区块中缺乏足够的 gas 或交易失效，这需要先前执行来自同一发送者的交易。在这里，我们依赖于以太坊 EOA 的一个属性：EOA 的 nonce 和 balance 决定了来自该 EOA 的任何交易的有效性，并且只能通过这样的交易来修改。

然而，即使是已经被考虑纳入 Electra 的有限形式的账户抽象（例如，EIP-3074 或 EIP-7702）也允许一笔交易触发 EOA 余额的变化，而无需来自该 EOA。这引发了对先前 \text{fIL} 提案的担忧，因为提议者 n 在提议其 \text{IL} 时，不知道构建者 $n$ 的 payload 中包含什么。这可能会导致这样一种情况：提议者 n 在 \text{IL} 中包含来自地址 A 的交易 txn_A，而构建者 n 包含一个 EIP-7702 交易 txn_B，该交易 txn_B 来自地址 B，但却扫空了地址 A 的所有 ETH，从而使 txn_A 无效。因此，构建者 n+1 将不再能够包含 txn_A，尽管之前没有执行来自地址 A 的其他交易。换句话说，IL 摘要将无法满足。

在 FOCIL 中，一个简化是 \text{IL}_\text{agg} 的约束适用于正在并发构建的区块。这意味着 \text{IL}_\text{agg} 中的交易不会因为前一个区块中的交易而失效，就像在 \text{fIL} 设计中那样。换句话说，我们不需要担心前一个区块中发生的事情，以便检查 \text{IL}_\text{agg} 是否满足。但是，构建者仍然可以在其 payload 中插入使 \text{IL}_\text{agg} 交易无效的 EIP-7702 交易。为了处理这种情况，我们在验证区块时可以执行以下操作：

• 在执行区块的交易之前，我们存储 \text{IL}_\text{agg} 中出现的所有 From 地址的 nonce 和 balance。
• 执行后，我们再次检查来自 \text{IL}_\text{agg} 的所有 From 地址的 nonce 和 balance，对于 \text{IL}_\text{agg} 中的每个 (From, Gas Limit) 对，我们要求 nonce 或 balance 已经更改，或者 Gas Limit 大于剩余 gas。

如果 nonce 已经更改，则已执行来自该地址的某些交易。如果 balance 已经更改但 nonce 没有更改，则某些 AA 交易已触及该地址。在这两种情况下，该地址都在区块中进行了交易，并且该条目已满足。

注意： 对于“完全” AA，交易的有效性可能取决于任意状态（例如，Uniswap 池中的价格变化）。在这种情况下，依赖于简化形式的交易（即，具有 From 和 Gas limit 字段的条目）是不够的，因为需要交易的完整验证逻辑。由于免费数据可用性问题，将原始交易放在链上是不可行的。相反，证明者可以在本地检查这一点，因为他们需要构建自己的 \text{IL}_\text{agg}^\text{attester}，因此可以评估完整的验证逻辑。这允许他们验证交易是否已失效以及是否应强制执行其包含。但是，证明者可能拥有包含来自同一 From 地址的不同交易的 \text{IL}_\text{agg}^\text{attester}\text{s}，从而导致一种交易可能失效而另一种交易无效的情况。这将导致分离的视图和潜在的攻击。

• BRAID 的审查保险市场
• AUCIL：一种基于拍卖的包含列表设计，用于增强以太坊上的审查抗性
• 执行提案权的抗 MEV 动态定价拍卖
• FOCIL CL & EL 工作流程
• Mechan-stein (alt. Franken-ism)
• 还有11个

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