强制选择的分叉包含列表（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 对本提案的讨论、反馈和评论。

tldr

在本文中，我们介绍了由 Fork-Choice 强制执行的包含列表 (FOCIL)，这是一种基于委员会的简单 IL 设计。

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

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

这种设计通过保证及时的交易包含，确保了强大而可靠的机制来维护以太坊的审查抵制和 链中立性 属性。

介绍

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

这推动了 研究 转向允许验证者通过强制在其区块中包含交易来对构建者施加约束的方法。这些努力最近在即将到来的 Pectra 分叉中考虑包含前向 \text{ILs} (\text{fILs}) 的第一个实际实现中达到高潮（参见 设计，EIP 和 规范 此处）。但是，有人对 EIP-7547 中提出的特定机制提出了一些担忧，导致其被拒绝。

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

设计

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

高阶概述

每个Slot，都会随机选择一组验证者成为包含列表 (\text{IL}) 委员会的一部分。\text{IL} 委员会成员负责创建公共 mempool 中待处理交易的本地包含列表 (\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}）和一个有效负载。
  • \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}$s 包含给定的交易。
  • 函数 \text{Agg} 接受可用本地 IL 集 \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 已满，则在 d 之前有可用的本地 $\text{IL}$s，并且提议者未包含 \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，其中包含有效负载和聚合的 \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} }

• \text{Eval} 函数 由每个Slot n 证明者用于评估区块 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} 中保留多长时间？如果跳过一个Slot会发生什么？

更多规则

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

• 用户应如何支付将其交易包含在内（\text{Payment}）
• 如何在 FOCIL 参与者之间分配奖励（\text{Reward}）
• 如何构建本地 \text{IL}（\text{Inclusion}）
• \text{IL} 和有效负载交易之间的交互（\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} 规则可能是包含公共 mempool 中看到的所有交易，按优先费用排序。

\text{Priority} 规则

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

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

改进和缓解措施

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

承诺攻击

FOCIL 和 EIP-7547 中提出的前向 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{ILs}（查看 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审查抵制

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

\text{IL} 条件性

\text{ILs} 的一个核心属性是其条件性，该条件性确定 IL 是否应为其交易保留专用的区块空间（无条件）或与有效负载共享区块空间，并且仅在区块未满时才包含在内（有条件）。对于 FOCIL，我们倾向于出于以下几个原因使用有条件的 \text{ILs}。首先，通常最好让像构建者这样的复杂实体在组织区块空间方面拥有最大的自由，只要他们包含 \text{IL} 交易即可。允许他们按自己的喜好对交易进行排序并填充区块，而不是对其行动空间施加过多的限制，从而降低了他们使用侧通道来规避过于严格的机制的风险。具体来说，由于希望使用 \text{IL} 专用区块空间的构建者可以简单地从选定的验证者那里“购买 \text{IL} 委员会席位”，以经由本地 \text{ILs} 包含其交易，因此有条件的属性实际上无法通过 FOCIL 有效地强制执行。选择有条件的 \text{ILs} 的另一个原因是列表大小的灵活性。对于无条件的 IL，添加的区块空间必须严格设置任意最大 \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 的 Account Abstraction 的有限形式（例如，EIP-3074 或 EIP-7702），也允许一笔交易触发 EOA 余额的变化，而无需来自该 EOA。这 引起了对 之前 \text{fIL} 提案的关注，因为提议者 n 在提议其\text{IL} 时，不知道构建者 $n$ 的 payload 中包含什么。这可能导致这样一种情况：提议者 n 在 \text{IL} 中包含来自地址 A 的交易 txn_A，而构建者 n 包含一笔 EIP-7702 交易 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 中插入 EIP-7702 交易，从而使 \text{IL}_\text{agg} 交易失效。为了处理这种情况，我们可以在验证区块时执行以下操作：

• 在执行区块的交易之前，我们存储 \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 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～