Fusaka 带宽评估

介绍

Fusaka 刚刚在 Holesky 测试网上线，并且正在快速接近主网。该分叉包含一个名为 PeerDAS 的新功能，这是一种向网络上的节点分发 blob 的新方式。在 PeerDAS 中，节点将负责“保管”不同部分的 blob 数据，这取决于它们验证的 ETH 数量。这个想法很简单：如果你质押了大量的 ETH，你可能应该有足够的资源来处理更多的 blob，反之亦然。这保留了去中心化，确保不将家庭质押者排除在网络之外，同时仍然提供更大 blob 数量的好处。

这篇文章将重点关注 Fusaka 之后网络上各种类型节点的带宽和磁盘使用要求。

我们将从两个不同的角度来分析这个问题：

• 网络上节点的理论要求
• 我们从开发网络测试中观察到的情况

PeerDAS

PeerDAS 将我们现有的 128kB blob 分成 128 列，每列约 2KB。然后这些列在点对点层上单独广播，节点根据他们验证的 ETH 数量来保管这些列的不同子集。在 ethereum.org 上阅读更多关于 PeerDAS 的信息。

通过添加纠删码（2 倍 blob 大小），与当前“每个人下载所有内容”的模型相比，这实现了理论上的 8 倍扩展限制。节点可以通过抽样验证数据可用性，而无需存储完整的 blob。这引入了网络上可能出现的新类型的节点，每种节点都有不同的要求。

出现了三种节点类型：

• 超级节点/骨干节点：总余额 ≥4,096 ETH 的验证者必须订阅所有 128 个列子网，并保管所有数据 4096 个 epoch（约 18 天）。这些节点基本上构成了网络的骨干。与网络上的其他节点相比，它们将具有更高的处理和 p2p 负载。但是，它们所代表的权益不容小觑，而且很可能是复杂的实体。
• 验证节点：常规验证者（具有 1 个验证器）订阅其分配的 8 个以上的随机列子网。因此，它们将处理超级节点处理的 1/8（或更多）的数据，这意味着更低的 p2p、磁盘和 CPU 负载。这是普通家庭质押者将获得的好处。
• 完整节点：不参与验证的节点参与 4 个列子网。它们将处理超级节点处理的 1/32 的数据，这意味着显著降低的 p2p、磁盘和 CPU 负载。但是，即使没有质押要求，它们仍然有助于数据可用性。这主要是对主要对状态感兴趣的普通 RPC 节点的好处。（注意：如果你打算通过 Beacon API 提供 blob，你应该成为一个超级节点，因为你需要所有列来重建 blob。）

BPOs

Fusaka 还通过 EIP-7892 引入了仅 Blob 参数分叉的概念。这些分叉只能修改 blob 计数的值，而无需完整硬分叉的协调开销。核心开发人员目前计划使用 BPO1 和 BPO2 来发布 Fusaka，以监控对主网的影响，一旦收集和分析了数据，将继续对 BPO3、BPO4 等进行更积极的扩展。

基于在开发网上进行的测试和收集的数据，我们得出了以下关于主网 blob 时间表的建议：

阶段

目标 Blobs

最大 Blobs

Fusaka

6

9

BPO1

10

15

BPO2

14

21

理论要求

以太坊网络是一个复杂且不断发展的系统，鉴于有大量的活动部件，很难确定 Fusaka 之后网络的具体要求。但是，我们可以根据网络的当前状态和拟议的更改做出一些有根据的猜测。

为了帮助我们了解 Fusaka 之后网络的要求，我们将从了解网络的当前状态开始。主网目前以“6 目标 9 最大”blob 运行。目标 blob 计数在这里很重要，因为它是 blob 费用市场的平衡点，我们可以大致预计 blob 计数的使用量会随着时间的推移趋向于该点。

提醒：Fusaka 之前的 Blob 大小为 128kB。Fusaka 之后的 Blob 大小为 256kB（blob 为 128kB，纠删码为 128kB）。

为了提供帮助，我们创建了一个资源计算器，可以帮助识别不同节点类型和 blob 计数的要求。这些数据需要谨慎对待，因为它是理论上的，并且假设了一些事情。 确保更改节点类型以查看不同的要求，并查看下面每个指标的注释。

