# To couple or not: 4844 beacons and blobs A quick examination of why we may or may not want to couple beacon blocks and blobs on the networking layer in 4844. This is actually two different problems 1. Historic sync of beacon blocks (and blobs to some depth) 2. Realtime beacon block and blob gossip I argue that for (1) beacon blocks and blobs should remain decoupled to allow for minimally invasive changes when shipping 4844 as well as minimal changes again when shipping full danksharding. For (2), I can see the argument going in either direction -- coupling or not -- but do believe that *coupling* for gossip dissemination requires solving fewer problems and allows us to use more off-the-shelf code from prior forks. ## Historic sync For historic sync today, we already have blocks by root and by range requests, and these can go to a depth of *at least* `MIN_EPOCHS_FOR_BLOCK_REQUESTS` epochs (~5 months) on the p2p network. I argue that by coupling blobs into these requests, we complicate an existing protocol due to the *likely* more limited p2p guarantee that blobs have -- the 2 weeks or 1 month often discussed. Thus if coupled, `BlocksAndBlobsByRange` request now needs to account for depths at which the Blob supplied *may* be null (and potentially require a way to specify if you actually want the potential blobs depending on needs/state/depth). This complicates an existing protocol that ultimately will move back to not needing special logic in a full sharding world. Whereas, if we just add a `BlobsByRange` (and root) request, the Beacon Block sync mechanism remains unchanged now (and in full danksharding!) and the blob requests (to whatever p2p serving depth is spec'd) is added as a complementary mechanism that can either be done in parallel or as a task after filling in the blocks. And this can be transparently shifted to DAS in full danksharding -- again, not ever having to change the fundamental BeaconBlock sync methods/strategies. **Note**: it might make sense to use the `SignedBlob`s variant rather than just `Blob`s for these range requests. It probably doesn't detract from anything, but the signatures may or may not be useful in all contexts. For example, when doing historic sync, you may not know the assigned proposer for a given slot until after getting the associated beacon block -- thus the Blob signature might not provide any value if received prior to the beacon block request. ## Gossip In 4844 and in fulldanksharding gossip, there exists a race condition between receiving the `BeaconBlock` and receiving the full blobs or rows/columns (in 4844 and full sharding respectively). That is, you need the beacon block before deciding if a blob (or row/column) should be forwarded, and due to disparate gossip patterns, this may require moderate amounts of extra logic to handle locally and to optimize for the network in general. This race condition exists if BeaconBlocks and Blobs are decoupled in gossip in 4844, and definitely exists for row/column dissemination (and likely DHT seeding) in full sharding. We can construct a topic and network message `beaconblock_and_blobs` to sidestep this race condition in the meantime during 4844. This gossip topic will look almost exactly like the `beaconblock` topic today, but will have blobs as a sidecar in the network datastructure and some additional blob gossip validations. Or in 4844, we can side-step the problem by having the proposer also sign the blob sidecar (as currently spec'd). This does work, but (1) does not have the same crypto-economic dos resistance as blocks due to no slashing condition and (2) does not port easily to full danksharding because rows/columns are likely to stem from a Builder which may or may not be cryptoeconomically bonded and thus a signature may or may not carry weight. It does seem reasonable to side-step the gossip race condition in initial 4844 release. We can't avoid the race-condition issue entirely due to the full danksharding row/column dissemination and the additional challenges of seeding the DHT. But, as we've seen in the past, sometimes we can't accurately predict the future, so maybe we avoid the premature problem solving and just use a gossip dissemination almost exactly like what we have today. **Note:** In the event that we want to use more sophisticated methods of disribution of Blobs that find a trade-off between push vs pull on distribution to try to reduce bandwidth, then decoupling `BeaconBlock` and `Blob` gossip is requisite.