EIP-7805：分叉选择强制包含列表 (FOCIL)

Ethereum Cat Herders 的 PEEPanEIP 第 141 期。主持人 Pooja Ranjan 邀请了以太坊基金会稳健激励小组 (Robust Incentives Group) 的研究员兼 EIP-7805 （在新标签页中打开） 的合著者 Thomas Thiery 和 Julian Ma，共同解释分叉选择强制包含列表 (FOCIL)：为什么以太坊需要协议层的抗审查性、该机制如何运作，以及目前的实施进展。

本文字稿是 Ethereum Cat Herders 发布的原视频文字稿 （在新标签页中打开）的无障碍副本。为提高可读性，已进行了轻微编辑。

简介 (0:35)

Pooja Ranjan： 大家好，欢迎来到 PEEPanEIP，这是唯一一个深入探讨以太坊改进提案 (EIP) 并探索其对生态系统影响的节目。这是第 141 期，由 Ethereum Cat Herders 为您呈现。我是主持人 Pooja Ranjan，今天我们要讨论的是 EIP-7805，即分叉选择强制包含列表 (Fork-choice enforced Inclusion Lists)。

EIP-7805 记录于 2024 年 11 月，是一项目前处于草案状态的标准跟踪核心提案。该提案旨在允许一个验证者委员会在每个区块中强制包含一组交易。该提案由 Thomas Thiery、Francesco D'Amato、Julian Ma、Barnabé Monnot、Terence Tsao、Jacob Kaufmann 和 Jihoon Song 共同撰写，目前正为未来的升级进行积极讨论。

在本期节目中，我们将探讨 EIP-7805 的细节、其含义以及它对以太坊生态系统的潜在影响。为了进一步讨论该提案，我们邀请到了 Thomas Thiery 和 Julian Ma。欢迎来到 PEEPanEIP。

Thomas Thiery： 感谢邀请。

Julian Ma： 是的，非常感谢邀请我们。

Pooja Ranjan： 我们很高兴能了解该提案的概述、目前的进展，以及我们多快能在以太坊主网上看到它。但在我们开始之前，我们的社区非常喜欢了解这些工作背后的研究人员和开发者。你们能分享一下关于你们自己、目前参与的项目，以及你们在以太坊生态系统中的经历吗？

嘉宾介绍 (2:14)

朱利安·马： 没问题，我先来。我是朱利安，和托马斯一样，是以太坊基金会稳健激励组 (Robust Incentives Group) 的研究员。稳健激励组非常广泛地关注协议的经济学。我们中有些人一直在研究交易费机制，比如 EIP-1559，其他人则在研究共识层攻击，主要是那些受经济激励驱使的攻击。

就我而言，我从研究基础费用衍生品的实习开始，之后转为全职。我主要致力于提议者-构建者分离 (PBS) 和与 MEV 相关的主题，现在我正专注于通过这个 EIP 中的 FOCIL 实现包含列表 (inclusion lists)，并期待证明者-提议者分离 (attester-proposer separation)。我想说，最让我兴奋的是通过这种从偏理论的工作开始，将其转化为有望在以太坊中提出并实施的 EIP 的流程，将研究投入到实际应用中。

托马斯·蒂里： 我是托马斯。我也在以太坊基金会的稳健激励组从事研究工作。我的背景其实是神经科学博士，这截然不同。但我对区块链和分布式系统产生了好奇，想尝试一些不同的东西，于是加入了一家名为 Dune 的加密货币数据公司。我在那里待了一段时间，但后来我怀念做研究的日子，很幸运能够加入以太坊基金会和稳健激励组，到目前为止一切都很棒。

我研究过类似的主题。我刚加入时，MEV 是个大热门。有趣的是，我最初发表的研究文章篇幅很短，但都是关于包含延迟 (inclusion delays) 和抗审查性 (censorship resistance) 的。直到最近我才真正深入研究它。在过去半年到一年的时间里，我在抗审查性和包含方面更加活跃。能够从研究想法开始，改进以前那些非常有趣但没有包含我们即将讨论的一些细节的想法，提出一个提案，到现在有了实现和开发网，而且与我交谈过的大多数人都认为这将是以太坊的一个很好的补充，这真的很棒。

普贾·兰詹： 感谢你们的分享。了解开发者的背景总是令人深受启发。看到他们来自不同的领域，并最终为以太坊生态系统做出贡献，这非常有趣。我知道我们今天有一个演示。那么事不宜迟，让我们来看看吧。

演示：FOCIL 的目标 (5:16)

朱利安·马： 太好了，非常感谢。我想先做一个简短的演示，介绍 EIP-7805（即 FOCIL）的工作原理以及我们究竟为什么要这样做。它的目的是抛砖引玉，所以不会太深入，以便为随后的讨论留出空间。

FOCIL 的主要目标是提高以太坊的可靠中立性。FOCIL 通过消除目前单个提议者或区块构建者在一个时隙内拥有的包含垄断来实现这一点。相反，FOCIL 允许多个验证者通过在每个区块中包含交易来共同构建区块。

更高层次的目标是追求一种我们称之为“链中立性”的属性，这意味着任何待处理的付费交易，只要它是可用的并且链上有空间包含它，就应该被包含在内。我们相信，如果这个属性得到充分满足，那么我们就能提高以太坊的可靠中立性。

为什么我们需要 FOCIL，为什么是现在？ (6:09)

Julian Ma： 为什么我们需要这样的机制？目前，几乎所有验证者都将区块构建外包给 MEV-Boost，这是一个协议外市场，构建者在其中竞标区块构建权。在这个市场中，真正占据主导地位的只有两个实体，这意味着 90% 的区块仅由两个实体构建。

我们在这里看到，以太坊已经无法再从本地区块构建中获得其可靠的中立性了。它曾经可以。最初，位于世界各地的提议者都在本地构建他们的区块，这意味着所有交易都会被包含在内。但现在区块构建被外包给了这些复杂的实体，这已经不够了。因此，有必要实施更强大的抗审查措施，而 FOCIL 是目前已知最好的方法。

