谁动了我的测试网？

谁动了我的奶酪测试网？

Holesky 和 Sepolia 网络上最近发生的事件让我开始思考我们当前测试网的状态，以及谁最受这些问题的影响。这也让我反思我们目前用于测试硬分叉和其他协调推出的方法，以及我们可以在哪些方面改进。在这篇文章中，我希望分享我对当前测试网状态的一些看法，并提出一些我认为可以帮助我们前进的建议。

TLDR

• Holesky 和 Sepolia 测试网对于外部实体测试其软件和基础设施都很重要；它们已经从简单的测试环境发展成为更接近于预发布环境。
• 我们需要明确 Sepolia 和 Holesky 测试网的需求。每个网络都有其用途，不同的人依赖于它们来实现不同的用例。
• 核心开发者需要一种尽可能接近主网的方式来测试发布和网络升级。我们主网和这些测试环境之间的差距越小，破坏重要事物的风险就越低。

什么是以太坊测试网？

这是一个为那些不熟悉以太坊测试网及其用途的人准备的快速入门。截至今天，以太坊有两个（如果包括 Ephemery 则为三个）测试网络。

Sepolia

Sepolia 是一个许可网络，拥有 1,780 个验证器（截至 2025 年 3 月 12 日）。许可并不意味着它是一个私有网络，而是意味着只有特定的实体才被允许作为验证器加入该网络。该网络有一个修改过的存款智能合约版本（这就是为什么当我们将网络升级到 Pectra 时我们遇到了问题），该合约需要一个特定的 token 才能创建存款。只有拥有该 token 的人才能创建存款。

控制验证器集的好处是，我们可以“强制”运营商尽可能完美地运行他们的验证器，即使没有像主网这样的网络提供的货币激励。这也使得以协调的方式推出更改变得容易得多：我们可以在短时间内让整个验证器集运行特定版本的客户端软件。这使得 Sepolia 成为应用程序开发人员推荐的网络，因为它是我们拥有的最稳定的测试网络。

Holesky

Holesky 是一个公共网络，拥有 1,750,086 个验证器（截至 2025 年 3 月 12 日）。到目前为止，它是我们最大的实时网络（比主网更大）。事实上，我们创建 Holesky 的全部原因是为了拥有一个可以向我们展示主网在增长时可能是什么样子的网络，让我们核心开发者有机会在问题影响主网之前在 Holesky 上识别问题。

由于 Holesky 是公共的，任何人都可以运行该网络上的验证器，这使其成为希望在提交运行主网验证器之前获得运行节点经验的家庭质押者的完美试验场。对于 L2 或质押池等其他实体来说，这也是一个很棒的试验场，因为他们可以在模拟主网的对抗性环境中测试其系统。

客户端团队如何测试他们的软件？

以太坊（以及一般的区块链）最基本的事情之一是它的分布式特性。这给我们客户端开发人员带来了真正的测试挑战，因为协议的大多数核心功能和我们编写的软件都是为与其他客户端互操作而设计的。

在以太坊的早期，每个团队都会提出他们自己运行大规模测试的方法，依靠其内部运维团队来支持启动开发网络。我们有一些公共测试网，例如 Ropsten 和 Rinkeby，我们可以在其中尽可能接近主网地测试我们的代码。

随着以太坊的发展，运行节点和大规模测试网络的网络拓扑复杂性也随之发展。我们现在有共识客户端、执行客户端、mev-boost、中继、DVT 等。

值得庆幸的是，在过去的几年里，EF 为我们提供了 ethPandaOps，这是一个由非常有才华的人组成的团队，他们在自动化、测试和监控工具方面为客户端团队提供了巨大的帮助。借助他们的工具，我们现在能够在我们的笔记本电脑上本地运行小型网络（使用 Kurtosis 和 ethereum-package），并且还可以启动大型网络来测试特定功能（我们称这些为 devnets）。

从一个非常简单的角度来看，这些是我们为一个特定 fork 以及 fork 中包含的每个功能（例如 EIP）拥有的测试“范围”。圆圈越大，测试所需的部署和协调就越复杂。

例如，在处理某个特定功能时，我将首先依靠单元测试和参考测试来确保我正在编写的代码正在执行我期望它执行的操作，更重要的是，没有执行任何会破坏规范的操作。

一旦我对它感到满意，我将启动一个本地互操作网络（使用 Kurtosis），以便测试我的客户端如何与其他已经实现了相同新功能的客户端进行交互。Kurtosis 的一个很棒的功能是本地网络由一个 YAML 配置文件定义，该文件很容易与其他团队共享。因此，如果我在与其他客户端交互时发现了一个错误或一些意外行为，我可以将我正在使用的配置发送给他们，他们可以在几分钟内在他们的计算机上拥有我正在运行的本地网络的副本！

下一步是核心开发团队将开始协调一些使用称为 devnets 的短期网络的互操作测试。这些可以专门用于测试特定功能或 fork 的完整功能集。EthPandaOps 负责启动这些 devnets，我们所有人都有机会测试我们的客户端并确定任何其他互操作问题。

有时我们使用我们称之为 Shadowforks 的东西来测试互操作性。Shadowforks 就像一个网络“克隆”。使用 shadowforks，我们可以从另一个现有网络（包括主网）启动一个网络。当我们想要来自真实环境的世界状态或验证器数据时，这些非常有用，并且对于查找只能在具有过去历史记录的网络上浮出水面的错误特别有用。如果你想了解有关 Shadowforks 的更多信息，我建议你看看这篇文章。

