_2024-08-19_

# EPF5: Week 10

During this week I ran again into some issues with the simulation... It never ends. However, now I believe we really are in a good spot to start testing. Let me tell you about the issues I faced and my plan for the next week!

## Blobssss

For simulations with PeerDAS, it is rather important to have some blob transactions (duh). First, I tried integrating [`blob-spammer` by EthPandaOps](https://github.com/ethpandaops/goomy-blob/tree/master), which is also used in Kurtosis. While it spammed blocks well enough, it unfortunately has some strange performance issues which block the simulation for a few seconds every slot. That is unacceptable.

This is why I implemented [`blobssss` (Blob Spammer for Simulations, Stupid Simple)](https://github.com/dknopik/blobssss), which only has the most basic features I require. At first, it did not work properly (which was my bad), so I tried a third solution: [`tx-fuzz` by Marius van der Wijden](https://github.com/MariusVanDerWijden/tx-fuzz), for which he implemented a basic blob spammer. During my first few times trying it, it crashed approximately a quarter of the Reth instances in my simulation with segmentation faults, even though the spammer only connected to one :cold_sweat:. Trying to figure out why this crash occurs was very hard - the core dumps were very misleading, as the techniques used by Shadow's injected shim masked the actual issue at first, so I spent a lot of time investigating Shadow. The actual culprit was a known issue of [miscompilation of Reth](https://github.com/paradigmxyz/reth/issues/9955) in recent versions of Rust :face_palm: - omitting the flag for optimizations targeting my CPU fixed it. So much wasted time. Oh well.

Trying again with `tx-fuzz`, it seemed a bit buggy still as no blob transactions were spammed, so in the end, I fixed my own blob spammer, and will go ahead with that one.

## Unstable Network

Happily spamming blobs, I tried some small simulations on my laptop, which supports up to 38 nodes. As soon as the spamming start, the network quickly falls apart, with many missed slots and and some nodes losing sync completely.

I feared that the pseudo geographic distribution of the nodes was imposing too harsh conditions, but it turned out that there are simply not enough subscriptions on the blob column subnets for a sustainable network. Adding a flag to have every node subscribe to every subnet vastly improved behaviour and I belive having more nodes would also fix that issue.

## Next week

Ok, but now for real: Large simulations!

I already prepared a Makefile to quickly get simulations up and running from scratch, so all that is left is to make sure my experiment series well thought out and then go ahead with it!

...unless I find some issues with large simulatons... ;(