为什么我们现在应该实施 FOCIL？你可能会认为构建者现在并没有进行太多审查，但他们随时可能开始审查，无论是出于监管原因还是经济原因。而且，绝对不要对经济审查产生误解。在审查相对较少的时候引入 FOCIL 也是一件好事，因为这样你就可以将其作为基准和默认设置引入。所有验证者都会制作包含列表，无论其司法管辖区或经济动机如何，这几乎不会引起市场不稳定。相反，如果你在所有构建者都在进行审查时引入 FOCIL，也许会更加困难。

此外，如今 Based 汇总正变得越来越普遍，它们将依赖以太坊的区块构建来承载负荷。如果我们想提供以太坊所具备的排序功能，就有必要通过 FOCIL 在这里实现可靠的中立性。

而且，FOCIL 可能会有助于扩容，这取决于你问谁。如今，以太坊仍然从本地区块构建中获得抗审查性。如果以太坊可以从其他地方（例如通过 FOCIL）获得抗审查性，那么也许我们可以提高对区块构建者的期望，并允许（例如）更多的斑点。但这也有可能在没有 FOCIL 的情况下完成。因此，已提议在弗萨卡中实施 FOCIL。

FOCIL 的工作原理 (8:10)

Julian Ma： 现在我将向大家介绍 FOCIL 的工作原理。我们将从基础知识开始，逐步深入，直到掌握完整的机制，然后探讨这个完整机制如何满足我们想要的属性。

包含列表（inclusion list）的基本概念（Mike Neuder 之前也提出过）是，存在一个交易列表，它以某种方式对区块进行约束。例如，有一个包含交易 A 和 B 的包含列表，它由协议认可的某人签名，然后这些交易必须被包含在某个区块中。FOCIL 并没有改变这一点。它以此为基础，更多的是关于谁来创建这个列表以及如何强制执行这个列表。

那么，谁来创建这个列表呢？这是 FOCIL 协议工作原理的第一步。在每个时隙中，会选出 16 名验证者作为包含列表委员会成员。这些委员会成员中的每一位都会观察内存池并构建自己的包含列表。一个包含列表的大小应在 8 KB 左右，或者大约包含 20 笔平均大小的交易，这意味着总共大约有 320 笔平均大小的交易。

第二步是分发这些包含列表。包含列表委员会成员通过全局主题（global topic）分发他们的包含列表，并且他们自己不会将这些列表包含在区块中。他们必须在时隙的第 9 秒之前完成此操作，此时证明者（attester）会冻结他们对本地包含列表的视图。正如我们将在下一步中看到的，证明者是实际强制执行这些包含列表的实体，顾名思义：分叉选择强制执行的包含列表（fork-choice enforced inclusion lists）。他们在第 9 秒冻结他们将要强制执行的包含列表视图，这可以防止视图分割攻击（split-view attacks）。区块生产者仍然有几秒钟的额外时间来观察包含列表，并确保它不会因为遗漏任何包含列表而受到负面影响，因此在这种设置下，区块生产者没有任何风险。

然后我们进入最后一步，即强制执行。正如我所说，强制执行是通过分叉选择来完成的。证明者只有在区块满足包含列表条件时才会为该区块投票。他们通过观察在全局主题上发送的包含列表，将在这些包含列表中看到的交易汇总成一个列表，然后检查所有这些交易是否都在区块中。如果检查通过，他们就会为该区块投票。也可能出现包含列表中的交易并未全部包含在区块中，但区块已满的情况。在这种情况下，证明者也会为该区块投票。因此，除非区块既没有包含这些交易又没有满，否则证明者都会为该区块投票。

总结一下完整的机制：在每个时隙中，会选出 16 名委员会成员作为包含列表委员会成员。他们观察内存池并构建包含列表对象，在截止时间（在本例中为第 9 秒）之前通过全局主题进行分发。构建者观察这些包含列表，并将它所看到的所有交易包含在其区块中。然后，证明者检查他们在第 9 秒之前在包含列表中看到的所有交易是否确实都在区块中。如果检查通过，他们就会为该区块投票，然后我们进入下一个时隙，再次重复相同的设置。

IL Boost 与不可拥挤性 (11:07)

Julian Ma：关于包含列表的一个主要担忧（在 Mike 提出的上一个 EIP 以及随后的开发过程中被提及）是“IL Boost”，或者说不可拥挤性。这指的是包含列表提议者可能会想要出售其构建包含列表的权利。这是一个非常合乎逻辑的担忧，因为我们在区块构建中看到了这种情况：出售这种权利会导致形成一个由复杂构建者组成的中心化市场。

我们认为，由于以下特性，FOCIL 能够有效抵御这些类似 MEV-Boost 的市场（俗称 IL Boost）。FOCIL 不保证任何交易排序。无论你将交易放在包含列表中的哪个位置，区块构建者都会以他们认为合适的方式对其进行排序。例如，如果你在列表中包含了一笔套利交易，构建者极不可能将你的套利交易放在区块顶部以便其真正执行套利。相反，构建者可能会自己执行该套利。

此外，私有订单流是不可能的。这些包含列表通过全局主题进行分发，因此在构建者构建区块之前，你的交易是公开的。私有订单流不可能通过包含列表进入区块。

第三，每个时隙有多个包含列表提议者。即使有有价值的东西可以出售，所有 16 名包含列表委员会成员都有相同的可能性来构建这个包含列表，因此这些包含列表提议者之间的竞争会将该价值压低至零。

最后，这些包含列表是在区块生产者行动前 3 秒创建的。在包含列表提交之后、区块生产者行动之前，会有 3 秒的额外信息到达，这通常对 MEV 类型的交易极其重要，这意味着几乎没有信息优势。实际上，对于那些试图将包含列表作为获取 MEV 工具的人来说，反而处于信息劣势。

基于这些原因，我们认为没有任何单个包含列表提议者拥有包含、排序或排除的权力，而这正是 MEV 的基本定义。因此，包含列表不应受到 MEV 的影响。

演示总结 (13:09)

