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 对这个提案的讨论、反馈和评论。

tldr

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

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

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

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

引言

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

这推动了研究朝着允许验证者通过强制在其区块中包含交易来对构建者施加约束的方式发展。这些努力最近在即将到来的 Pectra 分叉中考虑包含 forward \text{ILs} (\text{fILs}) 的第一个实际实现中达到顶峰（参见设计，EIP，和 specs here）。然而，有人对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} 和一个 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} 中存在的交易。
  • bitlist \text{tx}_\text{agg}[\text{bitlist}] \in \{0, 1\}^m 指示哪些本地 $\text{IL}$s 包含了给定的交易。
  • 函数 \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 属性（例如有条件的 vs. 无条件的）编码区块的有效性。

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

  • 如果本地 \text{IL} 在截止日期 d 之前可用，但提议者不包括 \text{IL}_\text{agg}^\text{proposer}，则区块 B 被视为无效。

  • 如果在截止日期 d 之前没有本地 \text{IL} 可用，并且提议者不包括 \text{IL}_\text{agg}^\text{proposer}，则区块 B 被视为有效。

  • 如果区块 B 已满，本地 $\text{IL}$s 在 d 之前可用，并且提议者不包括 \text{IL}_\text{agg}^\text{proposer}，则区块 B 仍然被视为有效。

  • 如果根据 \text{Eval}，\text{IL}_\text{agg}^\text{proposer} 与大多数证明者的 \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}s，了解区块 n-1 的内容。
• Slot n-1 , t=9 : 存在一个本地 \text{IL} 冻结截止日期 d，在此之后每个人都会锁定他们观察到的本地 \text{IL}s 的视图。 提议者通过全局主题广播 \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}s 的视图上计算 \text{Agg} 函数的结果（应用 \text{Eval}）并检查区块 B 是否 \text{Valid}，来决定 \text{IL}_\text{agg} 是否“足够好”。

聚合、评估和验证函数

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

• \text{Agg} 函数 可能是最容易定义的：来自所有收集到的本地 \text{IL}s 的交易应该被确定性地聚合和去重，以构建 \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}s 上的 \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) 活跃性（liveness），因为如果标准设置得太严格，我们可能会看到错过 slot 的情况增加。

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

更多规则

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

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

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

• 用户根据他们分配给将其交易包含在区块 B 中的值来placed出价。 他们需要考虑 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} 中排除，来加强机制的稳健性。 深入研究 builder 和 \text{IL} 委员会成员应该如何获得奖励的具体细节超出了本文的范围，因为以激励兼容的方式分配奖励，尤其是在拥塞期间，会变得非常复杂。

但是，这里有三个需要考虑的高级选项：

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

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

\text{Inclusion} 规则

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

\text{Priority} 规则

我们假设该区块将由两个部分组成：一个是 builder 包含的 payload 和一个 \text{IL}_\text{agg}，以对需要在 builder 的 payload 中包含的交易施加约束。 因此，通过 \text{IL}_\text{agg} 对区块 payload 施加约束需要一个优先级规则来确定拥塞期间会发生什么。 通常，FOCIL 中的优先级规则规定，如果可以用 builder 的 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}s 中的重复项。 在 FOCIL 中，现在整个证明者集合都参与强制执行并确保提议者区块中包含的 \text{IL} 的质量，从而消除了提议者以外的单方依赖性。 此外，值得注意的是，审查提议者必须放弃所有共识和执行层奖励，并导致错过 slot，以避免在 \text{IL} 中包含交易。

拆分攻击和 IL 篡改

对 \text{fILs} 的另一个担忧集中在使用 \text{ILs} 的可能“拆分”攻击。 当恶意参与者试图划分网络的诚实视图以阻止共识时，会发生像定时发布或“篡改”之类的拆分攻击。 在以太坊上，验证者通过违反其先前向网络宣传的内容来进行篡改是一种可被罚没的违法行为。 如果有证据表明违规行为已包含在信标链区块中，则会将恶意验证者从验证者集合中移除。 快速提醒一下，在 EIP-7547 设计中，slot n-1 的提议者负责制作 \text{IL} 以约束提议者 n，并且可以广播多个 \text{IL}s（查看 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{IL}s 中包含在同一 slot 期间提交的交易来对该区块施加约束。 这是对 \text{fILs} 设计的严格改进，在 \text{fILs} 设计中，forward 属性对 \text{IL} 交易施加了 1-slot 的延迟。 此属性对于可能因 MEV 原因而被审查的时间敏感型交易特别有用（请参阅链上拍卖中的审查抵抗论文）。 诚然，该机制并非完全实时，因为我们仍然需要施加“本地 \text{IL} 冻结”截止日期 d，以便区块生产者有时间在提议他们的区块之前考虑 \text{IL}_\text{agg} 交易。

\text{IL} 条件性

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

账户抽象会计

在先前的提案中，\text{IL} 摘要被构建为约束区块的结构，而无需提交特定的原始交易。 每个 \text{IL} 摘要（或 FOCIL 的 \text{IL}_\text{agg}）条目通过包括以下字段来表示交易：From 和 Gas Limit。 满足 IL 摘要中的条目要求至少已执行来自 From 地址的 某些 交易，除非 区块中的剩余 gas 小于 Gas Limit 。 这个想法很简单：如果一个交易先前有效并且具有足够高的基础费用，那么阻止其包含的唯一两件事是区块中缺少足够的 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，该交易源自地址 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 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～