本文件的动机是我们的工作 FOCIL 共识规范 23，我们意识到该协议需要围绕资源限制进行更周到的考虑，因为某些细节没有在协议中明确指定 FOCIL 以太坊研究帖子 14。

先决条件

在开始之前，我们假设采用以下设置来建立一个干净的基线供我们考虑：

• 该设置基于 Electra 硬分叉。在 EIP-7732 (ePBS) 之上重新审视这一点进行比较也是有意义的
• 我们假设单独的区块构建和发布，其中提议者没有运行 MEV-Boost。这是第一个需要正确处理的关键组件，而 Builder API 是次要考虑因素
• 我们假设一个单独的质押者设置具有典型的计算、内存要求和带宽，您今天可以在以太坊链上轻松遵循

演员

在继续之前，我们假设以下参与者是协议的一部分并分析他们的职责：

• 包含列表（IL）委员会成员，负责通过其包含列表交易集来约束下一个插槽提议者
• 提议者，负责提议下一个槽位
• 证明者，他们正在证明链头的下一个插槽
• 节点，验证并跟踪链。提议者和证明者是已质押以太币的节点的一部分

时间轴

我们假设 IL 委员会、提议者和证明者执行一些诚实行动的时间表如下：

• 投币口 n-1, 时间=6：IL 委员会在了解区块内容后，针对全球主题发布了本地包含列表 (IL) n-1
• 投币口 n-1, t=9：证明者和诚实验证节点锁定本地 IL 的视图
• 投币口 n, 时间=0：槽的区块提议者 n 释放块 乙，其中包括应满足IL要求的有效负载
• 投币口 n, 时间=4：槽的证明者 n 对区块进行投票 乙，通过将其与本地 IL 视图进行比较并确认是否阻止来验证 IL 聚合 乙 是“有效”的
  • 当提到一个块时，我们会重载“有效”这个词，但它可能意味着“可导入的”、“规范的”或其他意思。请参阅未解决的问题以获取进一步说明

区间 1：IL 委员会发布本地 IL

演员：列入名单委员会

IL 委员会成员从给定头的 EL 客户端检索 IL 交易列表（CL → EL 调用），然后他们签署本地 IL（交易 + 摘要）并将其发布到八卦网络。

资源考虑因素

• 从 EL mempool → CPU/MEM 检索 IL 交易
• 签署包含列表 → CPU
• 上传收录列表到八卦网→带宽（上传）

参与者：节点（包括证明者）

链上的节点将下载 IL，验证其是否具有反 DOS（尚未将其导入 EL），并将其转发给其他节点。节点还将 IL 导入到分支选择中，并使用聚合缓存跟踪已看到哪些 IL。链上的证明者和节点应该具有相同的链视图。

资源考虑因素

• 下载 IL → 带宽（下载）
• 转发 IL → 带宽（上传）
• 验证 IL 的抗 DOS → CPU/MEM
• 缓存已见并聚合 IL → MEM

演员：求婚

下一个时隙的提议者主动监视 IL 八卦网络，并收集和聚合本地 IL，然后在 IL 聚合截止（间隔 #2）时，提议者使用要包含在其块中的 IL 交易列表来更新块构建过程。这需要 CL 到 EL 的调用。

资源考虑因素

• 继承与链上节点相同的成本

提案者边缘案例

如果下一个时隙的提议者根据其未见过的父哈希观察到足够数量的包含列表，则提议者将需要手动请求丢失的信标块，导入该块，并在该块之上构建。

结论

基于上述，我们可以识别潜在的资源密集型区域并缩小范围：

• IL 委员会的 CPU 影响：从 EL 检索 IL 交易并签名：虽然这里存在资源需求，但据推测这相对便宜并且不是主要问题。
• 节点带宽影响：下载和上传 IL 的节点可能会使用大量带宽，特别是目前的研究文章表明包含列表大小是灵活/无限制的。这引入了潜在的 DOS 风险，因为恶意 IL 委员会成员可能会用大量交易淹没网络，即使这些交易无效。节点在导入 IL 之前仍然会讨论 IL 的八卦。需要仔细考虑反 DoS 措施。

间隔 2：节点锁定其视图，提议者导入 IL 交易

演员：求婚

提议者使用包含列表交易列表更新区块构建过程。这是 CL → EL 调用。

