无状态FOCIL的深入分析

对无状态 FOCIL 的深入分析

本文档是以下人员共同努力的结果：

Ignacio Hagopian、Guillaume Ballet、Thomas Tiery、Julian Ma 和 Carlos Perez。

简介

以太坊的路线图包括旨在提高可扩展性、去中心化和抗审查性的宏伟提案。其中两个提案是 以太坊无状态性——消除或减少某些类型的节点（如验证者）存储整个状态的需求——以及 EIP-7805 中定义的 强制包含列表分叉选择 (FOCIL)，它使用验证者委员会来强制将某些交易包含在区块中。单独来看，每种方法都解决了不同的问题：无状态性解决了不受限制的状态增长问题和节点资源需求，而 FOCIL 则解决了交易审查问题。然而，结合起来，这些提案必须和平共处。本文档深入分析了无状态性和 FOCIL 如何在以太坊的演进中相互受益，每种类型的无状态性对区块生产者提出的要求和场景，以及当两种机制都处于活动状态时可能出现的摩擦点和网络开销。

我们还将讨论诸如交易失效、网络开销、带宽消耗等开放性问题，并评估无状态性技术是否有助于缓解这些问题。

文档将假定下列所有概念都已熟知和理解。如果你不确定是否完全理解它们，建议你查看一下。

以太坊中的无状态性方法和区块生产者要求

以太坊向“无状态以太坊”的推进涉及几种模型，这些模型在 状态存储程度 以及谁负责提供状态数据（通过 证明，即状态的加密证明，请在此处查看更多相关内容）方面有所不同。

FOCIL 和无状态性的主要接触点之一是，它们分别对证明者和区块提议者的角色产生重大影响。一种可能会降低对它们提出的硬件要求。而另一种增加了通过 IL 确保抗审查性的额外任务。

下面我们概述主要的无状态性方法——完全无状态性与部分无状态性——以及每种方法对区块生产者意味着什么。

弱无状态性（部分无状态性）——*“验证者无状态，区块生产者有状态。”*

在弱无状态设计中，只有区块提议者/构建者需要完全访问全局状态，而所有其他节点都可以在没有本地状态数据库的情况下验证区块（无状态性、状态过期和历史过期）。

验证者验证新区块时，会收到区块中每个状态访问的证明（例如，Merkle/Verkle/ZKVM 证明），这使他们能够更新其状态根并确认区块有效性，而无需存储整个状态。

这种方法大大降低了大多数节点的硬件要求（从而实现近乎即时的同步，甚至移动电话验证者），但它给区块生产者带来了压力，要求他们维护完整的最新状态，以便执行交易并为其区块生成证明。在实践中，弱无状态性假定角色分离（例如，通过提议者-构建者分离，PBS），其中专门的构建者处理繁重的状态和证明生成任务。弱无状态性下的区块生产者必须是强大的、有状态的节点（或外包给此类构建者），因为他们需要访问待处理交易触及的任何部分的状态，才能创建必要的证明。

强无状态性（完全无状态性）——“没有节点存储完整状态；所有状态数据都根据需要传递。”

强无状态性是理想的最终状态（因为我们大幅降低了所有共识参与者和可能的执行参与者的硬件要求），其中没有验证者或区块构建者永久存储全局状态（无状态性、状态过期和历史过期）。相反，交易必须携带足够的证明数据（账户/存储值的证明），以便任何人都可以针对已知的状态根验证它们。此模型中的区块生产者不需要预先获得整个状态；从理论上讲，他们可以依赖随交易提供的证明，或者根据需要从分布式存储网络获取所需的状态位（为什么实现无状态如此重要 | Dankrad Feist）。

然而，在实践中，实现完全无状态性具有挑战性。它将状态可用性的负担主要推给用户和网络——用户可能需要获取证明并将其附加到他们的交易中，并且区块构建者可能仍然维护最近使用的状态的缓存或使用按需状态获取协议以提高效率（为什么实现无状态如此重要 | Dankrad Feist）。

区块生产要求：

