arnetheduck
commented
1 year ago sooner rather than later
I'd even go further and say that we should move to a decoupled design given that it's more flexible and semantically closer to what blobs are meant to be - ie decoupled pieces of data with different lifetimes - this ensures that we don't put up artificial barriers for efficiency and engineering work that becomes difficult to do when the "official" protocol says things should be coupled and can lead to the ossification of a needlessly suboptimal approach - the simplicity gains seem temporary at best and increase total complexity at worst by adding constraints and constructs that naturally have no raison d'etre.
If it turns out at closer to the end that indeed there are no benefits to be had whatsoever, it's trivial to move back to a coupled design.
Episub, for all its benefits, looks unlikely to make it into the protocol by the eip4844 HF - I think it would be unwise to couple it (haha) with the coupling gossip in general, since it's largely an orthogoncal piece of work that should stand on its own and be switched to when it's ready - until that time, it's easier to reason about eip4844 in isolation and work on it based on existing gossip assumptions (ie episub might never happen).
terencechain
mkalinin
sauliusgrigaitis
Nashatyrev
AgeManning
There has been more discussion about alternative blob/block gossip designs including the possibility of decoupling blocks and blobs in gossipsub. @arnetheduck suggested large bandwidth reductions could be achieved by only listening to blobs and downloading blocks via a decoupled by-root request. The reverse, gossiping blocks and downloading blobs by root, is structurally similar to what full DAS might look like.
However, there are concerns about the potential for additional round trips of communication at each hop and the difficulty in knowing which nodes to request blobs from if blocks are gossiped without the associated blobs.
Episub is another way we can decrease bandwidth by reducing the gossip amplification factor. We’re still trying to understand to what degree this will have an impact, so far it seems it may be more beneficial in larger networks, but these are difficult to run reliably in testing. A solution where we only gossip one of blob/block would still benefit from episub because of the bandwidth reduction on other/existing topics.
It seems like we will stick with coupling in the near term but it may be worth exploring alternative designs sooner rather than later in case bandwidth or network propagation times look suspect in testing. I think it’s also worth discussing which of these we are prioritising to what degree: