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

本文介绍了Fork-Choice enforced Inclusion Lists (FOCIL)，一种基于委员会的简单IL设计，旨在通过让验证者对构建者施加约束，强制在其区块中包含交易，从而增强以太坊的审查抗性。FOCIL通过选择IL委员会成员、收集本地包含列表并由出块者聚合成一个简洁的聚合列表，最后由证明者评估聚合列表的质量来实现。

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

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

作者：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. 证明者根据他们自己对传播的本地列表的看法，评估聚合列表的质量，以确保区块提议者准确报告可用的本地列表。

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

引言

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

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

在这里，我们介绍 FOCIL，一种基于委员会的简单设计，改进了以前的 IL 机制（Forward ILs，COMIS）或共同创建的区块（CBP），并解决了与 贿赂/勒索攻击，IL 伪造，账户抽象 (AA) 和激励不相容等问题。另请注意 Vitalik 最近的提案“ One-bit-per-attester inclusion lists”，其中被选出构建列表的委员会本质上是整套证明者。

设计

在本节中，我们将介绍 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.51 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} 接受可用的本地 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}$，并且提议者未包含 \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}，了解了区块 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} }

  • \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) liveness（活跃性） 之间的权衡，因为如果标准设置得过于严格，我们可能会看到错过的 slot 数量增加。**

  • \text{Valid} 函数编码 \text{IL}_\text{agg} 是否符合预定义的核心 \text{IL} 属性，例如：
    • Conditional vs. Unconditional（条件与非条件）：只要有剩余空间，提议者是否应该在区块中尽可能多地包含 \text{IL} 交易，或者是否有为 \text{IL} 交易保留的专用区块空间？
    • Where-in-block（区块中的位置）：\text{IL} 交易应该包含在区块中的什么位置？它们应该放置在任何位置、区块的顶部还是区块的末尾？
    • Expiry（到期）：交易一旦包含在 \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} 委员会成员的具体细节超出了本文的范围，因为以激励兼容的方式分配奖励，尤其是在拥塞期间，会变得非常复杂。

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

  • 选项 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 中，整套 attester（证明者）现在参与强制执行并确保包含在提议者区块中的 \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} 提议者包含“良好”交易。依赖利他主义行为可能没问题，但如果没有任何激励获得，那么只有极少数验证者会选择参与该机制始终存在风险。强烈认为，如果验证者通过揭示其偏好而面临着被标记为非审查或审查实体的风险（请参阅 Anonymous Inclusion Lists 文章），并且如果他们没有因贡献于保护网络的抗审查属性而获得奖励，那么任何 \text{IL} 机制的采用率可能会非常低。在 FOCIL 中，我们考虑在 \text{IL} 委员会成员之间分配奖励的机制，并提到用于基于在其本地列表中包含的交易的数量（即计数）和唯一性来共享交易费用的两个选项（\text{Payment} 规则部分中的 选项 2 和选项 3）。我们希望继续朝着这个方向努力，并找到激励兼容的方式来增加审查成本。

同 slot（区块时间）审查阻力

通过让 FOCIL 在 slot n-1 期间与区块构建并行运行，我们可以通过在本地 \text{IL} 中包含在同一 slot（区块时间）期间提交的交易来对该区块施加约束。这是对 \text{fILs} 设计的严格改进，其中前向属性对 \text{IL} 交易施加了 1 个 slot 的延迟。此属性对于可能因 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} 交易。需要更多的研究来确定区块填充的可持续性，因为 连续的完整区块会呈指数级增加基本费用 以及该策略的总体成本。

账户抽象 accounting（会计）

在先前的提案中，\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 中插入使 \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 交易已触及该地址。 在任何一种情况下，该地址都在区块中进行了交易，并且该条目已满足。

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

  • 原文链接： ethresear.ch/t/fork-choi...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文， 用中文传播以太坊的最新进展

以太坊中文

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！