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

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

focil => fossil => 协议固化

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

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

介绍

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

这推动了对研究的关注，这些研究旨在寻找允许验证者通过强制在其区块中包含交易来对构建者施加约束的方法。这些努力最近最终促成了前向 \text{IL}ILs (\text{fILs}fILs) 的第一个实际实现，该实现正在考虑包含在即将到来的 Pectra 分叉中（参见 设计，EIP，以及规范 这里）。然而，人们对 EIP-7547 中提出的具体机制提出了一些担忧，导致其被拒绝。

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

设计

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

高层概述

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

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

图 1. 图示说明了 FOCIL 机制。

机制

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

• 证明者的角色

  • Slot nn 的证明者接收区块 BB 并应用函数 \text{Valid}(B)Valid(B) 来确定区块的有效性。

  • \text{Valid}Valid 根据 \text{Eval}Eval 的结果以及核心 IL 属性（例如 有条件与无条件）来编码区块的有效性。

  • 以下是一些说明依赖于 \text{IL}IL 的有效性条件的情形：

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

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

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

  • 如果根据 \text{Eval}Eval，\text{IL}_\text{agg}^\text{proposer}ILproposeragg 与大多数证明者的 \text{IL}_\text{agg}^\text{attester}ILattesteragg 不重叠，则区块 BB 被视为无效。

核心 FOCIL 机制可以定义为：

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

MFOCIL=(Agg,Eval,Valid)

时间线

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

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

聚合、评估和验证函数

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

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

  • \text{IL}_\text{local} = \{\text{IL}_1, \text{IL}_2, \ldots, \text{IL}_m\}ILlocal={IL1,IL2,…,ILm} 是从委员会成员 mm 收集的本地包含列表的集合。
  • 每个 \text{IL}_i = \{\text{tx}_i^1, \text{tx}_i^2, \ldots, \text{tx}_i^{t_i}\}ILi={tx1i,tx2i,…,txtii}

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

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

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

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

Agg(ILlocal)=tx|tx∈⋃i∈mtxi

• \text{Eval}Eval 函数 供每个Slot nn 证明者用于评估区块 BB 中包含的 \text{IL}_\text{agg}ILagg 的质量。每个证明者在他们观察到的所有本地 \text{IL}IL 上计算 \text{Agg}Agg 函数，然后将他们生成的 \text{IL}_\text{agg}^\text{attester}ILattesteragg 与提议者包含的 \text{IL}_\text{agg}^\text{proposer}ILproposeragg 进行比较。然后可以定义 \text{Eval}Eval 函数，以便如果提议者的 IL_{\text{agg}}^{\text{proposer}}ILproposeragg 包含证明者观察到的大部分交易，则该列表有效，如参数 ΔΔ 所定义：

\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}

Eval(ILattesteragg,ILproposeragg,Δ)={Trueif |ILattesteragg∩ILproposeragg||ILattesteragg|≥ΔFalseotherwise

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

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

更多规则

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

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

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

• 用户根据他们分配给将其交易包含在区块 BB 中的价值进行竞标。他们需要考虑 FOCIL 机制 \mathcal{M}_\text{FOCIL}MFOCIL，还要考虑 EIP-1559 机制如何运作以设置其基础费用，表示为 \mathcal{M}_\text{1559}M1559。例如，用户 tt 进行竞标 b^t(v^t, \mathcal{M}_\text{FOCIL},\mathcal{M}_\text{1559}) = (\delta^t, f^t)bt(vt,MFOCIL,M1559)=(δt,ft)，其中 \delta^tδt 是最大优先级费用，f^tft 是最大总费用（即，基础费用 rr + 优先级费用 \delta^tδt）。
• 来自所有用户的竞标向量表示为 \mathbf{b} = (b^1, b^2, \dots, b^T)b=(b1,b2,…,bT)，其中每个 b^tbt 表示来自用户 tt 的竞标。
• \text{Payment}Payment 规则 p(\mathbf{b}) = (p_0(\mathbf{b}), p_1(\mathbf{b}), \dots, p_t(\mathbf{b}), \dots, p_m(\mathbf{b}))p(b)=(p0(b),p1(b),…,pt(b),…,pm(b)) 确保用户支付的费用不超过其优先级费用 \hat{\delta}^t = \min(\delta^t, f^t - r)^δt=min(δt,ft−r)。在此，p_0(\mathbf{b}p0(b) 表示支付给区块生产者的费用，p_t(\mathbf{b}pt(b) 表示用户 tt 向所有其他 \text{IL}IL 委员会成员支付的费用，其中用户集合的大小为 mm，区块生产者以 0 为索引。

上面定义的 \text{Payment}Payment 规则旨在提供一个总体视图，说明如何跨 FOCIL 参与者（例如，\text{IL}IL 委员会成员、区块生产者）重新分配用户交易支付的价值，以激励被认为对网络有益的行为，在这种情况下，维护其抗审查性属性。激励 \text{IL}IL 委员会成员包含交易可增强机制的稳健性，从而增加 审查成本，或审查方必须支付给 \text{IL}IL 委员会成员以将其交易从其本地 \text{IL}IL 中排除的金额。深入研究构建者和 \text{IL}IL 委员会成员应如何获得奖励的具体细节超出了本文的范围，因为以激励兼容的方式分配奖励，尤其是在拥塞期间，会变得非常复杂。

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

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

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

\text{Inclusion}Inclusion 规则

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

\text{Priority}Priority 规则

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

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

改进和缓解措施

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

承诺攻击

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

拆分攻击和 IL 上的含糊不清

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

激励不兼容

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

同一Slot的抗审查性

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

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

账户抽象记账

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

然而，即使是已考虑包含在 Electra 中的有限形式的账户抽象（例如，EIP-3074 或 EIP-7702）也允许一笔交易触发 EOA 余额 的变化，而无需源自该 EOA。这引起了对之前 \text{fIL}fIL 提案的担忧**加粗，因为 proposer nn 在提议其 \text{IL}IL 时并不知道 builder $n$ 的 payload 中包含什么。这可能导致这样一种情况：proposer nn 在 \text{IL}IL 中包含了来自地址 AA 的交易 txn_AtxnA，而 builder nn 包含了一笔 EIP-7702 交易 txn_BtxnB，该交易源自地址 BB，但扫空了地址 AA 中的所有 ETH，从而使 txn_AtxnA 失效。因此，builder n+1n+1 将无法再包含 txn_AtxnA，尽管之前没有执行来自地址 AA 的其他交易。换句话说，ILIL 摘要将无法满足。

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

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

如果 nonce 发生了变化，则表示已执行了来自该地址的某些交易。如果 balance 发生了变化但 nonce 没有发生变化，则表示某些 AA 交易已触及该地址。在任何一种情况下，该地址都已在该区块中进行交易，并且该条目已满足。

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

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

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