朱利安·马： 总结一下这个简短的演示：FOCIL 允许多个验证者参与区块构建，防止单个提议者垄断包含权，并提升以太坊的可靠中立性。我们认为现在有必要实施 FOCIL，因为目前只有两个占主导地位的构建者，他们随时可能开始审查，这可能是出于他们可以从中获利的经济原因。区块构建可能会承受更大的压力，因为 based 汇总将希望使用以太坊的排序特性。当审查方较少时，FOCIL 的启动会顺利得多：首先，因为这意味着验证者构建包含列表是一种默认行为；其次，因为这意味着在进行审查的构建者和不进行审查的构建者之间，市场的不稳定性会更小。最后，FOCIL 可能会有助于扩容，这也许是我们能够深入探讨的一个主题。

感谢大家抽出时间观看这个简短的演示。我只想展示一下二维码，它指向该 EIP，供感兴趣的人查看。

普贾·兰詹： 非常感谢你带来这个简短的演示以及对该提案的概述。

问答：EIP-7805 与 EIP-7547 有何不同？ (14:17)

Pooja Ranjan： 我想以第一个问题开始问答环节，这个问题关于你在演示中也提到的早期提案：由 Mike Neuder 提出的包含列表（inclusion lists）提案 7547。我想了解该提案与我们在 7805 中提出的 FOCIL 之间的基本区别。你在演示中部分提到了 IL Boost 和不可拥挤性（uncrowdability）。你是否愿意再多解释一点？

Julian Ma： 也许 Thomas 最适合回答 7805 与 7547 有何不同，但我可以说一点。首先，FOCIL 是针对同一个时隙的，而 7547 是针对下一个时隙的。相同时隙的特性让一些事情变得更容易，因为这意味着包含列表不必存储在链上。

关于不可拥挤性，这是一个非常有趣且微妙的特性。在 7547（这是一个很棒的提案，我们的提案就是建立在它之上的）中，包含列表无条件地附加在区块的底部，并且由一个人制作。这与我们的提案有一些不同的特性。首先，交易是有序的。未来，区块底部的套利可能会非常有价值，事实上，Thomas 的一些研究已经强调了这可能是一个有价值的位置。拥有构建包含列表的权利意味着你是区块中最后一个采取行动的人，在某些情况下这可能很有价值。其次，它是由单个人制作的，因此在包含列表委员会成员之间不存在这种竞争效应。一个人的委员会拥有在区块底部包含交易的完全权利，这也可能使其更有价值。第三，存在这种无条件特性，这意味着无论区块生产者做什么，你的交易无论如何都会被包含在链上。因此，除了包含所需的最低限度之外，它还有一些额外的保证，这可能在某种程度上使其具有价值。

Thomas Thiery： 另一个很大的区别是我们拥有的包含列表提议者的数量。在之前的提案中，有一种机制，即时隙 n 的提议者制作包含列表，而时隙 n+1 的提议者需要强制执行它。这里有两件大事：首先，有一个时隙的延迟，因此包含列表中的交易只需由下一个提议者包含在下一个时隙中。而且实际上只有一个提议者制作包含列表。在 FOCIL 中，我们有 16 个。这产生了巨大的差异，因为现在我们只需要 16 个包含列表委员会成员中有一个是诚实的，整个机制就能按预期工作。它成倍增加了你实际拥有一个良好的抗审查机制的机会，而以前你只能依赖单一方。

然后是一些更技术性的细节：与账户抽象存在一些不兼容性，并且很难处理 IL 双签问题，即有人发送两个不同的包含列表。区块双签是已知的事情，并且会受到协议的惩罚，但由于在之前的提案中所有内容都在链上进行，你还必须处理奇怪的边缘情况，而且要适应它们并不容易。在 FOCIL 中，包含列表不会上链。它们只是通过 P2P 共识层网络广播。这有点技术性，但在处理由账户抽象引起的这些边缘情况，或者通过 IL 双签将网络分裂成两个视图的攻击时，它确实产生了很大的不同。

Pooja Ranjan： 非常感谢。对于想了解更多关于提案 7547 的人，我们确实有一期与 Mike Neuder 录制的节目，即 PEEPanEIP 的第 130 期，它提供了一个高层次的概述。我总是喜欢看到相互竞争的提案，因为我知道这是为了生态系统和链的更好发展。我看到聊天室里有几个问题。也许我想邀请 Kataya 分享她的问题。

提议者必须包含所有 16 个列表吗？(19:05)

Kataya: 你好，谢谢。我的问题是：区块提议者是否会收到 16 个包含列表（每个列表来自一名委员会成员），并且它是否必须包含这些列表中的所有交易？

Thomas Thiery: 是的，没错。你需要获取所有列表中所有交易的并集，在我们的例子中是 16 个列表。显然，可能会有重叠，所以你需要取并集并去重，但是的，所有列表中的所有交易都需要包含在区块中，才能被证明者视为有效。

Pooja Ranjan: 聊天室里的下一个问题来自 Justin。Justin，你想为嘉宾们读一下你的问题吗？

包含列表中的私有内存池交易 (19:55)

Justin: 我问了很多问题。我想问是什么阻止了将私有内存池中的交易放入包含列表中，我认为这个问题已经得到了很好的解答。听起来这完全没问题，考虑到构建者基本上会按照他们认为合适的方式对它们进行排序，而且当你的交易进入包含列表（IL）时，它也会公开。所以我觉得这说得通。谢谢。

Thomas Thiery: 正如 Julian 所提到的，这也是一个考量因素。我们真的不希望 FOCIL 和包含列表被用于包含 MEV 交易、私有订单流或预确认，因为我们最终想要的是抗审查性，如果不小心，一种机制很容易成为包含高价值交易的工具。事实上，当你将交易放入包含列表中时，它会自动公开，每个人都能看到它，它没有排序保证，并且可以被构建者包含在区块中的任何位置，这使得它非常不适合高价值交易。

因此，要么你有一笔公开交易，你可能只需将其提交到公共内存池，以便将其包含在包含列表中；要么你有高价值的私有交易，那么你就不会通过 FOCIL，因为有更好的方法来处理。你会直接联系构建者，并通过私有渠道发送。

Pooja Ranjan: 感谢分享。我看到下一个问题是 Ladislaus 提出的。

