IntersectMBO
Only download block bodies in the block fetch client
After all, we have already downloaded the headers in the chain sync client, so there is no need to download those again. Crucially, this will allow an important optimization where we can skip downloading the block body altogether for empty blocks, which make up a significant proportion of the current chain.
@coot I removed the Consensus label. I think this is a Networking Issue, since the Networking Team is still the primary owner of BlockFetch---at least this kind of decision around... at least in my opinion (but I admit it's a gray zone).
A slightly better approach is to just download block bodies in block-fetch protocol, right now we are duplicating downloading headers which we already know from chain-sync.
I don't see the need for this, it also has disadvantages.
If blocks are empty the whole chain is basically just ticking over (no txs) - so the saved resources (given we fetch the block from one/small number of nodes) are minimal.
We also loose information - we would loose the 'who supplied this block first' and the contribution to the ∆Q for the client - this means that churn would less well informed.
It would also raise the issue of what would happen during prolonged periods of idleness - the churn would basically based solely on header distribution times which may make the topology stray from the optimality we are seeking - optimally we might need when the chain became busy again.
I strongly suggest that this is a an 'over optimisation' that causes us to loose information about network performance.
@njd42 if block-fetch just downloads block bodies (since headers we already have), we will still know who offered the block first.
It's not not just about optimising when the network is idle, although the impact will be the largest. It saves less than a tcp segment since headers fits into it, so quite likely the optimisation is not that big. But it's also a low hanging fruit - implementation should be quite easy.
I disagree - this creates a testing and validation overhead that will persist for all time. TCO for this change doesn't make sense
It's something we should validte, it's hard to judge how much negative impact this will have when a node is synced; but it will save bandwidth when a node is syncing though - so might be worth to consider for wallets.