🚨 Sunnyside devnet report (09/30) just dropped — about the devnet-5 ran at ~11% mainnet scale (~1.7K full nodes). If you care about blob scaling & network limits, this is essential reading. A thread 🧵

The blob throughput at devnet-5 sustained 22/33 blobs, and was stretched to 48/72, with the gas usage peaking near ~45M. The biggest limiter was network capacity: fullnodes with 50Mbps upload caps hit the ceiling constantly at 48/72 blobs.

Unlike our previous small devnets, EL P2P spikes for the full nodes completely outpaced gossip, creating new instability at scale. The EL side of networking is now the dominant volatility source. The column gossip upload spikes eased, likely because EL traffic was already saturating bandwidth and nodes had more CL peers to share column requests.

On availability, GetBlobsV2 reliability clearly showed some degrades with higher load. Geth and Nethermind showed higher blob availability than the hit rate, suggesting they often held only partial blobs — hinting that allowing partial returns from the GetBlobs API could help CL performance at higher blob counts. Meanwhile, the GetBlobAPI performance of Reth has enhanced a lot, doubling peer counts (~120 vs ~40–60) and finally shaking off past sync/OOM issues.

Conclusion: Fusaka will unlock support for more blobs for L2s, while the currently scheduled BPOs will scale up to target of 14 blobs per block (with a maximum of 21). To go beyond this limit, careful attention is required to the critical bottlenecks highlighted in this report — namely upload bandwidth, P2P networking stability, and client-specific outliers. The immediate priority should be improving bandwidth efficiency and refining client blob handling, such as enabling partial returns via the GetBlobs API. Sunnyside Labs remains committed to advancing these areas and will continue working to push blob throughput to its limits — but always in a way that ensures the network operates safely and reliably.