FOCIL 与扩容 (21:41)

Ladislaus: 大家好。这与你们提到的关于 FOCIL 和扩容的观点有关。正如大家所见，我最近也看到了一些关于以太坊扩容的讨论，而且正如你们正确指出的那样，目前存在少数几个构建者造成的瓶颈。我个人倾向于认为 FOCIL 是在重新赋能本地构建，并且我认为在增加带宽要求或总体节点要求之前，有必要将其纳入协议中。也许你们可以详细谈谈对此的看法，以及正如你们提到的，在没有 FOCIL 的情况下可能存在的其他扩容方式。

Julian Ma: 感谢你的提问。首先，关于通过 FOCIL 进行扩容的情况。目前 90% 的验证者通过 MEV-Boost 将区块构建外包，而这些复杂的实体显然拥有超过最低硬件要求的带宽。例如，它们可以在其区块中包含更多斑点而不会引发任何问题。然而，有趣的是，以太坊依赖本地区块构建来实现可信中立性或抗审查性，因为以太坊的抗审查性不能建立在这两个复杂的实体之上。

因此，以太坊协议的设计仍必须使得本地区块构建成为可能，事实上，我们的设计使其与 MEV-Boost 相比并非无利可图。这是以太坊设计中的一部分，但在实践中，MEV-Boost 显然要有利可图得多：首先是因为这些复杂的区块构建者拥有更复杂的算法，其次是因为它们拥有多得多的私有订单流。Data Always 最近的一项研究表明，MEV-Boost 区块包含的交易要多得多。单凭这一点就能带来更多利润。

尽管如此，协议的设计确保了协议规则内部没有任何力量会使一个验证者的利润低于另一个验证者。如果我们想保留这条规则，那么 FOCIL 就是必要的，因为这样本地区块构建者就可以为包含列表做出贡献，从而维护抗审查性。然而，我们也可以废除这条规则，基本上可以说本地区块构建者可以包含一定数量的斑点，但更复杂的区块构建者可以包含更多斑点，以至于本地区块构建者在自己创建区块时将无法处理这种负载。因此，如果我们想保留将最大值设置为最低硬件要求的规则，那么我们需要 FOCIL。如果我们觉得放宽该规则也没问题，那么在扩容方面我们可能就不需要 FOCIL 了。

Thomas Thiery: 我想这非常相似，但目前在以太坊上，我们处于一个奇怪的境地，因为我们依赖复杂的构建者来构建大多数区块，但这对搞审查性来说并不好，因为只有两方参与。如果他们出于某种任意原因决定审查交易或某些地址，那么基本上我们就失去了抗审查性或无许可性，而这同样非常重要。这意味着他们可以审查或限制任何他们想要限制的参与者在链上参与，这是非常糟糕的。

而且我们保留的抗审查属性并不理想，对吧？由于大多数区块都是由这两个构建者构建的，你基本上需要等到一个本地区块构建者被选中并提议一个包含所有这些通常被审查的交易的区块，这感觉并不好。这意味着这些用户将需要等待 10 个、12 个，我不知道，反正很多个区块，直到他们的交易真正被包含在链上。

因此，我们真的希望保留家庭质押者和本地区块构建者，因为他们是维护抗审查性的人。同时，在今天，即使使用他们也不是很理想，因为如果你的交易被这两个构建者审查，你仍然需要等待很长时间才能让其被包含。有了 FOCIL，你将进入这样一个世界：保证抗审查性的参与者（在我们的例子中是包含列表委员会成员）可能与构建区块的人不同。我认为这开启了一个非常有趣的局面，因为现在我们不必依赖完全相同的参与者来既构建有价值的区块又为抗审查性做出贡献。FOCIL 也可以被视为朝着这个重要方向迈出的第一步，因为你有两项截然不同的职责，而今天我们要求完全相同的验证者节点同时执行这两项职责，这在很大程度上是存在冲突的。

Pooja Ranjan: 非常感谢。我想下一个问题由 Luis 提出。

选择交易的标准 (26:46)

Luis Pinto: 我在开始几分钟后才加入，但在我看来，这似乎是在将整个网络中的交易选择去中心化。我认为这非常好；它可以对抗 MEV 和审查。而且我非常喜欢让证明者来做这项工作的部分，因为在未来，他们的硬件要求将低于构建者，在实现无状态和无状态客户端后更是如此。既然你能够以非常低的硬件配置运行它，这会让事情变得非常去中心化。我想这里的主要挑战是定义这些包含列表的交易选择标准，无论是根据优先费还是斑点数量；有太多的变量了。你们是否已经确定了一套打算强制执行的标准？

Thomas Thiery: 这是一个很好的问题。这包含两个方面。第一个方面非常重要，关于试图将证明者与构建或提议区块的人分离开来。这就是整个证明者-提议者分离 (APS) 的研究方向；Julian 在这方面做了很多工作。我们称之为角色解绑，这样它们就能更紧密地匹配协议的职责。我写了一篇文章（刚刚分享了），探讨了一种可能的分离方式，这是一个非常开放的话题，我很乐意听到更多人的意见。在这篇文章中，我将证明者、包含者（即现在的 IL 委员会成员）以及执行提议者（或构建者）进行了区分。我认为这些是根本不同的职责，也许我们应该为它们设定不同的角色。

然后，关于包含规则，这是一个非常好的问题。我们确实对此进行了大量思考，我想我们得出了两点结论。第一点是我们希望规则具有多样性。我们不希望只有单一的规则，例如所有客户端都按优先费降序排列，因为那样的话，你实际上可以玩弄游戏规则，尝试对内存池进行重新排序，从而使只有你的交易被包含在 IL 中。但是，如果你有多种规则，包括一种同时考虑交易在内存池中等待时间的规则，并且不同的客户端实现不同的规则（风格大致相同，主要围绕优先费和在内存池中的等待时间），那么这就非常非常难以被操纵，并且会使协议变得更加健壮。我认为，这也是利用当今以太坊上客户端多样性的一种好方法，并让客户端做出有主见的选择。我们心中有一些规则，但我们认为客户端也可以选择最适合他们的规则。只要不是每个人都使用完全相同的按优先费排序的规则，我们就没问题。

