Validity Sync process can be significantly optimized

[viquezclaudio]

Currently, full nodes are using the regular history store (which is also used by history nodes).

When doing the validity window sync process, we are also interested in syncing the history store in such a way that we can verify the history root of the latest macro block. For this purpose we download history chunks and apply historic transactions into the history store. In some cases, this is done from the beginning of the previous epoch: with a chain full of txns, this process can take several hours.

However, for verifying the history root, this is not needed, since having only the peaks should be sufficient.
Thus, a light history store (which keeps only the peaks) would be more efficient.
However, for this to work, we would need to implement requests, such that history nodes and full nodes can provide the peaks-only structure for the latest macro block (and the associated size proof) and from there, we request the transaction hashes within the validity window, going backward from latest macro block to the beginning of the validity window.

In cases where the validity window is crossing an epoch boundary, then we would need the size proof of the latest epoch in order to request the validity window hashes located in the previous epoch, thus, nodes serving this request would need to maintain a size proof of the previous epoch + a size proof of the current epoch, in order to consider and support both cases.

A further optimization improvement could take into consideration the fact that the chain is moving while the validity window is being synced, and since we are syncing backwards, then syncing the full validity window could no longer be necessary.