即使不需要任何节点始终持有所有状态，提议者也必须确保其包含的任何交易都具有有效的、最新的证明（否则该区块将无效）。如果自交易形成以来状态已更改，这可能涉及重新生成或更新证明。因此，在强无状态体系中，区块生产者可能仍然执行适时状态查找或缓存。期望加密累加器结构（例如 Verkle 树）将使证明变得小巧且易于传输，并且像 Portal 网络 或 PeerDAS 这样的协议将能够从对等方快速检索状态数据，并在需要时进行检索。

强无状态性以显着更多的实时数据检索为代价，最大限度地减少了永久存储；区块构建者需要极其强大的网络，并且可能需要用户提供的证明，才能在紧张的时间限制下组装有效的区块。

状态过期（状态租金）——定时部分无状态性 减轻状态负载的另一种方法是 状态过期，它可以被视为部分无状态性的一种形式。

在状态过期提案中，长时间（例如约 1 年）未访问的状态部分将从活动状态中删除，并被视为 非活动状态，直到“复活”。然后，节点仅存储最近活动的状态；访问旧状态（过期的帐户或存储插槽）需要证明或证明才能将该数据恢复到活动集中。这在概念上类似于对状态收取 租金：帐户必须定期支付或触摸才能保持活动状态，否则其数据将被删除，并且必须通过明确的证明将其带回。

区块生产者要求： 在状态过期场景中，预计区块提议者至少存储 活动状态（所有尚未过期的帐户/存储），并像往常一样处理正常交易。但是，如果交易触及过期状态，则区块生产者将需要该状态部分的相应证明（证明）。

否则，生产者必须从某些外部来源（例如分布式存储网络或存档节点 例如 Portal 网络）获取历史状态数据，然后才能包含该交易。这在区块构建中引入了额外的开销（类似于强无状态性），但仅适用于冷门/过期状态访问。实际上，状态过期将长期状态存储外包给链下系统或用户，限制了链上状态大小的增长，同时要求区块构建者处理偶尔出现的大型证明，以便恢复数据。区块生产者还需要确保 过期状态交易支付适当的费用（涵盖证明验证和状态恢复的额外成本），正如在状态租金经济学中所讨论的那样。

总之，弱无状态性 使区块构建与今天类似（一个具有完整状态的参与方），但解放了其他人，而 强无状态性 则将区块生产彻底改变为按需数据检索过程。状态过期 介于两者之间：大多数区块仅处理活动状态的子集（从而使区块生产快速），但偶尔一个区块必须通过证明来承担包含先前过期的状态的成本。所有这些方法都力求使运行节点更容易（减少持久存储），但代价是增加了 每个区块必须携带或提取的实时数据（即证明）。下表总结了每种场景中区块生产者的要求：

FOCIL 概述（强制包含列表分叉选择，EIP-7805）

FOCIL 是一种 分叉选择规则修改，它引入了 包含列表 (IL)，通过在验证者（证明者）委员会中分配区块内容（交易）决策，来加强以太坊的抗审查性。在今天的以太坊中，单个区块提议者（或其外包给的 MEV 构建者）完全控制哪些交易包含在区块中。这集中了权力，并导致了 寡头垄断的区块生产——截至 2024 年底，两个实体构建了以太坊上 95% 以上的区块——以及 薄弱的抗审查性，一些构建者排除 受制裁 的地址证明了这一点。FOCIL 旨在通过确保 许多验证者集体 影响每个区块的内容来对抗这种情况。

FOCIL 机制的图示（每个Slot的工作流程）。

• 在每个Slot \(n\) 中，一个 包含列表委员会 观察内存池，并且每个成员都生成一个交易的 本地包含列表（例如，包含“tx \(\mathbb{a}\), tx \(\mathbb{b}\)” 等）。
• 这些 IL 在全局网络主题上进行八卦。Slot \(n\) 的区块生产者收集这些 IL，并且必须将 IL 中所有交易的并集包含在该区块中，直到该区块已满。