Luis Pinto: 好的，所以你们也在分配这个标准，让构建包含列表的人拥有自己的标准。还是说这将成为协议的一部分？

Julian Ma: 包含规则不会成为协议的一部分。首先，它很难强制执行，其次，实际上最好什么都不强制执行。如果我们允许委员会成员自行决定，或者让客户端团队代表他们决定如何包含交易，那么我们就能在网络中创造一些健壮性。具有不同偏好的人将以不同的方式进行包含，这意味着攻击系统会变得更加困难。

Luis Pinto: 好的，谢谢。

与 EIP-7702、ePBS 和 PeerDAS 的兼容性 (30:43)

Pooja Ranjan: 非常感谢。据我了解，该提案已经被提议用于佩克特拉之后的升级，即弗萨卡。考虑到弗萨卡可能会也可能不会包含其他正在进行中的 EIP，我想知道 FOCIL 与 7702（关于账户抽象）、ePBS 和 PeerDAS 等提案的兼容性状态如何。

Thomas Thiery: 很好的问题。由于包含列表（inclusion list）的历史，我们在这里有一些优势。正如我们提到的，7547 曾被考虑包含在内，但后来由于不兼容而被拒绝。因此，在提出新提案之前，我们非常谨慎地解决了这些问题，因为我们知道人们会带着同样的问题来看待它，这是合情合理的。

我们非常有信心，因为我们也与账户抽象团队进行了交谈，并且与 Potuz 和 Terence 进行了大量沟通。Terence 一直在积极帮助我们，他同时在参与 ePBS 和 FOCIL 的工作，因此我们很容易检查它们是否兼容。我真的认为它与其他任何 EIP 都不存在不兼容的情况。对于 ePBS，你必须小心处理时间安排，因为你将执行负载与共识区块分离开来，所以整个时隙的时间安排都会改变，而且现在你还增加了在提议负载之前需要创建的包含列表（IL）。所以你需要注意时间安排，但如果我没记错的话，从上次我们与 Potuz 和 Terence 讨论的情况来看，根本没有任何关键的不兼容性。我认为在兼容性方面我们做得很好。

Pooja Ranjan: 很高兴知道这一点。我注意到 Jihoon 也分享了一份 HackMD，我们将把它添加到资源中，供那些想专门了解与 ePBS 兼容性的人参考。是的，我记得在上次与 Mike 的交谈中，我猜该提案没有被包含在内是因为与账户抽象不兼容。所以很高兴知道这个问题已经得到了解决。

FOCIL 与多时隙 MEV (33:04)

Pooja Ranjan: 我在查阅添加到 FOCIL 网站 meetfocil.eth.limo 的文档和详细信息时，了解到了一个叫做多时隙 MEV 的术语。Julian 也提到，尽管开发者们希望并努力使其保持平衡，但 MEV-Boost 总体上是有利可图的。我想知道 FOCIL 将如何防止这种情况。

Julian Ma: 感谢你的提问。首先，让我谈谈 FOCIL 和 MEV，然后我们再讨论多时隙 MEV。FOCIL 并不一定会防止 MEV，这正是因为我们希望将 MEV 部分和包含（inclusion）部分解绑。在我们看来，这样做很重要，因为否则就会出现类似 IL Boost 这样的市场。按照这个逻辑，如果包含列表（inclusion list）能够限制可提取的 MEV 数量，那么构建包含列表就会变得非常有价值，人们就会围绕它建立市场。我们的设计实际上是为了提供最低限度的包含保证，这意味着成为包含列表委员会成员并没有那么大的价值，而且有 16 个这样的成员，这意味着不存在由复杂生产者组成的市场。

接下来，关于多时隙 MEV：FOCIL 缓解了部分问题，但并没有彻底解决。这同样是因为在提供抗审查性和解决 MEV 之间存在不兼容性。FOCIL 的作用是允许任何交易被包含进去，只要它支付了费用，这在一定程度上解决了多时隙 MEV 的问题。这里的多时隙 MEV 是指，如果某一方连续控制两个区块，它就能提取更多的 MEV。

FOCIL 缓解了部分问题，因为它允许你插入你的交易。例如，如果你需要插入一笔交易来清算某处头寸的坏账，即使提议者试图审查你并会在下一个区块中从你那里提取 MEV，你也能做到这一点。

它之所以不能解决所有问题，是因为逆向选择（adverse selection），这是一种一方比另一方拥有更多信息的经济学特性。多时隙 MEV 的一个例子是跨两个区块提取套利，区块构建者不在第一个区块中提取套利，而是在第二个区块中提取。一些理论结果表明，对于区块构建者来说，这比在两个时隙中都提取套利更有利可图。你可能会认为 FOCIL 在这里能帮上忙，因为套利者原则上可以将他们的交易包含在包含列表中，从而强制发生某种套利。虽然情况确实如此，但套利者将交易提交给 FOCIL 并不符合激励相容原则，因为在他们提交交易和区块构建者能够采取行动之间仍有 3 秒的时间差。如果你试图进行套利，而外部市场的价格在不断波动，你不会希望提前 3 秒做出承诺，因为你掌握的信息远少于比你晚行动的区块构建者。逆向选择之所以起作用，是因为构建者拥有更多信息：如果情况对你不利（即在这额外的 3 秒内，外部市场的价格走势对你不利），它就会让你赢；如果情况对自己更有利，它就会让自己赢。

因此，FOCIL 解决了多时隙 MEV 中交易不受逆向选择影响的那部分问题。对于存在逆向选择的交易，情况要稍微复杂一些，但它在一定程度上缓解了这个问题。原则上，它使情况比现在更好，但仍有一些工作要做。

Pooja Ranjan: 很好，非常感谢你的分享。我了解到目前有很多关于解决 MEV 问题的研究正在进行，所以很高兴知道至少在原则上，它会比目前的情况更有帮助。

权衡与挑战 (36:44)

