Change the PartSetHeader to allow for committing to arbitrary part schemes

[evan-forbes]

Currently, the proposal is gossiped using block parts. This, in theory, is highly advantageous because nodes can gossip the block in parallel and only partially to each of their peers. This should, again in theory not currently in practice, enable fast && efficient block propagation. The overall throughput should be able to far exceed that of the per peer bandwidth allocation.

Block propagation could be further improved by making it compatible with other optimizations. Mainly

• 1. Erasure encoded block propagation
• 2. Compact Blocks EPIC: Compact Blocks #883
• 3. Combining i. and ii.

i.

erasure encoded block parts would make block propagation even faster and more efficient because instead of waiting on the network to distribute 100% of the block, we only have to wait on the network distributing any 50% (or even 33% in some schemes) of the block to each peer. The block is of course 2x bigger (or 3x in the 33% case) but we would still never actually download more than the original block data. This would require changing the way that block parts are committed to, as we would need to first erasure encode them.

As previously attempted in #434, we could utilize the existing erasure encoding created in the application. While we would save some compute as we wouldn't have to erasure the block data twice, that currently is far from being even close to a bottleneck. It might add some complexity if we also need to incorporate compact blocks, since compact blocks benefit greatly from using individual txs as block parts and the square combines txs

ii.

Compact blocks are amazing not only because we are only gossiping block data once while retaining the benefits of a mempool, but also because we can gossip block data outside of the proposal period. Compact blocks also fit in extremely well with schemes that break the proposer monopoly, because the probability of gossiping redundant data is high when we have many block producers contributing to each block.

Using the existing block part scheme with compact blocks would be limited in benefit. While we would have the capability to distribute blocks quickly, in any scenario where we have to rely on distributing the block during the proposal period, we essentially revert to the current protocol. If the block part scheme was changed so that each transaction is a block part, then we would not lose the benefits of gossiping block data outside the proposal period. In this scenario, we would start gossiping blocks identically to how we normally would, except peers would start off with partially filled blocks.

iii.

If we combine both erasure encoding block parts and using individual transactions as block parts, we can get the best of both schemes. At that point, [imo] we are quickly getting into "state of the art gossiping protocol" territory.