IL 聚合包括委员会列表中的所有交易（此示意图中的条目 0xa1、0xb2、0xc3）以及哪些委员会成员的 IL 得到了遵守的位列表。Slot \(n + \mathbb{K}\)（右侧）的证明者评估区块 \(\mathbb{K}\)：如果它包含所有必需的 IL 交易，则他们认为该区块在分叉选择中有效；如果不是，则他们拒绝证明。因此，只有包含委员会交易的区块才能成为规范区块。*

有关 FOCIL 如何工作的更多信息可以在下面的隐藏部分中找到，也可以在此处找到：https://meetfocil.eth.limo/。

FOCIL 的工作原理（更深入一些）

• 在每个Slot中，会随机选择验证者的一个子集作为 IL 委员会（即，在当前提案中每个Slot 16 个成员）。在整个Slot *N* 中（在处理另一个区块时），这些委员会成员独立地从其本地内存池视图中收集交易，并构建一个包含列表（直到大小限制，即每个列表 8 KiB），其中包含他们认为应该包含在下一个区块中的交易。

• 他们通过 p2p 网络广播这些列表，供其他验证者接收。当新的提议者准备好构建区块 $n + \mathbb{K}$ 时，他们将收到多达 $m$ 个包含列表（每个委员会成员一个）。

• 在构建区块时，提议者（或与其合作的外部构建者）必须包含它已收集的所有 IL 中的所有交易。这些交易可以放置在 区块中的任何位置（FOCIL 不规定排序），只要它们包含在 某个位置 即可。

  FOCIL 甚至允许 有条件地包含（如果无法包含来自 IL 的交易（即，区块已满或该交易已失效），则在某些条件下仍然可以接受该区块）。

• 一旦提议者包含了 IL 交易，它就会发布该区块。然后，该Slot的证明者只有在该区块 满足包含列表约束（即，包含所有 IL 交易）时才会对该区块投赞成票（证明）。如果区块省略了任何必需的交易，那么诚实的证明者将拒绝投票支持该区块，从而导致该区块无法通过分叉选择规则，并且无法成为规范区块。通过这种方式，分叉选择（具有投票的“最重”链）强制执行包含列表。

无状态性和 FOCIL 的交互

明确的共生关系领域/迹象

很明显的一件事是，无状态-FOCIL 将始终是一个正和博弈。

有几个理由可以论证这一点：

无状态性将显着降低验证者的硬件要求

这意味着我们能够在 CL 中拥有更多的参与者。

这直接转化为更多能够加入 FOCIL 协议并提交 IL 的实体。

无状态体系允许更多的协议参与者（类似于 rainbowstaking）。如果你可以将 FOCIL 包含者的工作开放给权益较低的人员，那将是 democratizing Ethereum staking。

虽然这是事实，但同样重要的是要指出，FOCIL 不需要有数千个 IL 或每个 IL 中包含大量交易才能有效。

事实上，正如 Thomas Thiery 所说：

“……对我来说，IL 越多（更准确地说，IL 中的交易越多），交易包含时间越短，直到你达到一个限制

这个限制是 1 个Slot包含，并且你无法包含比区块空间更多的交易。”

因此，无状态性在这里具有双重影响。它允许：

1. 显着提高 gas_limit 参数。
2. 消除 FOCIL 协议参与者的硬件要求。

它们都有助于抗审查性和中立性。

这是最直接的协同领域。FOCIL 明确旨在提高抗审查性：通过分叉选择将包含列表强制到区块中，它可以确保没有交易被长期审查。

• 无状态性以一种更微妙的方式提高了抗审查性。首先，如前所述，它增加了可能的独立验证者的数量——当有成千上万个全球分布的验证者是协议采样域的一部分时，审查交易要困难得多，至少其中一个验证者很可能在其 IL 列表中包含任何给定的诚实交易。

FOCIL 的 “N 中取 1” 诚实假设 在 N 很大时更容易满足。

• 其次，无状态性可以在网络层启用新的 反审查技术：例如，抵御基于状态的审查——如果攻击者试图通过膨胀状态或利用状态负载来审查（一种拒绝服务形式，以使诚实节点的价格过高），那么无状态客户端将免受状态膨胀减速的影响，因为它们不会为每个区块处理整个状态。这意味着即使在高负载或试图进行状态层攻击的情况下，无状态验证者也可以保持正常运行，提出包含列表并验证区块，从而维护抗审查性。