Pooja Ranjan: 我有一个关于 Thomas 之前提到的 IL 双签的问题。我注意到在提案的安全注意事项部分，提到了很多点，比如共识活跃度、IL 双签和负载构建。你认为最大的权衡是什么，或者有什么可能需要更多研究，并可能阻碍该提案按原样进入下一次升级？

Thomas Thiery: 老实说，我认为安全注意事项部分主要是为了表明我们已经考虑并解决了有关安全的担忧。它更多的是展示这一点，而不是提出我们不了解的安全方面的未决问题。我不认为在安全注意事项方面有任何大的阻碍或问题。

至于权衡：如果你从一个非常狭隘的角度来看，FOCIL 确实给验证者增加了一些任务，无论是在他们必须提议包含列表时，还是对于证明者来说，当他们必须多检查一个条件以确保区块根据包含列表是有效的时候。它还为提议者增加了一项小任务，因为现在它需要确保其负载实际包含了 IL 中的交易。对我来说，这是唯一的权衡，而且这些任务并不繁重或复杂。IL 委员会成员只需监控公共内存池，并将交易包含在他们发送的列表中。这不需要任何技能或复杂的操作，我认为这很好。另一方面，正如我们所说，它可能会解锁一些重大的扩展性改进，并在协议内的参与者和职责之间实现更好的分离。

我可能有偏见，但我没有看到大的权衡。我确实认为，在抗审查性方面，它彻底改变了局面。现在你基本上只需要网络中 15% 的节点是诚实的，就能让所有交易（包括可能被构建者审查的交易）被包含在下一个区块中，这是一个非常大的改进。老实说，我不认为你在那里牺牲了很多东西。

Pooja Ranjan: 很高兴知道这一点。在大多数提案中，我们发现安全注意事项部分要么没有信息，要么信息很少，所以很高兴知道已经对这部分进行了研究，并且我们意识到了可能的安全注意事项。很高兴知道这不会成为未来实施和采用的阻碍或潜在挑战。

包含列表的交易费机制 (39:50)

Pooja Ranjan： 我有一个关于我在网站上发现的一些未决问题，是关于交易费机制的。我想知道是否有任何更新，或者你们是否愿意分享更多关于收取费用以及分配这些费用以将其包含在包含列表中的最佳方式。

Thomas Thiery： 我们有一项正在进行的资助，专门研究这个问题以及奖励 IL（包含列表）委员会成员的激励机制。这并不容易。这很棘手，而且无论你如何处理，这些都是非常大的改变。改变以太坊上的费用，无论你是更改费用、增加费用还是增加新的发行，所有这些都是需要大量考虑和谨慎对待的重大改变。但目前正在探索中，例如，在包含某笔交易的委员会成员之间分配费用的想法似乎是不错的主意。它在某种程度上具有我们想要的属性，因为我们希望奖励那些包含其他人可能不想包含的交易的人。所以我们正在非常深入地思考这个问题，并且我们有一项正在进行的资助。

还有一个问题是，我们是否真的想向 IL 委员会成员支付费用，因为众所周知，很难奖励分布在世界各地的小型参与者。你不希望发生女巫攻击，也不希望拥有大量质押的大型参与者挤出 IL 委员会集合。你如何防止这种情况？这非常困难。所以你需要考虑很多设计因素。

我最近的一个想法是：如果我们为 FOCIL 添加一些很酷的功能，比如隐私，这样你就无法真正知道是谁提议了给定的交易列表，会怎么样？你知道那是实际被选为 IL 委员会成员的人，但你不知道具体是谁提议了哪个列表，所以你无法将 IL 委员会成员与他们 IL 中的交易集合联系起来。如果我们能做到这一点，并让 IL 委员会的角色变成一种选择性加入的形式，那么我们可能会在协议中拥有诚实的参与者，依靠利他行为，也许我们根本不需要建立费用机制。这是一个非常近期的、带有个人观点的看法，目前正在大力探索中。所有这些都是关于“FOCIL 的未来”的讨论；它们不应该包含在当前的 EIP 中。

Julian Ma： 补充一点，最后一部分也非常重要：EIP-7805 不包含任何交易费机制，以使其更容易实现。它基本上是我们能够提供抗审查属性的最小可行方式，但它非常具有可扩展性。我们正在研究这个问题。Thomas 做了大量工作，研究为包含者和提议者分别设置交易费。然后，正如 Thomas 所提到的，我们与奈瑟曼德（Nethermind）的一位出色研究员有一项正在进行的资助，他正在研究为 FOCIL 创建一种交易费机制，这非常有前景。最后，还有一项针对 FOCIL 变体 AUCIL 的交易费机制的研究，AUCIL 是由 Sarisht Wadhwa、Fan Zhang 和 Kartik Nayak 以及几位 FOCIL 作者共同提出的一种基于拍卖的包含列表设计，该设计探讨了激励包含列表委员会成员的方法。

关于 Luis 之前的观点，激励在很大程度上与包含列表的创建方式有关。这意味着协议希望对包含列表委员会成员应如何表现提供某种视角。通常归根结底是它希望某些参与者做不同的事情。例如，它可能会对委员会成员进行排序，并通过相关均衡为他们分配某些交易，以便在委员会成员之间仍然保持一些不同的行为。所以它不是当前提案的一部分，但我们肯定在研究它，并且它符合 FOCIL 的可扩展性路线。

Pooja Ranjan： 哦，这很有趣。所以我们应该期待未来会有一些补充提案，以增强当前的 FOCIL 功能。

包含列表大小 (44:16)

Pooja Ranjan: 我还有一个问题。我不确定它是否应该成为当前提案的一部分，但我很想了解关于 IL（包含列表）大小是否有任何更新。包含列表可能必须限制大小，以防止占用过多带宽。关于如何确定包含列表的最佳大小，我们是否有进一步的研究或更新？

Thomas Thiery: 我们现在在规范中有一个固定的大小，并且已经存在一段时间了：8 KB。我们以千字节（KB）为单位，因为 FOCIL 和 IL 真正消耗的是带宽，基本上就是这样。如果以交易大小的中位数计算，每个 IL 大约包含 40 笔交易，如果所有交易都是唯一的，那么在所有 16 名委员会成员中，大约可以组合 640 笔交易。