节点类型：完整节点（无验证者）(0 ETH)Solo Staker (32 ETH)小运营商 (320 ETH)中型运营商 (1,024 ETH)大型运营商 (2,048 ETH)超级节点 (4,096 ETH)自定义金额

指标：磁盘使用量平均持续下载带宽发布本地区块的最小上传带宽

ethPandaOps.io磁盘使用量（预估）质押 32 ETH 的验证者 • 保管 8 列Fusaka 分叉基线（Pectra 6 个 blobs）6目标6Fusaka9Pectra/Fusaka 最大10BPO1 目标14BPO2 目标15BPO1 最大21BPO2 最大Blob 数量0.0295886115GB

浏览了计算器的人会注意到，本地区块构建的要求显着增加。这是新纠删码的结果。考虑到 EIP-7870，本地区块构建者的最大上传带宽为 50mb，但我们的理论计算器显示，对于 BPO1 blob 计数值为 10 时，我们超过了这个值！这是怎么回事？幸运的是，核心开发人员掌握了一些技巧来帮助解决这个问题：

1. 分布式 Blob 构建

当一个区块在本地构建时，提议者发布该区块，然后发布所有 128 列。当另一个节点收到该区块时，它将首先检查自己的内存池中该区块引用的 blob。如果找到这些 blob，它就可以跳过下载并使用本地 blob。这里的主要好处是，对于验证者来说，区块变为 可证明的时间减少了，因为它不必等待通过 gossip 接收 blob。这对区块提议者有直接的好处，因为他们提议的区块将更快地变得可证明。 还有一个不错的副作用，即接收节点可能能够避免通过 gossipsub 下载 blob。

2. 使用 MEV 中继

在过去 14 天里，有 86% 的区块由 MEV 中继提供，现实情况是，很大一部分网络将获得 MEV 中继的帮助来发布他们的区块。虽然我们不想依赖这些中心化实体，但它们是主网上的一个事实，结合上面的其他两个技巧，我们有信心网络能够处理负载。

3. --max-blobs 标志

共识层客户端可能会附带一个 --max-blobs 标志，该标志将限制客户端提议区块时使用的 blob 数量。构建一个包含比你能上传的更多的 blob 的区块是没有意义的，所以这将是确保你不会错过任何提议的好方法。此功能仍在开发中，可能不会在你更新到与主网兼容的版本后立即在你的客户端中可用。

开发网数据

从理论要求退一步，我们可以查看从我们的开发网收集的数据，以更好地了解网络的要求。

• 过去几个月运行了多个开发网，但我们将重点关注来自 fusaka-devnet-5 的数据，因为它具有一定规模。
• 约 1700 个节点开发网（1/8 主网），与 Sunnyside labs 合作部署。
• 配置了 5 个 BPO，测试了高达 72 个 blob 的 blob 计数。我们将重点关注 21 个 blob 以下的范围，因为这些是建议的 BPO1 和 BPO2 的最大值。
• 我们针对我们现有的节点类型（超级节点、验证节点、完整节点）进行测试，因为每个节点都有不同的要求。

用于测试的节点

我们的基础设施如下所示：

• 对于超级节点：
  • 8 个 vCPU/32GB RAM/640GB SSD
  • 1000 Mbps 上传和下载速度
• 对于验证节点：
  • 8 个 vCPU / 16GB RAM
  • 100/50 Mbps 下载/上传，使用流量控制限制
  • 还有一些 ARM 节点以不同数量的验证器计数运行
• 对于完整节点：
  • 4 个 vCPU / 8GB RAM
  • 50/15Mbps 下载/上传，使用流量控制限制
  • 由 Sunnyside Labs 团队运行

在测试阶段，我们始终在每个 BPO 中有 2 个阶段。一半的时间用于使用 MEV，另一半的时间用于单独使用本地构建。这使我们能够收集两种类型网络设置的数据点。

BPO1 的开发网观察

🔍 点击放大

图 1.1：超级节点中使用 10 个 blob 的带宽

超级节点在 10 个 blob 的情况下显示出显着的带宽峰值：接收峰值约为 200 Mb/s，传输峰值约为 250 Mb/s，基线约为 50-100 Mb/s。

🔍 点击放大

