Sunnyside 的 7/14 PeerDAS Devnet 报告来了！ 让我们深入了解 PeerDAS 的当前状态 - 我们能处理多少 blob，瓶颈在哪里？

在这些工作中，Sunnyside 的职责是每周以许多不同的配置运行开发网，并将由此产生的见解提供给核心开发人员： •当前 PeerDAS 限制所在 •究竟哪些组件造成了瓶颈 •超级节点和 GetBlobV2 等优化在实践中的效果如何

我们的主要目标是以补充其他团队（如 @ethPandaOps）在 fusaka-devents 所做的事情的方式快速灵活地进行测试，提供及时的反馈，以支持 PeerDAS 的持续实施。

在本周，我们运行了 12 个 devnet，运行了 3 个测试套件，使用了 @ethPandaOps 最新的 fusaka-devnet-2 镜像： 1.Blob 吞吐量（每个区块的最大 blob） 2. 网络带宽（持续负载测试） 3. 带宽限制（30 / 20 / 10 Mbps 上限）

1 – Blob 吞吐量测试 测试结果显示，大多数 CL 客户端每个块可以处理 84 个或更多 blob，并且至少有 40 个 blob 保持稳定。与以前的开发网相比，一些客户端记录的最大 blob 计数相对较低——但这可能是因为该开发网中每个节点的验证者计数从 100 减少到 8，这反过来又降低了每个节点的子网参与率。

2 – 网络带宽测试 与早期的开发网不同，早期的开发网在高 blob 数量下网络经常变得不稳定，这一次，即使每个块有 60 或 72 个 blob，所有开发网也能稳定运行较长时间（~16 小时）。虽然这并不能保证生产级的稳定性，但它表明至少一些CL-EL组合通过优化🚀实现了更高水平的鲁棒性

3 – 带宽约束测试 为了检查 PeerDAS 激活后，真正的家庭质押者是否能够顺利参与，该测试应用了网络限制，并检查了在各种受限场景下哪些因素成为瓶颈。 在多项测试中，我们发现节点带宽使用量会周期性地激增，尤其是在 blob 被八卦时，在插槽开始附近，并且这些峰值限制了整体网络性能。突发流量在节点之间均匀发生，而不是由特定的 CL 或 EL 客户端引起的，一旦突发开始，网络就无法进一步增加 blob 吞吐量。 换句话说，突发流量是带宽受限环境中最大的瓶颈，我们需要找到缓解它的方法。

此外，我们还与各个客户团队进行了沟通，并鼓励改进同步和对等相关问题。

Sunnyside 开发网仍在运行🏗️;使用多个客户端组合进行互作开发网、更精细的带宽测试、包括正常事务的垃圾邮件测试以及回填/同步测试，以识别更接近主网条件的环境中的瓶颈。