You can find all published reports here:

Sunnyside Devnet Reports (Internal)

Overview

• Most single CL devnets could reach ~72 blobs per block, but in this round Lighthouse & Teku peaked around 60, and Nimbus around 40. This underperformance may be due to using less validators (8 instead of 100).
• All tested EL clients supported ≥72 blobs/block (Reth required manual peer boosting to exceed ~40 blobs).
• Sustained loads: a 128-node mixed devnet remained stable for more than 48 hours at 60 blobs/block.
• 30 Mbps bandwidth cap: Single CL devnets achieved ~60 blobs/block and the 128-node devnet had ~45 blobs.
• Network usage: average bandwidth remained moderate (<20 Mbps at 60 blobs) even at high load, but short burst traffic (especially gossip at slot start) often hit the bandwidth ceiling and became the limiting factor.
• Findings on EL networking: comparing behaviors observed in peering and network usage.
• Resource usage: CPU utilization stayed low across tests, but RAM usage climbed steadily over long runs (the same already observed from Fusaka-Devnet-2)
• Genesis sync: All client pairs (CL+EL) synced from genesis except those with Geth, which hit a sync bug. A fix for Geth’s issue is in review

Introduction

We focused this round of Sunnyside devnets on network bandwidth benchmarking under high blob throughput, using the latest Fusaka-Devnet-2 spec images for each client. In previous tests, an unrealistically high validator count (100 per node) was used for fullnodes; this time we reduced to 8 validators per fullnode for a more realistic setup. We ran a series of devnets covering every major CL client (each paired with a default EL) and each major EL client (paired with a default CL, Prysm). We also launched one Mixed Devnet with 128 nodes (a mix of 4 CLs x 4 ELs, 8 nodes of each combination) to observe interoperability.

Our analysis emphasizes network usage and the impact of bandwidth limits at high blob throughput, while also monitoring other data & tests such as CPU/RAM usage and genesis sync tests.

Methods

We ran 12 devnets in total. Each devnet underwent up to three sequential test phases (Test 1 → Test 2 → Test 3), with progression contingent on success at the previous phase (if a devnet failed or yielded insufficient data in one phase, later phases were skipped).

Test 1: Blob Throughput Benchmarking

We gradually increased the number of blobs per block (by 1 every 5 minutes) until the devnet either reached a target maximum (≥72 blobs) or the chain failed. This could give an indication to each client’s current maximum sustainable blobs-per-block and identified at what throughput the network or clients break. The results guided which blob rates to use in the next tests (for example, we chose 48, 60, 72, 84 blobs/block as standardized rates depending on what each devnet could handle). (Note: Single-client EL-only devnets only ran Test 1, since their purpose was solely to gauge max blobs in this round; they did not continue to Test 2-3.)

Test 2: Network Bandwidth Benchmarking