关于 Flashbots 的笔记

作为我的 EPF 项目的第一步，我想要了解当前PBS的实现是如何运作的。并且看看我是否可以使用它来从一个使用 Portal Client 而不是 EL 客户端的验证者那里提案区块。

目前 (2023年9月) MEV的Flashbots架构是使用最广泛的PBS实现。所以这篇文章就是关于它的。

我制作了这个图表来可视化这个架构：

你可以在这里找到更高质量的图表。

这种架构为验证者提供了一种无需信任的方式来外包最佳区块构建工作。这个过程如下：

1. 搜索者将他们的交易发送给构建者。搜索者可以选择将他们的交易发送给哪些构建者。
2. 构建者从他们收到的交易中安排最有利可图的区块。
3. 中继：
   • 接受来自构建者的新区块。
   • 将最有利可图的区块头发送给验证者。
     • 验证者锁定他们对提案该区块的承诺。
   • 将完整的区块发送给验证者。
4. 验证者使用MEV-Boost从中继接收完整的区块，并将其提案给以太坊网络。

因为我想要专注于如何提案区块，我需要更深入地研究第三步和第四步，并正确理解MEV-Boost如何与中继和CL客户端交互。

幸运的是，Flashbots文档上有一篇专门针对此的文章。

"MEV-Boost 区块提案" ， Flashbots制作，基于CC BY 4.0协议 / 来源

现在是提及构建者API的好时机。“构建者API是共识层客户端获取由外部实体构建的区块的接口。” 这是MEV-Boost和MEV-rs 必须遵循的规范，以使验证者能够提案由其他人构建的区块。

回到图表，我对提案区块时调用的函数进行了一些研究：

• registerValidator
  • 构建者API 端点.
  • MEV-Boost 实现.
• getHeader
  • 构建者API 端点.
  • MEV-Boost 实现.
• getPayload
  • 构建者API 端点.
  • MEV-Boost 实现.
  • 还有一个名为 processCapellaPayload的函数。

退一步

在了解这些的过程中，我意识到我需要退一步。构建者API中描述的端点正是我想要的。它们描述了如何提案一个外部构建的区块。但是有些我没有足够重视：

你需要运行一个完整的EL + CL组合来运行MEV-Boost。

这意味着即使我设法在Portal Client上实现构建者API，我也需要运行一个完整的EL客户端，从而违背了我的项目的初衷。

所以，我将不得不继续研究如何在Portal Clients上实现Engine API。

一些最后的想法

我不确定这一点，但我会提到它以供将来参考：

我认为你需要运行EL+CL组合来运行MEV boost的原因是，CL客户端除非连接到EL客户端，否则不会启动。

这意味着可能有一个最少的Engine API端点集合，我可以实现它来启动CL客户端，然后运行MEV-Boost（或者，可能将mev-rs导入到Trin）来填充缺失的端点。

有一个最少的Engine API端点集合，我可以实现它来启动CL客户端，然后运行MEV-Boost（或者，可能将mev-rs导入到Trin）来填充缺失的端点。

这将产生一个很好的副作用，解决了我在项目提案中提到的问题：无法在不运行自己的EL节点的情况下测试Lighthouse。

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