强制分叉选择的包含列表（FOCIL）：一个简单的基于委员会的包含列表提议 - 权益证明/区块提议者

\ DALL·E 2024-06-05 14.58.08 - 一幅高度逼真的插图，描绘了一块石头，以太坊的标志化石化在其中，背景设置在一个洞穴中。 这块石头应该看起来饱经风霜，古老而充满智慧1792×1024 246 KB

focil => fossil => protocol ossification（协议僵化）

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

这个设计是在柏林与RIG及其朋友进行的一周小型面对面聚会中共同完成的，旨在讨论审查抵抗、发行以及证明者-提议者-构建者-共识-执行-[在此处插入]分离。

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

tldr（太长不看）

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

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

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

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

介绍

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

这推动了研究朝着允许验证者通过强制在其区块中包含交易来对构建者施加约束的方式发展。这些努力最近在即将到来的Pectra fork中考虑包含的 forward \text{ILs} (\text{fILs})的首次实际实施中达到顶峰（参见设计，EIP和规范 here）。但是，人们对EIP-7547中提出的具体机制提出了一些担忧，导致其被拒绝。

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

设计

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

高层概述

每个插槽，随机选择一组验证者成为包含列表（\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机制的图表。

机制

• 验证者选择和本地包含列表
  • 从信标委员会中选择一组验证者，成为插槽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}，从而产生插槽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属性，交易是否可以包含在区块中。
• 区块生产者的角色
  • 插槽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} \}。

• 证明者的角色

  • 插槽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}$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})

时间线

这里给出的具体时间安排只是一个例子，但需要更多的研究来确定哪些数字是有意义的。

• 插槽 n-1 , t = 6 : \text{IL}委员会发布其本地\text{IL}，知道区块n-1的内容。
• 插槽 n-1 , t=9 : 存在一个本地\text{IL}冻结截止日期d，在此之后，每个人都会锁定他们观察到的本地\text{IL}的视图。提议者在全局主题上广播\text{IL}_\text{agg}。
• 插槽 n , t=0 : 插槽n的区块生产者发布其区块B，该区块包含payload和聚合的\text{IL}_\text{agg}。
• 插槽 n , t=4 : 插槽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} 函数 由每个插槽 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}} 包括证明者观察到的足够比例的交易（由参数 Δ 定义），则该 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） 活跃性 之间的权衡，因为如果标准设置得过于严格，我们可能会看到错过插槽的情况增加。

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

更多规则

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

• 用户应如何支付将其交易包含在内的费用 (\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} 规则可以是包含在公共 mempool 中看到的所有交易，并按优先费用排序。

\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} 的质量，从而消除了提议者以外的单方依赖性。此外，值得注意的是，审查提议者必须放弃所有共识和执行层面的奖励，并导致错过插槽，以避免在 \text{IL} 中包含交易。

拆分攻击和 IL 伪造

对 \text{fILs} 的另一个担忧集中在使用 \text{ILs} 进行可能的“拆分”攻击。拆分攻击，例如定时释放或“伪造”，发生在恶意参与者试图划分网络的诚实视图以阻止共识时。在以太坊上，验证者通过与先前向网络广播的内容相矛盾来伪造是一种 可削减的违规行为。如果包含在信标链区块中的证据表明存在违规行为，则会将恶意验证者从验证者集中删除。快速提醒一下，在 EIP-7547 设计中，插槽 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），用于根据其本地列表中包含的交易的数量（即计数）和唯一性来共享交易费用。我们希望继续朝着这个方向努力，并找到激励兼容的方式来增加审查成本。

同槽审查抵抗

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

\text{IL} 条件性

\text{ILs} 的一个核心属性是它们的条件性，它决定了 IL 是否应该为其交易提供专用的区块空间（无条件），或者与 payload 共享区块空间，并且只有在区块未满时才包含。对于 FOCIL，我们倾向于使用有条件的 \text{ILs}，原因有几个。首先，一般来说，最好给予像构建者这样的复杂实体最大限度的自由来组织区块空间，只要它们包含 \text{IL} 交易。允许他们按他们喜欢的方式对交易进行排序和填充区块，而不是对他们的行动空间施加过多的限制，从而降低了他们使用侧通道来规避过于严格的机制的风险。具体来说，使用 FOCIL 无法有效地强制执行无条件属性，因为想要使用 \text{IL} 专用区块空间的构建者可以简单地从当选的验证者那里“购买 \text{IL} 委员会席位”，以通过本地 \text{ILs} 包含他们的交易。选择有条件的 \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 中的有限形式的账户抽象（例如，EIP-3074 或 EIP-7702）也允许一笔交易触发 EOA 余额的变化，而无需源自该 EOA。这 引起了对 之前 \text{fIL} 提案的担忧，因为提议者 n 不知道构建者 $n$ 在提议其 \text{IL} 时，其 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 中插入使 \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 字段的条目）是不够的，因为需要交易的完整验证逻辑。由于 free data-availability 问题，将原始交易放在链上不是一种选择。相反，证明者可以在本地检查这一点，因为他们需要构建自己的 \text{IL}_\text{agg}^\text{attester}，因此可以评估完整的验证逻辑。这允许他们验证交易是否已失效，以及是否应强制执行其包含。然而，证明者可能拥有包含来自同一 From 地址的不同交易的 \text{IL}_\text{agg}^\text{attester}\text{s}，从而导致一种交易可能失效而另一种交易未失效的情况。这将导致不同的观点和潜在的攻击。

• Censorship Insurance Markets for BRAID
• AUCIL: An Auction-Based Inclusion List Design for Enhanced Censorship Resistance on Ethereum
• MEV resistant dynamic pricing auction of execution proposal rights
• FOCIL CL & EL workflow
• Mechan-stein (alt. Franken-ism)
• 11 more

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