Gossipsub peers are separate from the ETH2 RPC protocol, and thus cannot
rely on the application-level `Status` negotiation to establish if
they're on the same network.
Segregating gossipsub topics by fork version decouples RPC from gossip
further and allows peers to more easily listen only to the traffic of
the network they're interested in, without further negotiation.
The duration of HISTORICAL_ROOTS_LIMIT is:
SECONDS_PER_SLOT * SLOTS_PER_HISTORICAL_ROOT * HISTORICAL_ROOTS_LIMIT
which is
12s * 2^13 * 2^24 = 1.65e12s = 52,262 years
This change simplifies the protocol and removes a race condition between
block request and response. In the case of honest server, this helps
serve the canonical / fork-chosen chain better while dishonest or broken
servers still need to be handled the same way.
Might as well get started on versions and upgrade it to 2, since the
change is backwards incompatible.
Only store a 32 byte root for every shard block
Rationale: originally, I added shard block chunking (store 4 chunks for every shard block instead of one root) to facilitate construction of data availability roots. However, it turns out that there is an easier technique. Set the width of the data availability rectangle's rows to be 1/4 the max size of a shard block, so each block would fill multiple rows. Then, non-full blocks will generally create lots of zero rows. For example if the block bodies are `31415926535` and `897932` with a max size of 24 bytes, the rows might look like this:
```
31415926
53500000
00000000
89793200
00000000
00000000
```
Zero rows would extend rightward to complete zero rows, and when extending downward we can count the number of zero rows, and reduce the number of extra rows that we make, so we only make a new row for every nonzero row in the original data. This way we get only a close-to-optimal ~4-5x blowup in the data even if the data has zero rows in the middle.