我不知道关于确切的最佳大小是否还有很多研究要做。我们的选择是：16 乘以 8 KB 基本上是一个斑点的大小，所以加起来并不是巨大的带宽量。而且，由于跨 IL 的交易组合大于一个区块，我认为我们在那里不会遇到问题。

未来，你可以增加 IL 的大小，但也可以考虑增加 IL 委员会成员的数量。如果网络的大部分决定开始审查，这让你有更多机会获得一名诚实的 IL 委员会成员。所以这也是我们可以做的事情。目前来看，16 似乎完全没问题且足够了，但如果审查变得非常疯狂，或者我们需要采取更多行动，未来你绝对可以调整这些参数。

跟踪采用情况的指标 (46:39)

Pooja Ranjan： 这里补充问一下：你有没有想到哪些指标，我们可以通过跟踪这些指标来了解这个提案的采用情况或成功与否？

Julian Ma： 这是一个很好的问题。让我快速回答一下，然后把接力棒交给 Thomas。一些简单的指标就是有多少被提议的包含列表是非空的。你可以想象一些数据看板，比如 Toni Wahrstätter 的 “.pics” 系列，那里可能会有更多特色，为这些包含列表分配一些质量衡量标准。不过原则上，每个时隙只需要一个人制作一个合适的包含列表，就能提供抗审查性。

我认为这是非常重要的一点，尽快实施 FOCIL 很重要，因为现在我们处于一个神奇的时期，区块构建者没有进行太多审查，验证者也没有进行太多审查。我想说这非常脆弱。到目前为止，区块构建者已经审查了很长时间，如果我们现在引入 FOCIL，我们就有可能使其成为默认设置，让所有这些验证者都采用它并创建有意义的包含列表。因为区块构建者没有进行审查，所以这里不会产生市场不稳定性。如果我们等到构建者之间出现审查时再行动，那么引入 FOCIL 就会困难得多，而且我可以想象，所有用于衡量采用情况的指标都会糟糕得多。

Thomas Thiery： 另一个需要关注的关键指标实际上是公共内存池交易的包含延迟。你把所有在公共内存池中待处理的交易拿出来，看看它们被包含的速度有多快。如果 FOCIL 起作用，它们都将被包含在下一个区块中。如果没有，那就意味着很大一部分验证者在进行审查。所以我们可以看的另一个指标是谁在审查，以及网络中有多大比例在审查。我们将拥有数据看板和非常透明的指标来跟踪这一点，因为这基本上就是 FOCIL 应该做的事情。如果公共交易没有被包含在下一个区块中，那就意味着网络中很大一部分实际上正在审查这些交易。

Pooja Ranjan： 非常有趣。所以也许这对研究人员来说是一件事：一个可能的升级愿望清单，即每当一个提案被包含在网络升级中时，开发人员都应该分享该提案的数据看板和指标跟踪器。

客户端实现状态 (49:11)

Pooja Ranjan：正如 Julian 所提到的，这项提案可能需要尽快实施。我很想了解我们在客户端实现方面的进展，因为我记得在上次测试网电话会议中，Paritosh 提到要在开发网中添加一些支持。那么我们目前的进展如何？

Thomas Thiery：我们进展得非常顺利。首先，看到大家如何承担 FOCIL 的实现工作真的非常棒，因为我不是开发人员，我是一名研究员。我从一开始就和开发人员一起工作，但我并不是在客户端中实现这些功能的人。

带头做这件事的有三个人：来自普莱斯姆的 Terence，以及 Jihoon，他在普莱斯姆上帮了 Terence 很多忙，同时也参与了 Go以太坊 (Geth) 的工作。所以现在我们有了一个适用于普莱斯姆和 Geth 的可用开发网，这太棒了，而且正在进行大量的测试。我们现在还试图让 FOCIL 在 Dora 浏览器上显示和可见。然后是 Jacob，他参与了莱特豪斯和瑞斯的工作，我知道那里仍在进行一些努力。洛德斯塔最近非常活跃；我认为他们非常接近拥有一个可用的开发网。我们今天从奈瑟曼德得到了一些消息，他们已经有了一个原型，这非常好。我觉得我好像忘记了一些……Jihoon 说尼姆巴斯也加入了。这真的很棒。

总的来说，我们有越来越多的开发网准备就绪并上线，包括本地开发网，以及执行层和共识层客户端之间越来越多的组合。目前已经取得了一些非常好的进展，这让人很高兴，因为我们都知道开发人员现在非常忙，佩克特拉即将到来，而且他们已经在进行 PeerDAS 和其他工作。看到以太坊上的大家总体上都非常关心抗审查性，这真的很棒。大多数我没有专门联系过的团队都加入了这项工作，现在正朝着开发网和测试的方向努力。

Pooja Ranjan：感谢你的分享。我期待着跟进开发网的更新。我不确定这个开发网会有多少次迭代，但我很高兴看到它的出现。我看到 Justin 这里有一个问题。Justin，请讲。

FOCIL 是在弗萨卡还是格拉姆斯特丹中实现？ (52:07)

Justin: 好的，大家坐稳了。你提出了一个非常好的观点，即解决审查问题的最佳时机是在审查发生之前，对吧？那么：FOCIL 应该在弗萨卡升级中实现，还是可以等到格拉姆斯特丹？作为一名开发者，我应该主张哪一个？

Thomas Thiery: 我们已经提交了 PR 并且已被合并，提议将 FOCIL 纳入弗萨卡升级。我们认为它应该进入弗萨卡。部分原因是一些客户端已经开始着手相关工作，并且没有遇到太多障碍。它不像其他提案那样难以实施且涉及大量工作。而且它也没有太大争议。我认为没有人会反对抗审查性，大家基本都同意需要尽快将其纳入。所以我倾向于弗萨卡。

