为Dencun硬分叉做准备

Dencun硬分叉是一个主要的以太坊升级，计划超过2年，并于3月13日在纪元29696上线。此次升级引入了Blob交易，旨在降低Rollup的交易成本。本文将详细介绍Flashbots在升级准备中的工程工作。

Dencun中针对MEV-Boost的协议变化

Dencun硬分叉由多个EIP组成，这要求对通过mev-boost堆栈传递的有效载荷进行升级。

最大的协议变化是EIP4844，它引入了用于二层数据可用性的Blob交易。Blob交易是一种新的交易类型，通过执行层提交并传播，但暂时存储在共识层中。

另一个对块构建和验证有影响的变化是EIP-4788，它将信标区块根引入执行层。

MEV-Boost架构

mev-boost和mev-boost-relay都需要实现最新的builder-specs API，以便与Dencun兼容。 builder API 指定了mev-boost如何与外部中继进行通信。通常，对于每次硬分叉升级，getHeader和submitBlindedBlock类型需要更新以支持执行头部和有效载荷中的新字段。

对于mev-boost，这是通过切换到attestant的go-eth2-client和go-builder-client库来实现的，替代了被弃用的go-boost-util类型。规范在测试网硬分叉之前常常处于变动中，因此大部分工作涉及在这些库中添加新的Dencun类型并对规范进行迭代修改。

mev-boost-relay中的更改更加复杂。除了builder-specs API，中继也需要实现对relay-spec API的更改，该API指定了构建者如何与中继通信。为了执行其块验证职责，中继还需要了解Dencun硬分叉版本和时间表，并升级其块发布和块验证调用。

块验证

块验证通过Flashbots的修改版geth客户端进行块验证API。对于Dencun，来自执行层的Blob交易意味着几乎所有Blob验证都由块验证API处理，而不是在中继处处理。通过引入上游geth变更，可以利用现有geth代码来验证Blob交易和Blob头部字段。

此外，对于EIP-4788，中继需要将父信标根传递给块验证API。

下图序列图描述了升级的全部交互和更新的终端。

buildervalidation nodebeacon nodemev-boost-relaymev-boostbuildervalidation nodebeacon nodemev-boost-relaymev-boostrelay servicespar[relay api]par[builder api]submitBlock (deneb.SubmitBlockRequest)flashbots_validateBuilderSubmissionV3getHeaderdeneb.SignedBuilderBidgetPayload (deneb.SignedBlindedBeaconBlock)publishBlockV2 (SignedBlockContents)deneb.ExecutionPayloadAndBlobsBundle

块构建

Flashbots还运营一个从geth修改而来的构建器builder。除了块验证，块构建逻辑也需要更新，以支持私有Blob交易和包含Blob交易的捆绑。

Geth对于4844显著改变了其txpool结构，通过引入子池以不同的策略处理传统和Blob交易的驱逐。然而，这不适用于捆绑，因为它们有不同的有效性条件，例如捆绑有效的目标块号码。

最有效的添加捆绑支持方式是在顶层的txpool中将所有捆绑和mev-share逻辑集中，而不是从子池中获取捆绑交易。这样，捆绑逻辑可以与子池逻辑分离开，并可以转移到其自己的服务中，而不必与geth的txpool集成。考虑到块构建时捆绑与Blob增大的潜在优化，可以进行更多的改进。然而，由于时间限制，这部分计划在硬分叉后再考虑。

与块验证一样，父信标根也需要通过信标节点的payload_attributes sse流作为块构建参数传递。

JSON RPC服务

Flashbots运行多种JSON RPC服务，供用户和搜索者通过Flashbots的JSON RPC端点提交私有交易、捆绑和mev-share捆绑。

这些服务的大部分中间件是用Golang编写的，更新geth的依赖关系足以支持升级。在内部，Flashbots将所有eth_sendPrivateTransaction调用封装成捆绑，并在构建器合并之前模拟所有捆绑。eth_callBundle和mev_simBundle方法可以利用现有geth代码来模拟Blob交易，因为模拟逻辑与构建器共享同一代码库。

legend

