There are a few things to note here:
- Spikes are only happening if you have the bandwidth for them. If not, it is smoothed out by the network. It is a side-effect of testing with high bandwidth nodes, NOT a requirement.
- How the network behaves when you don’t have the bandwidth for spikes and spikes are smoothed out is something to study separately. For this we have run tests with bandwidth restrictions, but there is still more space for testing. We are doing such tests and we will do these more intensively as we go towards higher blob counts.
- For lower blob counts bandwidth requirement is definitely not in the hundreds of Mbps range. E.g., 10blobs/12sec is less then 1 blob/sec. Even if you would subscribe to all 128 column subnets, that’s less than 256 KB/s of data. Even if you add overhead, you are not going into the hundreds of Mbps space, you are in the single digit Mbps space.
- GossipSub is adapting to available bandwidth to some extent already, and we are working on making it adapt more (see push-pull phase transition, lazy push, partial messages, etc.)
- if one does not have the bandwidth, it should be perfectly fine to subscribe to 64 column only, and use CPU power to decode the blobs.
- if one also doesn’t have the bandwidth to subscribe to 64 columns, subscribing to less and retrieving only the relevant blobs, filtering on the sender address, would also be fine. However, in the CL, in the current version we don’t have row topics or row-based ReqResp to support this well. These are part of the FullDAS design, but not in current PeerDAS. But we can work on adding them.
- as a middle-ground, and without row-topics or partial messages, one could also think of requesting all the column of only the blocks that have relevant blob transactions. I don’t think we need this, as we have partial messages close to being finalized already.