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

在这些努力中，Sunnyside 的角色是以多种不同的配置运行每周的开发网络，并向核心开发人员提供结果见解： • 当前 PeerDAS 的限制在哪里 • 到底哪些组件造成了瓶颈 • Supernodes 和 GetBlobV2 等优化在实践中效果如何

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

在本周，我们操作了12个开发网络，并运行了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 激活后是否能够顺利参与，本测试应用了网络限制，并检查了在各种受限场景下哪些因素成为瓶颈。 在多次测试中，我们发现节点带宽使用量周期性地激增——尤其是在一个时隙开始时，当数据块被传播时——这些激增限制了整体网络性能。突发流量在节点之间均匀发生，而不是由特定的 CL 或 EL 客户端引起的，一旦突发开始，网络就无法进一步增加数据块的吞吐量。 换句话说，突发流量是带宽受限环境中最大的瓶颈，我们需要找到减轻这种情况的方法。

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

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