🚨 Sunnyside devnet 报告（09/30）刚刚发布——关于 devnet-5 运行在 ~11% 主网规模（~1.7K 完整节点）。 如果你关心 blob 扩展和网络限制，这篇文章是必读的。 一条线程 🧵

devnet-5上的blob吞吐量维持在22/33个blob，并扩展到48/72个，气体使用量接近~45M。 最大的限制因素是网络容量：上传限制为50Mbps的全节点在48/72个blob时不断达到上限。

与我们之前的小型开发网络不同，EL P2P 对于全节点的峰值完全超越了 gossip，导致在规模上产生了新的不稳定性。网络的 EL 方面现在是主要的波动来源。 列 gossip 上传峰值有所缓解，可能是因为 EL 流量已经饱和了带宽，节点有更多的 CL 对等体来共享列请求。

在可用性方面，GetBlobsV2 的可靠性在更高负载下明显下降。 Geth 和 Nethermind 的 blob 可用性高于命中率，这表明它们通常只持有部分 blob——这暗示允许从 GetBlobs API 返回部分数据可能有助于在更高 blob 数量下提升 CL 性能。 与此同时，Reth 的 GetBlobAPI 性能大幅提升，节点数量翻倍（约 120 对比约 40-60），最终摆脱了过去的同步/内存溢出问题。

结论： Fusaka 将为 L2 解锁更多的 blob 支持，而当前计划中的 BPO 将扩展到每个区块目标 14 个 blob（最多 21 个）。要超越这个限制，需要仔细关注本报告中强调的关键瓶颈——即上传带宽、P2P 网络稳定性和客户端特定的异常情况。 当前的优先事项应是提高带宽效率和优化客户端 blob 处理，例如通过 GetBlobs API 启用部分返回。 Sunnyside Labs 始终致力于推进这些领域，并将继续努力将 blob 吞吐量推向极限——但始终以确保网络安全可靠的方式进行。