Sunnyside Devnet Updates - 03/18

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

execution_container_id=$(docker inspect execution -f '{{.State.Pid}}')
mkdir -p /var/run/netns
ln -sfT /proc/$execution_container_id/ns/net /var/run/netns/execution
ip netns exec execution ip -br -c link
tc -n execution qdisc add dev eth0 handle 10: root tbf burst 32kbit rate {{ bandwidth }}mbit latency 100ms