authority-discovery: Keep the validator ID <-> PeerId mapping of past sessions

[tomaka]

In addition to the mapping of the current and next session, the authority discovery needs to be able to provide the PeerId/Multiaddr of validator IDs of past sessions, in order for disputes to work.

It is unclear how many sessions in the past we want to keep.

[mxinden]

More details in paritytech/polkadot#1461 (comment).

[rphmeier]

Can we implement this entire on the runtime API level (as @mxinden suggested elsewhere) just by returning the AuthorityIds of N past sessions from a particular runtime?

The only thing that we'd need to be sure of is that the authority-discovery service needs to publish a DHT record for every key in that list as opposed to only the first. However, that may already be the implemented behavior.

[mxinden]

Can we implement this entire on the runtime API level (as @mxinden suggested elsewhere) just by returning the AuthorityIds of N past sessions from a particular runtime?

Yes. Correct. This is done for the current and next authorities in #6788.

The only thing that we'd need to be sure of is that the authority-discovery service needs to publish a DHT record for every key in that list as opposed to only the first. However, that may already be the implemented behavior.

The authority discovery module publishes a record for each key in the key store. This has not been tested yet though.

[mxinden]

An implementation of this ticket should ensure that either (a) the resources required for a lookup of all authorities is negligible or (b) the lookup of all authorities is spread out over time, only requiring a negligible amount of resources at a given moment.

(Related discussion: #6788 (comment))

[bkchr]

This was done by just returning the all relevant authorities from the runtime.