Guide: Availability Recovery Subsystem

[rphmeier]

This subsystem is the inverse of the availability distribution subsystem: validators will serve the availability chunks kept in the availability store to nodes who connect to them. And the subsystem will also implement the other side: the logic for nodes to connect to validators, request availability pieces, and reconstruct the AvailableData.

One main difficulty will be addressing the fact that the pieces may have been made available during session N, while we are currently in session N+K, where session keys may have changed. Thus, we will expect some data that lives on-chain to allow us to determine the session in which some receipt was included, who the validators were during that session, and what their authority-discovery key was. This will enable us to do the necessary DHT lookup to find the node to connect to, as long as their actual address hasn't changed.

This data can live partially on-chain and mostly off-chain, by using the technique introduced in paritytech/substrate#6220, where the chain stores cryptographic commitments in the state and triggers a write to an off-chain database which is maintained by the full node.

[rphmeier]

When we recover available data, we need to then re-erasure code all the pieces (even though we've just recovered from 1/3 of the pieces) so we can ensure the erasure-root in the CandidateCommitments is valid.