History Network: Options to optimize for lower latency tranfers

[KolbyML]

In the history network we have three main pieces of content

• Headers with proofs
• Block Bodies
• Receipts

Headers can be proven canonical by utilizing the proof included with them, on the other hand block bodies and receipts to validate these pieces of content we need to fetch the header with proof.

Currently when validiting the canonicalness of block bodies and receipts we request the header with proof sequencially after recieving the respective block bodies or receipts. This causes a delay to when users can access this data. The reason we choose this route originally was because it was the quicker way to get a live product, but moving into launching looking into these paths seems more beneficitial.

Solution 1

Request the header at the same time you request the block bodies or receipts.

Solution 2

The header with proof is very small almost always less then 1200 bytes why not include it with block bodies and receipts. This lowers the amount of uTP connections we have to open minimizing congestion

• todo add pros and cons

[qizhou]

Nice write-up! I am thinking about a similar issue related to the state network as verifying an account/storage slot needs recursively lookup/verify the trie nodes (suppose an early version of Portal maintains a trie_hash => trie_node mapping).

One question is about the latency of the request that you observed?