# How to help self builders with blobs According to [Toni's analysis](https://ethresear.ch/t/blobs-reorgs-and-the-role-of-mev-boost/19783/3?u=nero_eth), self builders currently suffer more from including blobs by incurring reorgs. Since most self builders probably don't play timing games, this cannot be attributed to late proposing. # Mitigation options 1. Allow easy configuration of maximum number of blobs to include Several builders already limit the number of blobs they include, currently self builders aren't doing this. 2. Allow configuration of minimum tip for blob tx Currently most blob transactions come with a very small tip, so the rational strategy is probably to not include any until the tip is increased. Especially for self builders with higher reorg risk, it might be worth just not including them until they are compensated for the risk. (However, in equilibrium this probably leads to lower returns from blobs for self builders, as professional builders incur lower risk from including blobs) # Introduce "decentralized blob building" ## Before PeerDAS Assuming that self builders only include transactions from the mempool, other nodes should already have the blob data included in the block. We can add a new validation rule that will accept a blob as available if it's part of any transaction in the mempool. Since not all transactions will be perfectly distributed in the mempool, we should add a rule that allows nodes to repackage existing transactions into blobs: 1. Upon receiving a block, a node checks its mempool for all blob transactions with existing blobs 2. For each missing blob sidecar, if it can find the blob data in the mempool, the node constructs the missing blob sidecar from the block header and the blob data. 3. For all such reconstructed blob sidecar, the node treats them just like it would treat a sidecar received via P2P. The self-building proposer can then change their distribution strategy to send the block first, and only send the sidecars once the blob has been sent out to enough peers, betting that many of its peers will also create blob sidecars. ## After PeerDAS With PeerDAS, it isn't possible to construct the samples unless a node has all the blob data (this actually improves with a 2d construction, which allows for a more distributed seeding of samples). Only nodes that have all the blobs could participate in seeding. This makes it a little bit more risky to use the same strategy as above, since many nodes could be missing just 1-2 of the included blob transactions and therefore distribution could still be slow. However, a node can improve their chances by only including blob transactions that a large majority of their neighbours currently have in their mempools. A second trick to improve distribution is to use other nodes capabilities to reconstruct samples. For example, we can identify neighbours that subscribe to all sampling subnets, and first send them exactly half of our samples, so that they can reconstruct the full set and send them on all subnets. To summarize, a new strategy for sending samples that optimizes these points is: 1. When building a block, only include blob transactions that have been verified to be in 90% of peer's mempools. 2. Send the signed blob first 3. After the block has been sent to a sufficient number of peers, send exactly 50% of samples to neighbours that are subscribed to all samples subnets (and therefore expected to reconstruct) 4. Once finished, send samples to all peers as usual