图 1.2：验证节点中使用 10 个 blob 的带宽

验证节点（家庭质押者）显示出显着降低的要求：接收约为 15-20 Mb/s，传输约为 10-15 Mb/s。这证明了 PeerDAS 对家庭质押者的关键好处。

🔍 点击放大

图 1.3：完整节点中使用 10 个 blob 的带宽

完整节点具有最小的带宽需求：接收和传输均为 ~4-8 Mb/s。

🔍 点击放大

图 1.4：从 EL 获取而不是通过 gossip 获取的 blob 百分比

数据显示，整个网络的 blob 检索策略差异很大，从执行层获取的比率从 40-100% 不等。这意味着可以在区块验证管道中需要 blob 之前获取大部分 blob，从而减少了插槽关键部分的带宽需求。但是，此数据仅来自开发网，并不能证明我们会在主网上看到类似的数据。

BPO1 总结：在 10 个 blob 时，验证节点（家庭质押者）的观测带宽要求完全在 EIP-7870 规范范围内，该规范要求 50 Mbps 下载和 25 Mbps 上传。我们的开发网数据显示，两个方向的峰值约为 15-20 Mb/s，为其他操作留有余地。

BPO2 的开发网观察

🔍 点击放大

图 2.1：超级节点中使用 14 个 blob 的带宽

在 14 个 blob 的情况下，超级节点面临更高的需求：接收峰值约为 400 Mb/s，传输峰值约为 300 Mb/s。但是，忽略峰值，基线数据使用量似乎约为 100 Mb/s。较高的 blob 计数显然放大了超级节点的带宽需求。

🔍 点击放大

图 2.2：验证节点中使用 14 个 blob 的带宽

即使在 14 个 blob 的情况下，验证节点仍保持合理的要求：两个方向均约为 17-25 Mb/s。

🔍 点击放大

图 2.3：完整节点中使用 14 个 blob 的带宽

完整节点在 14 个 blob 的情况下继续显示最小的带宽需求：接收和传输均为 ~8 Mb/s。

🔍 点击放大

图 2.4：从 EL 获取而不是通过 gossip 获取的 blob 百分比

在 14 个 blob 的情况下，网络继续显示出不同的 blob 检索模式，EL 获取率从 20-90% 不等。我们看到，即使对于受控网络，命中率也会随着 blob 数量的增加而降低。但是，此数据不能代表主网的行为，我们需要进行额外的监控才能了解主网上的行为。

BPO2 总结：即使在较高的 14 个 blob 计数下，验证节点仍保持在 EIP-7870 家庭质押者的带宽限制（50 Mbps 下载，25 Mbps 上传）内。观测到的两个方向的 ~17-25 Mb/s 仍然是拥有本地提议的普通家庭质押者可以实现的。

一般注意事项

• BPO 流量很难确定，因为尚不清楚公共内存池流量在 blob 增加时将占多少。从理论上讲，随着我们增加目标 blob 计数，内存池应该会看到更多的流量 - 但这仅仅是因为存在私有内存池而做出的假设。
• 文档中提供的值可以用作高级指南，请确保你有额外的可用带宽来考虑工程余量。一旦 Fusaka 在主网上线，我们将获得实时数据，并可以使用更准确的信息更新分析。
• 文档前面提出的理论值没有捕捉到运行节点的细微差别，例如 EL 上的内存池流量、向对等方提供同步状态和其他后台 gossip。

总结

• 家庭质押者：验证节点需要 ~25 Mb/s 带宽（在 EIP-7870 限制范围内），允许主网安全地扩展到 14 个 blob。
• 有效的负载分配：超级节点处理骨干要求（200-400 Mb/s 峰值），而完整节点以最小的带宽运行（4-8 Mb/s），这证明了 PeerDAS 的可扩展性优势。
• 分布式 blob 构建有所帮助：从执行层内存池本地检索 blob 可以帮助减少关键验证期间的 gossip 带宽。

此数据支持在保持去中心化的同时继续进行 Fusaka 的发布计划。我们将继续监控主网上 Fusaka 的发布，因为情况可能与开发网测试不同。

后续阅读：

另请阅读 Sunnyside labs 团队提供的分析，在此处 找到。 它们更详细地介绍了流量类型的细分以及优化。

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