Fusaka-Devnet-5 将 Blob 作为参数的（BPO）分析

介绍

Fusaka 正在快速临近，现在是开始选择 Blob Parameter Only（仅 Blob 参数）分叉值的时候了。这些是小型硬分叉，其中唯一改变的是 blob 数量。它们为核心开发者提供了一种机制，可以在没有完全成熟的硬分叉协调开销的情况下安全地扩展链。开发者目前的想法是，Fusaka 发布时会带有一些安全的初始 blob 数量值，收集数据，然后在不久之后更有信心地进行更激进的扩展。

但是，我们应该将这些初始值设置为多少呢？我们需要选择一些安全的值，同时也要提供足够的数据来深入了解未来的 BPO 值。这就是 fusaka-devnet-5 的用武之地。

Fusaka-Devnet-5

与 Sunnyside Labs 合作 ❤️

这个网络与其说是一个网络，不如说是一个冒烟测试。我们正在检查事情在根本层面上是否可行，但除此之外没有太多。

该网络具有较高的节点数量 (1-2k)，以帮助弥合这一差距，但这仍然只有主网的约 1/8。不幸的是，这带来了一定程度的混乱。单独维护节点变得不可行，对于人类来说，漏洞会迅速变得难以弥补。在撰写本文时，有 50-100 个节点未正确证明的比例高于 50%。

在这个网络的整个生命周期中，我们也踩了一些坑：

• 节点配置错误

由于 ethPandaOps 方面的 Ansible 中的配置错误，大约 700 个“完整”节点在带宽受限的情况下保管着所有列。这已在 2025 年 9 月 17 日 UTC 时间下午 6 点左右修复。

• 多个客户端错误

这是一个很棒的结果 - 在开发网络周期中发现这些问题总是更好，但这为数据提供了另一层噪声，很难穿透。

鉴于以上情况，只有相对较短的可用数据窗口（约 12 小时）。 这也带来了额外的挑战，因为某些测试场景的交易量相对较低。鉴于这种情况，我们对这里发现的数据的信心相当低，但这应该可以完成解锁我们在初始测试网 BPO 值上的工作。我们可能会在未来几周内运行 fusaka-devnet-6，以提高对此处发现的数字的信心。

此数据和分析仅仅是一个起点。

分析

我们将专注于这些最大 Blob 数量选项的可行性：

我们使用一个名为“Head attestation immediately correct %”（头部证明立即正确百分比）的指标。我们将其定义为投票支持其职责Slot中的区块（不是父区块）的证明。这意味着验证者在 4 秒之前看到了该区块和所需的列。如果证明者投票支持父区块，则意味着他们没有及时看到该区块/列。这会将网络中的许多复杂性，如分布式 blob 构建、传播、区块处理时间等，捆绑到一个简洁的指标中。

通过 Xatu，我们可以基于提议者和证明者两侧，在多个维度上过滤和分组这些数据。例如，“显示由所有超级节点提议并通过 mev-relay 提议时，由 Lodestar 常规节点证明的Slot，按提议者 CL 类型分组”

测试 1：完整节点可以在没有 MEV-Boost 的情况下提议区块吗？

根据 EIP-7870，完整节点有 50mb 的上传带宽可供使用。他们必须将所有 128 列传播给他们的对等节点，并且 66% 的Slot证明者必须在 4 秒之前看到这些列。对于我们最敏感的带宽网络贡献者来说，这是一个艰巨的要求，我们预计会在某个地方达到一个临界点。

数据过滤器

• 12 小时的数据
• 仅本地构建的区块
• 由完整节点提议
  • 排除 Prysm，因为它在整个时间窗口内存在区块提议错误
  • 排除 Nimbus，因为它是一个严重的异常值，表明存在客户端特定问题
• 由所有节点类型（完整+超级）证明
  • 排除 Nimbus（原因同上）
  • 排除 Lodestar，因为它在整个时间窗口内有大量节点存在问题

该网络只有 10% 的有效余额在完整节点上运行。再加上需要过滤掉 Prysm 和 Nimbus 提议，它们占我们完整节点有效余额的 40%，我们真的很难获得数据。尽管如此，我们仍然可以深入研究。

结果

鉴于以上情况，我们只有 100 个Slot的数据可供使用。但我们实际上只是在检查这些 blob 数量是否在根本上可行，这会有所帮助。

图 2.1：按提议者 CL 分组的头部正确性

在这里关注提议者方面，超过 21 个 blob 时似乎会出现下降。Lighthouse 的表现强劲。

图 2.2：按证明者 CL-EL 分组的头部正确性

在这里查看等式的证明者方面。这在所有证明者 CL-EL 组合中都观察到，这表明提议者承受着压力。

