You can find all published reports here:

Sunnyside Devnet Reports (Internal)

Overview

• Our fusaka-devnet-3 spec mixed devnet achieved 72 blobs/block across all scenarios—including bandwidth‑limited runs—and sustained >60 blobs/block (10‑min avg) under 60 M gas, a 25% supernode / 75% full‑node mix, and caps of 1 Gbps/500 Mbps (supernodes) and 50/25 Mbps (fullnodes).
• As load increased, stability degraded: block time became unstable past ~60 blobs in blob‑only baseline, ~45 blobs with +30 M gas, and ~30 blobs under bandwidth caps—coinciding with fullnode uplink saturation at 25 Mbps, slower propagation (~7 s avg at peak), higher attestation disagreement, and reorgs (78 then 120 in the two consecutive runs).
• GetBlobsV2 under high blob load varied by EL: Geth showed the highest availability and hit rate; Besu degraded most; Nethermind reported higher average blob‑pool availability than Reth but a lower hit rate, implying fewer complete per‑block blob sets.

Introduction

This was a short mixed-devnet run executed while preparing for fusaka‑devnet‑4 with EthPandaOps, but it still produced useful signal. We operated a fusaka-devnet-3 spec devnet with 25% supernodes and 75% full nodes, applying a gigabit cap to supernodes and 25/50 Mbps up/down to fullnodes. We raised the gas limit to 60 M and targeted ~30 M gas per block in the “large tx” phases. We staged the load step-by-step: start with baseline (only blobs or only large transactions), then combine the two, and finally apply bandwidth limits. The intent was to extrapolate toward fusaka-devnet‑4, which will push blob targets toward 48/72 under proportionally less supernodes, higher gas, and bounded bandwidth.

Devnet Information

Setup & Configurations

Test Scenarios

• 1Gbps Download
• 500Mbps Upload Fullnode:
• 50Mbps Download
• 25Mbps Upload | Grafana (1st run) Xatu (a) Grafana (2nd run) Xatu (b) |

Results

1. Blob Throughput

Blob throughput in a bandwidth-limited scenario

Gas usage in a bandwidth-limited scenario

Average block time in a bandwidth-limited scenario

Across all scenarios—including the bandwidth‑limited runs—we were able to deliver 72 blobs per block at peak and sustain >60 blobs on a 10‑minute average, which suggests the network can meet a 48/72 target in favorable conditions. Notably, this was achieved with fewer supernodes (1 in 4) and a higher gas limit (60 M) than earlier tests; the figures above reflect the bandwidth‑limited case. The primary area of concern is block time: instability (>14 s) began around ~60 blobs in the pure‑blob baseline, ~45 blobs when adding 30 M gas of transactions, and ~30 blobs when bandwidth constraints were applied.