我不知道它是否能等。提案和升级总是可以等待的。我只是想避免陷入一种难以实施这些更改的境地。情况可能会迅速反转。正如我们所见，情况走向了另一个方向：几个月前，其中一个主要的构建者突然停止了审查。我们问为什么，他们的回答大概是，“是的，我们只是决定不这么做了。”在那种情况下是件好事，因为它是向好的方向发展，但它完全有可能再次反转，然后我们可能会面临两个构建者审查某些交易的情况，那我们将回到一个非常糟糕的处境。

我想提到的另一件事，因为我确实认为它很重要：如果我们朝着我们讨论过的一些方向发展，比如 APS，在这些我们研究过的设计中，你可以真正将证明者和提议者分离开来，我们需要在此之前引入 FOCIL，并且我们需要知道 FOCIL 是有效运行的。我们需要 FOCIL 在主网上运行六个月甚至一年，以真正确保它实现了其目的，即维持和改善以太坊的抗审查特性。因此，至少对我来说，另一个紧迫性在于，如果我们想保护证明者免受时序博弈以及我们希望通过 APS 解决的其他问题的影响，我们需要尽快引入 FOCIL。

Pooja Ranjan: 有时看到提案没有被选入下一次或最近的升级中会让人感到遗憾，但一次升级中能包含的提案数量是有限的。我非常感谢在提出提案、准备提案以及进行相关测试背后所付出的所有辛勤工作。所以非常感谢你们为以太坊生态系统所做的一切工作。

快问快答 (55:18)

Pooja Ranjan: 在结束之前，我们有一个简短的快问快答环节。唯一的条件是答案必须是一个词或一句话，我们会尽量计时，大概每人 30 秒。如果准备好了，我们就从 Julian 开始。目前区块链研究中最难的问题是什么？

Julian Ma: 我不想太玩梗，所以我认真回答。我认为最难的问题是质押的未来：质押的未来意味着什么，哪些服务提供商扮演什么角色，他们如何获得报酬，以及他们之间如何相互关联。

Pooja Ranjan: 有哪个区块链用例还没有得到充分探索？

Julian Ma: 我会说是 FOCIL。

Pooja Ranjan: 今天以太坊面临的最大安全风险是什么？

Julian Ma: 老实说，我认为抗审查性在这里非常关键，因为像多区块 MEV 这样的问题可能会带来巨大的安全风险，例如对二层网络 (l2) 而言。

Pooja Ranjan: MEV 应该被最小化、被拥抱，还是介于两者之间？

Julian Ma: 我在很大程度上同意 Flashbots 的观点，即它应该被民主化，这意味着在必要的地方应该将其最大化，而在应用层将其最小化。

Pooja Ranjan: 去中心化总是值得权衡取舍的吗？

Julian Ma: 通常是值得的。

Pooja Ranjan: 以太坊给世界带来的最大创新是什么？

Julian Ma: 在这里我想引用 Mike Neuder 在 Devcon 上关于数字产权的演讲。我认为是抗审查的数字产权，这真正改变了世界。

Pooja Ranjan: 非常感谢，回答得很好。我的下一组问题是给 Thomas 的。那么，如果以太坊不存在，你会致力于哪个区块链？

Thomas Thiery: 我想我会很爱玩梗，Julian 坑了我一下，因为我以为他也会这么做。那个区块链会是 FOCIL。

Pooja Ranjan: 区块链最被过度炒作的用例是什么？

Thomas Thiery: 没有 FOCIL，任何用例都不值得炒作。

Pooja Ranjan: 以太坊需要尽快改进的一件事是什么？

Thomas Thiery: 抗审查性，通过 FOCIL。

Pooja Ranjan: 用一个词来形容去中心化？

Thomas Thiery: FOCIL。

Pooja Ranjan: 你认为以太坊能完全解决可扩展性问题吗？

Thomas Thiery: 带有 FOCIL 的以太坊，是的。

Pooja Ranjan: 一层网络 (l1) 扩展还是二层网络 (l2) 扩展，哪个会赢？

Thomas Thiery: 无限层，全部带有 FOCIL。

Pooja Ranjan: 做得非常好，非常感谢你，Thomas。感谢你回答所有这些问题。在结束之际，我想把这个机会交给你们：关于这个提案，或者对整个以太坊社区，你们有什么想对社区说的话吗？

给社区的寄语 (58:08)

Thomas Thiery: 实际上，这是非常重要的一点，因为我们一直在进行积极的讨论，而且这些讨论在 Discord 上都是公开的。一开始就有人推动将所有内容公开，而且大家确实在这么做，所以我非常高兴。你可以在公开的 Eth R&D Discord 上的 inclusion-list 频道关注讨论和进展。目前基本上所有的事情都在那里进行。然后你可以在推特、电报或任何地方联系我们。请随意。

我们交流和参与的人越多，设计就会越好，实现也会越好。因此，如果你能在任何方面提供帮助，请联系我们，我们很乐意在各个方面提供帮助，甚至在研究方面也是如此。我想，对于那些希望致力于 FOCIL 未来发展的人来说，与我们合作再合适不过了。我们提到了隐私，提到了交易费机制，我们还将把大量精力集中在针对斑点的 FOCIL 上。所有这些事情都需要人力和研究投入。如果你感兴趣，请联系我们。非常感谢邀请我们，也感谢你们为以太坊所做的所有工作。

Julian Ma: 补充一点，我希望我们能让一些人对 FOCIL 充满热情。如果你对此充满热情，请告诉我们。如果你还有任何问题，我们很乐意解答，希望我们能让你相信 FOCIL 确实是正确的发展方向。非常感谢。很高兴能来到这里，感谢你们主持这次会议。当然，也感谢大家的参与。

结束语 (59:52)

Pooja Ranjan: 谢谢大家。今天的节目就到这里。非常感谢 Thomas 和 Julian 今天加入我们，并分享他们对 EIP-7805 的见解。感谢所有参与者；你们的问题令人鼓舞且很有启发性。感谢您的收看。如果您喜欢这次对话，请务必点赞、订阅，并与您的以太坊爱好者朋友们分享本期节目。我们将在 PEEPanEIP 上为您带来更多 EIP 和研究进展。我们下期再见，愿您在知识中惬意徜徉，与 Ethereum Cat Herders 一起在以太坊的世界中探索。祝您今天过得愉快。