[optimization] Strategy for pruning Headers and Shares

[Wondertan]

Hmm, does it make sense for light nodes to keep shares only for headers within unbonding period and not beyond? Same for headers, a light node may simply delete all the past headers beyond unbonding period, as it does not trust them anyway.

Originally posted by @Wondertan in #244 (comment)

[musalbas]

Ideally there should be an option for light clients should keep shares permanently so that they can participate in data storage, for security reasons (which they will only be queried in the worse case scenario e.g. full nodes will request the shares from them).

As we discussed in the offsite, there must be some node that does data availability sampling, that is able to share samples with full nodes, otherwise data availability sampling won't be secure as nodes can't reconstruct missing data.

[Wondertan]

@musalbas, what should be the default case: automated pruning of old shared or storing of old shares? Should we understand the storage costs before doing a decision or just stick with storing by default, as a security requirement? If that's a security requirement for the network, shouldn't we then forget about pruning at all?

[musalbas]

We can discuss what the defaults should be later, but at minimum the following must be true for the DAS story to be completed end-to-end:

there must be some node that does data availability sampling, that is able to share samples with full nodes, otherwise data availability sampling won't be secure as nodes can't reconstruct missing data

[adlerjohn]

My personal preference is for defaults to be more secure even if more burdensome. That being said, both options can be implemented and we can decide on defaults later.

[Wondertan]

Related to #2033