Proposal for block header lookup via block number in the history network

[KolbyML]

Offshoot of this PR https://github.com/ethereum/portal-network-specs/pull/333 you can read for a deeper background or reasoning.

In the other PR I list Pro's and Con's of certain block index model's and in the end come to the conclusion that it would probably just make more sense to store these values in the History network, as the total storage size for these indexes will be around 22ish GB with proofs. Which is extremely small in comparison with the requirements to store block bodies and receipts which is around 749.94GB so I think it is well justified.

In the same note we have previously discussed https://github.com/ethereum/portal-network-specs/pull/268 removing epoch accumulator history network content type, but decided not to due to not having a better solution during the time.

With this proposal we add block number -> block header lookup capabilities

Here is a copy paste from my other PR why we want these indexes

• Most JSON-RPC calls support requesting data by block number
• ETH Call requires block number -> block hash indexes for the last 256 blocks (in Portal's case we would need access to all the blocks 0 to latest to properly support eth call)
• Being able to fetch header's by block number is more intuitive and easier to get what you want, our current model requires you to start from the latest block header from the beacon network and walk back to your desired block header, so potentially if you wanted the block header for block 1 you would have to fetch 20 million headers which is a little overkill

In short this proposal offers a much better UX experience and enables us to properly implement the JSON-RPC

[bhartnett]

Great idea here. Currently in Fluffy, our state endpoints implementation (eth_getBalance, eth_getCode, ... etc) does two lookups in order to get the state root which is required in order to return any state data. The first lookup gets the block hash for the given block number by looking up the epoch record and then looking up the block header via block hash to get the state root. With this change we will only need one history network lookup instead of two.