我们还有 Hive tests 来跨不同的客户端运行集成测试。Hive 是一种针对以太坊客户端运行端到端测试的工具。以太坊基金会维护着两个公共 Hive 实例，不断测试共识、p2p 和客户端兼容性。它们特别重要，因为通常我们会在那里看到诸如客户端之间的执行引擎 API 分歧以及其他难以在不测试共识和执行客户端的完整矩阵的情况下找到的问题。

接下来，我们有我们的测试网。这是事情变得更加严重的地方，因为这些网络都被其他实体和用户使用，我们努力确保我们的升级是无害的（尽管我们这次在测试 Pectra fork 时没有成功）。理想的情况是完美推出，客户端之间没有互操作问题或任何协议漏洞。所有测试网的推出都会在发生之前进行协调和安排，以便节点运营商有时间升级他们的客户端。

Holesky 和 Sepolia 事件后的经验教训

Holesky 和 Sepolia 事件中的一个问题是，这些网络不仅仅被核心开发人员用来测试他们的部署和网络升级逻辑。这些网络正被其他实体积极使用来测试他们的软件（想想 L2、质押池和其他系统）。因此，当 Holesky 的情况变糟时，这些实体的所有测试管道都被阻止了。这个问题甚至更糟糕，因为这些实体中的许多实体都需要部署在网络上的特定基础设施，包括智能合约、预言机、监控系统等。因此，对他们来说，仅仅将他们的测试转移到另一个网络上并非易事。

另一方面，我从一些核心开发人员那里听到过这样的话：“我们需要一个我们可以破坏的测试网”，或者“我们破坏了 Holesky？这就是测试网的用途！”。公平地说，他们没有错。我们确实需要一种测试我们的发布的方式，而不必担心事情出错时“清理”自己。

在这个特定的例子中，Holesky 和 Sepolia 的事件都是由我们的测试网和主网配置之间的差异引起的。有趣的是，这些问题都不会发生在主网上。也许下次我们只需按下按钮，直接进入主网（不，我们不会）🙂。

对我来说很清楚的是，我们需要更好地调整每个测试网的需求，以及它们的预期目标。我们还需要为现有测试网的用户设定明确的期望，即我们将像对待主网一样对待它们。在 Holesky 事件期间，有人呼吁对网络进行硬分叉修复，这在主网上是不可接受的，那么我们为什么要讨论它呢？如果我们要修复 Holesky，我们需要以与在主网上相同的方式进行修复。毕竟，这就是协议的设计目的。如果它无法在这种情况下生存下来，我们需要回到绘图板并修复它（剧透警告：网络已修复并恢复最终确定）。

另一件重要的事情是重新审视我们的测试策略，并确定我们的部署、配置或任何其他方面与主网不同的所有区域。在 Sepolia 事件中，失败的原因是 Sepolia 中的存款合约与主网上的存款合约略有不同，而且大多数人甚至不知道它们是不同的。Holesky 上发生的问题没有在之前的测试中发生，因为我们配置 Devnets 的方式与我们引导测试网配置的方式不同。我们的测试环境（Kurtosis、Devnets 和测试网）与主网之间的差距越小，我们在推出东西时就越不容易感到惊讶。协议的复杂性随着每个新的 fork 而增长，因此我们花时间识别这些差异并尽可能消除它们是对我们自己有利的。

我们现在去哪里？

目前，核心开发人员正在与 ethPandaOps 合作，以寻找可以替代 Holesky 的方案，社区可以使用该方案及时测试所有与 Pectra 相关的更改。已经提出了一些想法，很快我们将有东西启动并运行。

关于现有的 Holesky 网络，目前尚不清楚它的未来会怎样。尽管它已经恢复了最终性，但在整个过程中，大量的验证器已被削减，而另一些验证器由于泄漏的余额太低而被弹出。我们可以让它保持在线并运行其过程，但这将无法实现其作为社区预发布环境的主要目标。过去的几周对我们核心开发者来说是一个绝佳的学习机会，每个客户端都有机会改进他们的客户端，以处理这些灾难性情况。我们过去曾有 devnets 来测试非最终性，但我认为我们从未运行过像 Holesky 中发生的那样大规模的场景。而且我们最终能够稳定网络并恢复最终性的事实太棒了。另一方面，保持网络运行需要付出巨大的代价，因此我相信我们很快就会停止使用 Holesky（当然我们会有一个替代方案）。

最后但并非最不重要的一点是，过去几周发生的一切已帮助我们确定了可以改进测试的领域，缩小了我们的 devnets 与主网之间的差距，而且我相信所有客户端团队都将从中获得更多灾难恢复经验，并更好地应对事件。对于我们来说，这是一个巨大的时刻，可以展示我们如何从错误中吸取教训，并改进协议、流程和代码。

参考

• Marius 的博客文章：Sepolia Pectra fork 事件回顾
• Kurtosis Github 仓库
• Ethereum-Package for Kurtosis Github 仓库
• Alchemy 文章：什么是 Shadowfork？
• Etherworld 文章：Holesky 测试网事件的余波：经验教训
• ethPandaOps 博客文章：Holesky 后最终性路径
• Pari 和 Marius 在 Galaxy 接受采访，谈论 Pectra 测试

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