图 2.3：仅由 Lighthouse 提议的区块的按证明者 CL-EL 分组的头部正确性

我们之前注意到 Lighthouse 的提议性能很强，因此我们可以放大仅他们的区块提议。令人惊讶的是，21-31 个 blob 的存储桶显示出生命的迹象，并且在理论上是可能的。这表明，当涉及到为我们对带宽敏感的运营商推送 blob 数量时，可能还有更多的潜力可以从客户端中挖掘出来。也许有一些东西潜伏在 libp2p 实现中？留给哲学家们去思考。

结果

✓ 15 个 Blob 可行

✓ 21 个 Blob 可行

⚠ 32 个 Blob 边缘

测试 2：超级节点能否及时看到最大 blob 数量下的 128 列？

节点只有在看到他们保管的所有列后才会证明一个区块。在超级节点的情况下，这是所有 128 列。我们需要断言这些节点可以始终在 4 秒之前看到所有列。令人担心的是，只需要 1 列到达较晚，就会导致很大一部分验证者不会证明该区块。

数据过滤器：

• 约 14 小时的数据
• 所有区块来源（本地和 mev 中继）
• 由超级节点提议
  • 排除 Prysm，因为它在整个时间窗口内存在区块提议错误
  • 排除 Nimbus，因为它是一个严重的异常值，表明存在客户端特定问题
• 由超级节点证明
  • 排除 Nimbus（原因同上）
  • 排除 Lodestar，因为它在整个时间窗口内有大量节点存在问题

结果

图 2.1：按提议者 CL 分组的头部正确性

图 2.2：按证明者 CL+EL 分组的头部正确性

这里等式的两边都显示出强劲的结果。随着 blob 数量的增加，我们似乎没有遇到任何瓶颈。

✓ 15 个 Blob 可行

✓ 21 个 Blob 可行

✓ 32 个 Blob 可行

测试 3：网络可以及时恢复列吗？

如果提议者未能发布单个列，网络是否可以及时恢复该列以保存该Slot？某些 Lighthouse 节点已被配置为在提议区块时随机保留一个列。

结果

所有测试的Slot都成功恢复了被保留的列并成为规范的，实现了立即证明正确性，与网络的平均水平相当。

✓ 15 个 Blob 可行

✓ 21 个 Blob 可行

✓ 32 个 Blob 可行

测试 4：新节点可以加入网络吗？

Syncoor 已部署到 fusaka-devnet-5，并且一直在进行频繁的同步测试。感谢我们团队的 Skylenet 提供这个闪亮的新工具！Syncoor UI 具有关于运行时和利用率的深入指标。

结果

新节点能够以相当线性的时间方式加入网络，无论是完整节点还是超级节点。Syncoor 在网络持续时间内进行了约 3500 次同步测试 👑

图 4.1：完整节点能够同步到网络的头部

图 4.2：超级节点能够同步到网络的头部

图 4.3：fusaka-devnet-5 上的 Erigon 同步时间

Erigon 在这里有点异常。它的时间以相当快的速度增长，并且通常比其他 EL 慢得多，但这很可能与网络上缺乏种子基础设施有关。这是我们正在努力解决的问题，并且将在不久的将来提供。

✓ 15 个 Blob 可行

✓ 21 个 Blob 可行

✓ 32 个 Blob 可行

结论

fusaka-devnet-5 提供的挑战比我们希望的要多，但仍然提供了有价值的见解，了解网络在 blob 数量增加时的性能。必须重申的是，此处收集的数据样本量很小，并且 fusaka-devnet-5 并不代表主网。

Max = 15 安全的起点

测试结果

✓ 完整节点本地区块提议可靠地工作

✓ 超级节点舒适地处理所有 128 列

✓ 网络恢复机制平稳地运行

✓ 新节点可以无问题地同步

Max = 21 更好的数据，用于未来增加

测试结果

✓ 为未来扩展提供有价值的数据

✓ 比 15 选项多 40% 的 blob 容量

✓ 仍在安全的操作限制范围内

Max = 32 值得注意的挑战

测试结果

⚠ 完整节点在没有 MEV 中继的帮助下很难发布区块

✓ 超级节点充分地处理负载

✓ 网络恢复仍然有效

潜在的初始 BPO 计划

鉴于上述可行性，我们提出了一个计划，该计划结合了安全性、吞吐量增加和足够的数据来为未来的 BPO 决策提供信息。随着我们经历 Fusaka 的测试网阶段，这可能需要根据新出现的数据进行调整。

感谢

感谢在整个开发网络中与我们密切合作的客户端团队，以及运行大量节点的 Sunnyside Labs 团队！

🚀🚀🚀

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