Gossip block parts in order instead of randomly

[evan-forbes]

The reasoning afaiu behind gossiping block parts randomly is to attempt to distribute block data in parallel. This works by the proposer's peer's flood subbing the block parts that they receive. In theory, this results in significant efficiency and speed gains, but as we can see in our experiments, each peer is effectively uploading and downloading the entire block.

The proposer is also sending all block parts to all peers anyway, so the proposer gains nothing from an efficiency point of view. If we run simple simulations, we see that block parts distributed to all of the proposer's peers around the same time results in half of the hops normally required to distribute block parts, and that the added delay from the proposer contributes more to duplication than it does to increasing throughput.

Since comet is gossiping block data during the proposal period and not before hand, and bandwidth is not being fully utilized, it must optimize for speed over efficiency to maximize throughput.

[cmwaters]

I don't understand fully why gossiping in order as opposed to randomly would change things.

I understand that if we were to give block part 1 to peer 1 and block part 2 to peer 2 and so forth in that order that might make things faster because we can get out block part 2 much earlier to the network