总之，无状态性提供了一个 健壮、轻量级的验证者基础 和处理额外数据的技术手段，而 FOCIL 提供了 策略和规则集，使这些验证者能够保持链的中立性和包容性。

无状态-FOCIL 将提高可扩展性

无状态-FOCIL 解决方案可能会在某些领域以积极的方式影响可扩展性。例如：

• 消除对慢速磁盘 I/O 进行状态依赖——验证者不再需要每个区块读取/写入庞大的状态数据库，随着状态的增长，这可能会成为瓶颈。相反，他们会收到一个 固定大小的证明，证明状态发生了变化。这意味着当大多数节点处于无状态状态时，以太坊可以安全地提高天然气限制或吞吐量，而不会使验证速度过慢。
• FOCIL 通过确保交易不会因审查而无谓地延迟，间接 地帮助提高可扩展性。

更重要的是，FOCIL 还可以将 吞吐量与本地区块构建分离——验证者可以强制包含许多交易，即使构建者自己的区块会更小。在一种结合场景中，无状态性可以帮助处理 FOCIL 可能引入的 更高的数据负载。例如，如果每个区块现在都携带一个包含列表（或者来自 IL 的完整交易）以及相关的证明，那么无状态客户端可以验证这些更大的区块，而无需长期存储更多数据。

• 无状态性将允许显着增加 gas_limit。从而为交易开辟更多的空间。这个空间是构建者 可能被迫包含更多 IL 交易 的更多空间，这也促成了 有效地详尽使用 gas_target，而不是仅仅浪费它。

FOCIL 的强无状态性与弱无状态性

到目前为止，我们进行的最大辩论之一是试图确定在强无状态性与弱无状态性的困境中应该选择哪种方式。

有多种理由可以支持两者。

本文档不会深入探讨这一点。但你可以从 Julian 的这篇文章 中获得更多信息。

到目前为止，越来越清楚的一件事是，我们可能想要/需要 将吞吐量与本地构建分离，以便能够扩展整个网络（有关更多详细信息，请参见 此包含者-证明者分离）。

而且，这直接影响了我们想要拥有的无状态性类型。

特别是，如果我们打算将区块构建外包给少数资源充足（无论是在计算方面还是在带宽方面）的实体，并允许它们成为唯一的区块构建者，那么 显然会偏向于弱无状态性，在这种弱无状态性中，区块构建者仍然自己保存整个状态。

与此同时，这意味着我们需要尽可能地降低对证明者、包含者以及共识层中存在的任何其他角色的要求。

没有理由考虑强无状态性（这主要允许资源较少的构建者），也没有理由显着优先考虑状态过期。

一个可能出现的问题是“我们是否应该制定一个备用计划”？

为此，我们首先需要问自己以下问题：

谁持有状态？

重要的是要理解，在任何无状态场景中，我们只有 3 种类型的参与者可以/将会持有状态。以及这如何影响其他以太坊子协议（如 FOCIL）。

区块构建者

• 这篇文章清楚地将区块构建者确定为最值得信赖的持有状态的实体（至少是大部分状态）。特别是如果我们考虑像 将吞吐量与本地构建分离 这样的举措。这是最简单、最不复杂的方法，但会进一步极大地集中区块生产。与此同时，它会增加可能需要“备用方法”的额外风险。不过，由于有像 FOCIL 这样的子协议，我们实际上可以在这种情况下“更安全”一些。

• 重要的是要注意，从长远来看，将状态存储任务留给区块构建者将比将其委托给 Dapp 或用户受到更大的限制。因为分布式存储设计肯定会扩展得更远、更好。还可以大大减少协议其他部分的摩擦和激励问题。

• 如果我们降低区块生产者的准入门槛（通过强无状态性），但他们仍然将区块构建委托给 MEV 构建者，那么我们实际上什么也没改变（存在更多的区块提议者，但最终的构建者是相同的）。

Dapp/钱包（用户）

