You can find all published reports here:
List of Published Reports (Internal)
Overview
- For pectra devnet with 20% nodes bandwidth-limited (100Mbps / 50Mbps), the network could handle 15 blobs safely
- For peerdas devnet with 18 fullnodes, 16 supernodes, 8 custody requirement,
- network could handle 10 blobs per block.
- For pectra devnet with bandwidth-limited nodes,
- network usage mostly remained under 50Mbps while blobs ranged between 0-50
- non bandwidth-limited nodes could properly propose / progress the chain
- lodestar had higher block propagation times
Background
Sunnyside ran 3 tests during the past week:
- Run Pectra devnet with nodes with different bandwidth limits to identify any bottlenecks associated with bandwidth
- Run Pectra devnet with nodes with different bandwidth limits, and identify which blob count is sustainable for the network.
- Run PeerDAS devnet, and send fuzzed blob transactions until the network is unhealthy.
Blobs were fuzzed using spamoor tool, with its blobs scenario
Test 1
The identical test from last week was performed, but with different bandwidth limits:
| Bandwidth Limited Nodes |
Base |
Test A |
Test B |
Test C |
| No limit |
52 |
40 |
40 |
40 |
| 150 Mbps |
0 |
12 |
6 |
0 |
| 100 Mbps |
0 |
0 |
6 |
6 |
| 50 Mbps |
0 |
0 |
0 |
6 |
The bandwidth limits are larger than the 20Mbps commonly referred as “home staker” bandwidth, as we started to assume that network capacity of those nodes will increase as well.
The bandwidth was applied to the specific containers running in the node instead of the whole node. This was applied to both beacon and execution containers