Overview

This report details the results of devnets evaluating how high-bandwidth nodes handle high blob transaction loads up until 72 blobs.

• The network sustained up to 72 blobs per block without breaking consensus.
• Differences in blobpool management were observed between execution clients, notably between geth and reth/besu.
• Some clients like lodestar showed slower block propagation times.
• Resource usage (bandwidth, CPU, and memory) remains within acceptable ranges, though some clients show areas for further optimization.

Background

Sunnyside is currently running 2 devnets: https://github.com/testinprod-io/ethereum-devnets/tree/main

• pectra-devnet-ssl-1
• peerdas-devnet-ssl-1

Both of them are provisioned on digitalocean across multiple regions. You can find the node count and validator ranges here:

• pectra denet
• peerdas devnet

Test Scenario

Each devnet was configured with tx-fuzz to send fuzzed blob transactions to the network, starting from 1 blobs per block to 72 blobs per block, incrementing by a single blob every 10 minutes. We also populated the network with 20-30 regular transactions per block as well.

Note that the blob increment and its inclusion in a block is not consistent because blobs are sometimes not included in time. We could later improve the fuzzing methodology to provide more granular and consistent control on transactions.