• 如果我们忽略将其付诸实践的复杂性，这可能是“最佳解决方案”。一种分布式存储和为 Tx 生成证明的方式总是比任何其他替代方案都要扩展得更好。

问题在于 协议需要“快速/JIT 无效交易证明重新计算”（就像 FOCIL 可能需要）。更重要的是，谁将实际执行此操作？ 因为在这种情况下，区块构建者如果想要这样做，就需要向某人索取证明。否则，我们将陷入交互式场景，即使想象也很复杂。

• 即使我们处于强无状态体系中。区块构建者也可能会决定至少存储部分状态，以优化其区块构建过程。因此，我们可能会发现自己处于这样一种场景，即我们旨在降低区块生产者/构建者的资源。但他们仍然决定这样做。
• 我认为现在很难看到有用/不错的 dApp。想象一下，如果我们将管理每个交易的所有状态证明/见证生成的负担也添加到它们身上……

似乎至关重要的是，要对 dAPP 设置绝对最低的要求，因为它们是生态系统中稀缺的资源。我们需要让他们更容易生存和繁衍。

状态即服务（即 Portal、第三方）

• 可悲的是，像 Portal 这样的去中心化解决方案 可能无法足够快地提供状态。因此，无法通过委托给其他子协议使其成为水平扩展的可行选择。

• 如果没有其他人处理，大型提供商（即 Infura） 将会处理，从而导致 重新中心化。

应该更仔细地考虑这个想法。到目前为止，这似乎不是一个可行的想法，因为承担它的两个主要竞争者不够快或导致大规模的中心化。

总而言之，我认为构建区块提议者/构建者困境的一个重要方法是：

我们正在建立“关于假设区块生产者持有/拥有的数据的最小规则集”。这样，我们就可以基于这种假设设计协议，这些协议可能会触及可能无关的事情。但可以依赖于基于这些规则的假设

无状态性和 FOCIL 之间的摩擦点

虽然无状态性和 FOCIL 的结合提供了许多好处，但也存在重要的 缺点和摩擦点 需要考虑。同时实施这两者可能会带来与交易有效性、数据开销和系统复杂性相关的新挑战：

IL 质量显着下降

到目前为止，这是最需要解决的相关问题。

当任何形式的无状态性（除了部分无状态性，但即使部分无状态性是否可以称为“无状态性”还不太确定）和 FOCIL 放在一起时，就会出现此问题。

问题：无状态节点在保持内存池修剪方面存在严重问题。而 FOCIL 依赖于具有正确修剪和正常运行的内存池的假设。

目前，在强无状态和弱无状态模式中，包含者都不会持有允许他们验证交易正确性的状态（丢弃无效交易），除非：

• 它们带有证明（强无状态性）。
• 它们向一些第三方或区块构建者询问与交易相关的所需证明（弱无状态性）。

这两种解决方案都不好。前者意味着 DevX 和 UX 方面存在重大负担，而后者大大地集中了状态存储，并且有可能消耗大量的带宽和网络资源。

为什么这很重要？请注意，攻击者可以免费地淹没内存池，并且包含者无状态节点很难修剪它，从而导致 IL 中充满了垃圾。

这意味着什么？

• 对于我们收到的每个交易，我们需要查询/验证 nonce。并且在每个新区块之后，还需要定期修剪内存池。
• 对于我们收到的每个交易，我们需要查询/验证 balance。并且在每个新区块之后，还需要定期修剪内存池。
• 更重要的是，我们需要确保在不尝试挂掉的情况下收集这些信息不是不可能的。（即，假设我收到 100 万个进入我的内存池的交易。我将需要处理大量的证明验证，或者从 GOOD_SAMARITAN 中查询大量数据，以便确定交易是否有效并应该进入我的 IL）。

网络开销和带宽消耗

无状态性和 FOCIL 都引入了每个区块中需要传输的额外数据，从而引发了对 带宽和存储开销 的担忧。在无状态性下，每个区块都携带一个见证（Merkle/Verkle 证明），以证明其交易访问的状态。与此同时，FOCIL 每个Slot最多增加 \(m\) 个通过网络传播的包含列表。如果每个 IL 最多为 8 KiB 并且有 16 个委员会成员，那么理论上会在八卦传播中广播 128 KiB 的数据用于 IL（不包括签名和路由的开销）。

