Sunnyside's 7/14 PeerDAS Devnet report is here! Let's dive into the current status of PeerDAS - how much blob can we handle, and what's the bottleneck?

Among those efforts, Sunnyside’s role is to run weekly devnets in many different configurations and feed core developers with the resulting insights: •Where the current PeerDAS limits lie •Exactly which components create bottlenecks •How well optimizations such as Supernodes and GetBlobV2 work in practice

Our main objective is to test quickly and flexibly in ways that complement what other teams like @ethPandaOps are doing at fusaka-devents, providing timely feedback that supports the ongoing implementation of PeerDAS.

In this week, we operated 12 devnets and ran 3 test suites, using @ethPandaOps’ latest fusaka-devnet-2 image: 1.Blob Throughput (max blobs per block) 2. Network Bandwidth (sustained-load test) 3. Bandwidth Constraining (30 / 20 / 10 Mbps caps)

1 – Blob Throughput Test Test results showed that most CL clients could handle 84 blobs per block or more, and remained stable with at least 40 blobs. Some clients recorded a relatively lower maximum blob count compared to previous devnets - but this may be because the validator count per node in this devnet was reduced from 100 to 8, which in turn lowered each node’s subnet participation rate.

2 – Network Bandwidth Test Unlike earlier devnets where the network often became unstable at high blob counts, this time all devnets ran stably for an extended period (~16 hours) even with 60 or 72 blobs per block. Although this does not guarantee production-level stability, it shows that at least some CL-EL combinations have achieved a much higher level of robustness through optimization 🚀

3 – Bandwidth Constraining Test To check whether real home stakers can participate smoothly once PeerDAS is active, this test applied network limits and examined which factors become bottlenecks under various constrained scenarios. Across multiple tests we discovered that node bandwidth usage periodically spikes - especially near the start of a slot when blobs are gossiped - and that these spikes limit overall network performance. Burst traffic occurred uniformly across nodes rather than being caused by a particular CL or EL client, and once bursts began, the network could not increase blob throughput any further. In other words, burst traffic is the largest bottleneck in bandwidth-constrained environments, and we need to find ways to mitigate it.

In addition, we communicated with various client teams and encouraged enhancements for sync and peer-related issues.

The Sunnyside devnet is still running 🏗️; conducting interop-devnets with multiple client combinations, more granular bandwidth tests, spam tests that include normal transactions, and backfill/sync tests, to identify bottlenecks in environments that more closely resemble mainnet conditions.