资源考虑因素

• 使用包含列表交易列表更新区块构建过程 → CPU/MEM

参与者：节点（包括证明者）

锁定包含列表视图。从此时起停止接受本地包含列表。

资源考虑因素

• 锁定本地包含列表视图 → 无

结论

• 提案者对 CPU 的影响：将 IL 交易导入到区块构建过程中可能会扰乱区块构建过程，从而可能在交易模拟期间使执行层客户端的 CPU 紧张。在账户抽象下，这可能会变得复杂，因为交易可能会彼此无效。对此还需进一步分析。

间隔 3：提案者释放区块

演员：求婚

提议者从 EL 客户端（CL → EL 调用）检索执行负载，并将其发布到信标块八卦网络。然后其他人验证该块。

资源考虑因素

• 从 EL 客户端检索有效负载 → CPU/MEM

演员：节点

节点接收信标块并对其进行验证。新的验证步骤包括检查包含列表聚合构造并确认包含列表是否满足评估函数，这在CL上完成。 IL条件的检查（是否可以由于冲突而被跳过）将在EL上执行。

资源考虑因素

• 验证 CL → CPU 上的包含列表是否满足
• 验证 EL → CPU 上的包含列表条件

结论

提议者的额外职责似乎并不是一个重大问题。节点的新验证步骤（检查验证包含列表是否满足满意的条件）可能会引入一些额外的 CPU 负载，但这似乎不是一个主要问题。

区间 4：证明者委员会

演员：证书

证明者使用 LMD GHOST 分叉选择规则对信标区块进行投票。证明者只会根据间隔 1 的观察结果，投票选出满足包含列表评估函数的信标块。

资源考虑因素

• 证明者投票选出满足包含列表评估函数的区块 → 无额外成本

结论

和今天没有什么区别。

资源考虑总结

如上所示，最重要的资源问题围绕包含列表上传、下载以及从节点的角度来看垃圾邮件的可能性。另一个关键问题是节点验证和导入包含列表的开销，以及提议者需要更新其块构建过程以满足包含列表。这些方面都需要仔细考虑和设计，以确保效率和安全性。

开放性问题

基于上述内容，我们概述了几个将影响规范编写方式的悬而未决的问题：

1. 不满足评估函数的块：应该如何处理未通过包含列表评估函数的块，以及针对这种情况需要考虑哪些设计考虑？
   • 是否应该像 blob 一样对待它并且不能导入？
   • 难道不应该通过分叉选择来过滤吗？
   • 它在状态转换函数中应该无效吗？
2. 包含列表歧义：如果包含列表委员会成员将不同版本的包含列表发送到不同的节点，并且它们都在网络上传播，那么此操作的后果是什么？这种行为会对构建下一个区块的提议者产生怎样的负面影响？
3. 提案者已经建立在不同的头部上：如果提案者建立在与包含列表委员会发送的头部不同的头部上，因此需要改变其头部视图，那么这一行动对区块有效性和提案者行为会产生什么后果？
4. 包含列表交易失效：本地包含列表交易可以通过几种方式失效。即使这些交易失效，区块仍然应该能够满足评估函数。当多个包含列表彼此合并或与块中的交易合并时，交易可能会失效。除了典型的随机数检查之外，帐户抽象还引入了使交易无效的新方法，因为可以使用静态随机数耗尽余额。对于 MEV-Boost 参与者和本地构建者来说，由于交易无效，区块构建器需要执行多少额外的模拟，以及这对其 CPU 计算的影响有多大，还有待观察。
5. 提案者对 IL 委员会子网的观察：提案者监视包含列表委员会子网，以了解其何时准备好构建聚合。这里有两种设计方法，值得进一步考虑。第一种方法是贪婪的提议者，提议者等待直到 t=9，收集尽可能多的 IL，将它们发送到 EL，然后 EL 更新其块。第二种方法是选择性提议者，其中提议者等待，直到有足够的包含列表来满足 eval 函数，将它们发送到 EL，并且可以在小于 t=9s 甚至更早。问题是第二种方法是否证明优化的合理性，以允许提议者更早地发布包含列表聚合。第二种方法可能只适合具有自己专用气体限制的 IL。

声明：

1. 本文转载自[ethresear]，著作权归属原作者[terence]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。