Builder Playground - 快速搭建区块链的本地测试环境

2025-04-17 18:32

登链社区

2025-04-17 18:32

来源链接

订阅此专栏

收藏此文章

我们很高兴地宣布 Builder Playground，这是一个开源框架，用于快速启动 L1 和 L2 的全面区块构建测试环境。在与速度太慢、不够灵活或对于我们在 Flashbots 的专业需求来说过于繁琐的工具作斗争之后，我们构建了 Builder Playground。这种专门构建的解决方案使开发人员能够在几秒钟而不是几分钟内部署完整的区块链测试环境，具有最少的配置和最大的可靠性。

构建区块构建器基础设施的挑战

区块链的核心是区块，每个区块背后都有一个被称为“区块构建器”的角色。在 Flashbots，我们开发区块构建基础设施已经超过五年了。区块构建不是一项孤立的任务，它需要与众多基础设施交互，从共识机制到执行环境，一直到用户的钱包。测试 L1 区块构建器的最基本设置包括执行层客户端 (EL)、共识层客户端 (CL)、验证器和 MEV-Boost - 而这仅仅是个开始。当你向上发展到 L2 及以上时，这些环境会随着额外的组件和依赖项呈指数级增长，变得更加复杂。

虽然可以模拟某些类型的测试的某些组件，但拥有一种简单的方法来在本地部署完整的、类似生产的环境对于全面的测试和验证仍然至关重要。快速、可靠的本地部署使我们确信我们的实现可以正确处理真实组件之间的交互，从而暴露出无法通过模拟完全模拟的复杂性。

部署区块链测试环境最广泛使用的工具是 Kurtosis，它是一种支持 Ethereum 和 Optimism 的通用部署工具。但是，它的设计与我们的区块构建器开发工作流程不一致，原因如下：

性能限制：即使运行简单的设置也需要相当长的时间，这会影响我们的开发过程。
扩展到标准软件包之外：除了 EthPandaOps 团队维护的主要 Ethereum 和 Optimism 软件包之外，由于 Starlark 脚本的复杂性，创建和维护你自己的自定义软件包具有挑战性。这对我们来说尤其重要，因为 Flashbots 正在快速迭代不同的网络拓扑和区块构建模式（例如 Buildernet 和 Rollup-boost）。
部署后工作流程挑战：在 Kurtosis 环境部署后，访问服务并与之交互需要额外的步骤。容器名称和端口是动态分配的，这使得一致地访问特定服务变得困难。

考虑到替代方案，简单地直接使用 docker-compose 文件也不是一个可行的解决方案。虽然 Kurtosis 通过抽象增加了复杂性，但 docker-compose 对于我们的要求来说太基础了。区块链部署需要在容器启动之前对状态和工件进行大量的预设置。这个关键的准备步骤超出了 docker-compose 设计处理的范围。

此外，使用 docker-compose 将需要开发人员手动管理服务配置、处理端口映射、实施容器网络以及创建自己的健康监控系统 - 同时还要处理数十个特定于客户端的标志和参数。这种方法对于有效测试复杂的区块链环境来说太底层和手动了。

为了解决这些特定的挑战，我们创建了 Builder Playground - 一种专门构建的工具，可以简化区块构建器测试环境的部署。

Builder Playground 架构

Builder Playground 的核心是两个关键抽象概念：

组件： 组件代表单独的计算服务，如执行客户端、共识客户端或中继。每个组件都被定义为一个 Go 结构体，封装了服务的配置。组件仅公开必要的参数，同时通过合理的默认值将用户从众多底层配置细节中抽象出来。组件包括执行参数和重要的元数据，如导出的端口和服务依赖项。此信息用于验证部署并生成服务之间的关系图。
配方： 配方组合组件以创建具体的测试环境，如 L1 堆栈、OP 堆栈或 OP 互操作堆栈。开发人员只需声明应包含在环境中的组件。

Builder Playground 中的执行流程包括三个阶段：

工件生成 首先，Builder Playground 生成部署所需的所有必要工件，如区块链创世文件、验证器密钥和配置文件。
清单创建和验证 接下来，它处理配方定义以创建部署清单。在此阶段，Builder Playground 验证所有服务连接，确保组件配置正确以协同工作，并检查是否正确指定了所有必需的端口和依赖项。
部署执行 最后，经过验证的清单被转换为 docker-compose 文件以供执行。Builder Playground 自动处理所有 Docker 网络、卷挂载和服务编排。

整个系统是用 Go 编写的，没有使用单独的配置语言，尽管与特定领域语言相比，它确实使模块化和封装的某些方面更具挑战性。我们认为这是一种值得的权衡，因为我们的目标是特定的领域（区块构建场景），在这个领域中，性能、类型安全和开发人员对 Go 的熟悉程度的优势超过了可扩展性的限制。

这种基于组件的方法允许高度的重用性 - 同一个组件可以在具有不同配置的多个配方中使用。添加新的网络拓扑就像编写一个组合现有组件的新配方一样简单。

设计原则

我们使用现有部署工具的经验为 Builder Playground 的几个关键设计决策提供了依据：

直接实现核心功能：与依赖于多层间接的工具不同，Builder Playground 直接在 Go 中实现关键功能。配置操作、网络设置和工件生成以原生方式处理，消除了容器执行简单任务的开销。这可以显着加快部署速度，从而缩短开发过程中的迭代时间。

认知负荷最小化：我们没有为每个服务公开数十个标志，而是提供了经过精心选择的、针对区块构建场景优化的默认值。通过仅公开必要的标志，我们减少了开发人员的认知负荷，使他们能够专注于区块构建逻辑，而不是基础设施细节。

模块化、可扩展的架构：Builder Playground 分为两个关键层，将服务配置与环境组合分开。这种分离使得添加新组件或创建新的测试场景更容易，而无需修改核心系统，从而更容易支持不同的网络配置。

特定领域的优化：通过专门关注区块构建器测试，我们应用了通用的工具中不切实际的有针对性的优化。我们硬编码了常用参数，为网络拓扑创建了专门的抽象，并消除了不必要的灵活性。这种专门的方法提高了我们特定工作流程的性能，同时故意牺牲了我们不需要的通用性。

Builder Playground 入门

要使用 Builder Playground：

从 GitHub 上的发布页面克隆存储库或下载二进制文件
使用 cook 命令运行该工具：

$ ./builder-playground cook l1

就是这样！这条命令部署了一个完整的 L1 链环境，其中包含 Lighthouse 信标节点和验证器、Reth 执行客户端和一个内存中的 MEV-Boost 中继。

了解输出

Builder Playground 创建一个输出目录（默认：$HOME/.playground/devnet），其中包含配置文件、创世文件和验证器密钥。每个服务都将日志写入 /logs 文件夹，从而可以轻松地调试问题。你还会找到一个 .dot 文件，显示服务之间的关系，从而可以清楚地了解组件如何连接和相互依赖。