总的来说，区块数据大小 和 每个Slot的八卦负载 都会增加。这引发了几个问题：

• 验证者的带宽和传播时间：无状态验证者 必须下载区块体 + 见证（假设根据树/解决方案的不同，大约为 200KB-3MB） 加上 IL（另外大约高达 100+ KB），用于每个Slot。此外，我们 仍然需要考虑 blob 数据（使用 EIP-4844 引入），这会显着增加带宽要求，每个 blob 大约增加 1 MB（按照 Pectra 更新（9 个 128KB 的 blob））。如果每 12 秒出现一个区块，这会显着提高数据速率要求。互联网速度较慢的验证者可能会遇到困难，从而破坏了增加共识参与者数量的目标。

此图像来自 pop 关于将 Pectra 的 blob 数量翻倍的帖子，可以帮助我们了解根据发送的有效负载大小，我们可以预期什么样的传播时间。

正如可以看到的那样，无状态-FOCIL 的外观有点令人担忧。

下一步之一将是使用 Ethshadow 运行一些准确的模拟，以更好地估计对于不同的无状态解决方案（Verkle、Binary 等等），我们可以预期什么样的带宽/传播时间。

• 最坏情况下的见证大小： 在病态场景中，FOCIL 可能会强制包含触及 许多不同的状态条目 的交易，从而产生庞大的组合见证。

一个担忧是 FOCIL 可能会 覆盖构建者的优化，这意味着即使构建者通常会避免在一个区块中包含过多的状态密集型交易（以保持见证较小），但如果 IL 强制这些交易，则区块的见证可能会爆炸。这是一种在组合的无状态+FOCIL 操作下需要考虑的新型区块大小悲伤攻击。

见证生成复杂性和延迟

在弱无状态场景中，区块构建者（提议者）也承担了生成见证的任务。在 FOCIL 下，构建者现在在一个区块时间间隔内有一个 扩展的待办事项列表：

1. 接收 IL，
2. 获取这些交易（如果尚未在其内存池中）
3. 以正确的顺序执行所有交易（无论是其自己选择的交易还是强制的 IL 交易）。
4. 为要广播到验证者的整个区块生成状态见证证明。
5. 参与任何需要发生的与 DAS 相关的程序。

所有这些都必须在几秒钟内完成（在 12 秒的Slot中，IL 可能会在Slot的 ~8 秒时完成，可能留下 ~4 秒用于区块生产）。这比正常的 区块构建更紧张，在这种情况下，构建者可以更早地使用已知的内存池开始组装区块。

这现在不是问题。但是，如果我们决定将天然气限制提高到例如 1 亿，那么我们肯定会开始看到复杂的情况，在这种情况下，IL 会强制构建者为其区块执行更复杂和更大的状态证明。这可能会大大收紧协议中的每个人履行其职责的时间。

开放的 FOCIL 问题和无状态性的作用

无状态以太坊是 前沿研究，仍然存在许多悬而未决的问题。我们研究了无状态-FOCIL 设计中的一些已知的开放问题。

包含列表泛洪攻击

FOCIL 的一个担忧是，攻击者可能会试图用垃圾交易“泛洪”该机制。例如，提议者可以在 IL 委员会完成其列表之前，用 看起来有效 的交易来垃圾邮件内存池，从而导致许多 IL 条目被提议者控制的交易占用，然后提出一个使所有这些交易无效的区块。结果是所有这些 IL Slot都被浪费了，并且该区块仍然以空洞的方式满足 IL 条件。

这是一种 事后失效攻击。FOCIL 设计试图通过诸如“每个 IL 每个帐户最多一个交易”（因此一个交易不能使多个 IL 条目无效）之类的规则来限制影响。

无状态性在这里有帮助吗？不是直接在预防方面——这主要是内存池策略和成本的游戏。但是，无状态性可以帮助检测和分析：保持所有 IL 交易的见证的无状态节点 可以立即在下一个区块中检查哪些交易变得无效以及原因。