send

call

tx

Y

X

Z

null

eth_callBundle

bundle-relay

eth_sendBundle

eth_sendPrivateTransaction

simulation-node

private-tx-bundler

mev_simBundle

matchmaker

mev_sendBundle

builder

测试

由于配置所有不同服务的难度，测试整个堆栈是最困难的方面之一。一些使用的工具包括：

Kurtosis

Kurtosis提供启动容器化服务的工具，其以太坊包允许在一个命令中本地启动一个以太坊PoS开发网。

Flashbots与Kurtosis合作，将PBS仿真纳入以太坊包，这在本地测试mev-boost的端到端流程时是非常宝贵的。然而，在使用Kurtosis运行PBS仿真时存在一些需要注意的事项：

• 设置本地开发网资源密集。根据配置节点的数量，在单一机器上很难运行多个或长时间运行的开发网
• 初始设置等待时间较长。某些共识客户端在周期4之前不会请求mev-boost块，并且Flashbots构建器不支持可配置的时间插槽，以缩短每个周期的等待。每次运行可能需要20-30分钟来测试端到端流程
• 难以快速迭代修改。当发现错误时，需要使用包含修复的更新Docker镜像重新创建本地开发网。由于初始设置的缓慢，这并不理想，而对于开发网运行时更新Docker镜像的能力有一个开放的问题。

开发网和影子分叉

开发网是由EF设置的公开可用测试网，通常运行几个星期。Flashbots与以太坊基金会DevOps团队紧密合作，将mev-boost服务集成到他们的基础设施设置和测试中。

影子分叉是复制现有网络（例如主网）状态并重放交易的开发网。主网影子分叉在增强对mev-boost发布的信心方面至关重要，因为我们无法看到mev-boost在主网的错误。mev-boost软件与验证者客户端并行运行，因此识别和缓解错误的主要机制是来自验证者的直接反馈和报告。

总的来说，Flashbots参与了自devnet-9以来的每一个开发网（总共12个），2个Goerli影子分叉和1个主网影子分叉，在此次硬分叉的前5个月期间。

测试网

mev-boost堆栈被纳入许多核心以太坊协议测试基础设施，因为它对网络的健康至关重要。测试网对于测试捆绑和私有交易端点非常便利，因为在Sepolia和Holesky上有现有搜索者提交交易。

由于测试网运行时间很长，它们也可能捕捉到在开发网或影子分叉测试中未发现的错误。一些示例包括：

• 在块构建期间实例化工作线程时出现的内存泄漏
• 当合约与创建同一事务同时自销毁时，会导致状态Trie被破坏的错误，导致构建器无法同步

学习与未来步骤

Dencun硬分叉是一个很好的机会，用于回顾Flashbots关键服务和产品的升级和维护内部过程。与上一个Shapella硬分叉相比，有一些重要的收获：

• 对于本地测试，更好的工具（如Kurtosis）的重要性
• 早期与以太坊客户端集成是解决客户端错误的关键。由于mev-boost测试在Shapella的测试网硬分叉期间较晚进行，因此在主网时未发现客户端错误，导致错过插槽。
• mev-boost生态系统的成熟程度提高。客户端团队对mev-boost更加了解，从而减少了为适应外部块构建而进行的临时更改。

对于未来的硬分叉可改善的事项：

• 捆绑和私有交易的垃圾邮件发送工具。目前没有发送包含Blob交易的捆绑的工具，像mev-flood的工具仅覆盖少数测试用例
• 改进构建器中的开发工具。由于缺乏块构建逻辑的模块化、可配置时间插槽和性能监控，Dencun测试中构建器是最难测试的部分。

社区贡献

顺利完成Dencun升级离不开社区的帮助和参与：

• 其他mev-boost维护者对mev-boost和mev-boost-relay Dencun代码的审查
• 来自其他中继操作员（如Ultrasound和bloXroute）的错误报告
• mev-boost社区电话讨论Dencun规范和进展更新

特别感谢EF DevOps、Kurtosis团队以及mev-boost维护者对审查和确保Dencun升级顺利进行的支持。

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