如果他们注意到，例如，区块中的单个交易更改了 1000 个帐户的 nonce（因此使 1000 个 IL 交易无效），则该模式可以标记为恶意。仍然有待观察的是，除了识别之外，是否还有其他好处可以实际解决某些问题。

交易有效性窗口

FOCIL 和强无状态的交叉点的一个错位是 交易有效性随时间变化。在强无状态环境中，交易可能带有仅对特定状态根有效的冷状态（状态恢复）证明。如果状态发生变化，则交易可能会变得无效，或者至少证明无效（交易可能仍然可以执行，但不能使用提供的证明）。然后，无状态客户端可能会将该交易视为无效，直到提供新的证明为止。这实际上给了交易一个 保质期——如果交易没有及时包含或更新，它们会在内存池中过期。

请注意，虽然这不是两者结合的问题，但 FOCIL 实际上可以帮助减轻或加剧这种情况：

• 恢复存储交易包含对无状态节点持有的状态不再有效的证明。因此，会占用 IL 中的空间，从而造成浪费。这将是 FOCIL 在 10 个Slot左右强制包含的结果。
• IL 泛洪获得了一个新的攻击向量，该向量基于状态恢复交易。

无条件 FOCIL 导致 IL 提升市场。

到目前为止，在本文档中，我们一直在讨论“有条件 FOCIL”。但是，也存在一个“无条件 FOCIL”变体，在此帖子 中提出了该变体。

两种方法之间的主要区别在于 有条件 FOCIL 意味着提议者/构建者仅当区块未满且交易仍然有效时才需要在区块中包含 IL 交易。

另一方面，无条件 FOCIL 会在区块内为 IL 交易保留空间。

无条件 FOCIL 的主要担忧之一是，它可能会开启一个我们显然不想要的 IL 提升市场。

经过一些讨论，无状态似乎对此没有太大帮助。

正如 Julian 在与此主题相关的讨论中所说：

[..] 我不相信无状态可以在这里提供帮助。IL 的设计应该使其无法外包给 IL-Boost 市场，无论创建 IL-Boost 在实践中是否困难。 我们已经有很多验证者 [..]

因此，为 FOCIL 提供更多的验证者或低权益验证者（例如，通过无状态性 + 彩虹质押实现）似乎无助于减轻这些担忧。

结论

以太坊的无状态性和 FOCIL 的结合代表了协议演进中一个潜在的改进，将状态可扩展性与抗审查的区块生产相匹配。我们的分析显示了一个清晰的共生关系：无状态性使更广泛的验证者能够以最小的硬件参与，而 FOCIL 授权这些验证者共同维护包容性和中立性，从而抵消了 MEV 沉重的区块构建的中心化。 它们共同解决了以太坊未来最困难的两个问题——状态增长的负担和区块提议中的审查/中心化的风险。

同样显而易见的是，它们可以很好地结合在一起。当一个允许增加 gas 限制时，另一个确保区块已满，并将本地构建与吞吐量分离。

这意味着更大的区块、更满的区块，同时具有抗审查性和 CR（共识规则）中更多的参与者。

不过，组合这些系统并非没有挑战。 正如所见，网络、用户体验、IL 质量和其他次要主题仍然是我们心头挥之不去的担忧，我们需要找到解决方案。

关于谁持有状态以及这如何影响 FOCIL 和其他子协议，很难说。 因为我们只是在猜测。

在这个主题中，有一件事是显而易见的。 也就是说，如果我们想要立即扩展，并且我们想要释放状态增长，我们需要准备好处理这种增长，而无需要求所有共识参与者升级硬件。

理想情况下，我们应该降低协议的准入门槛，并促进对 Includer、Attester 或 Staker 等低要求角色的存在。

无状态性-FOCIL 的结合就是一个明显的例子。

经过所有考虑，一种混合解决方案，可以激励提供状态证明以降低费用。

或者，某种形式的部分无状态性可能是好的第一步。 这样我们就可以分析它如何影响生态系统并进行扩展，而不会扰乱网络目前的工作方式。

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