Controller aka certifiers abstraction for session keys

[burdges]

Is there some reasonable certifier or controller abstraction with which concensus modules should manage their session keys?

It's likely always true that

• at most one key is valid for any particular "role" in a concensus module at any particular time, and
• any key used in concensus must be "certified" on-chain by some "controller".

I think controllers certifying the same new session keys should mostly be made "idempotent" by hashing the previous one, or maybe some counter, maybe with equivocations being slashable.

We have various concerns and variations around consensus keys like:

1. We cannot afaik foresee all ways consensus modules might transition epochs.
2. GRANDPA key changes propagate very slowly to lite clients.
3. BABE keys must be certified enough epochs in advance.
4. Any key producing shared randomness ala BABE, PVSS, etc. must change at fixed times.
5. Deserializing BLS public keys should check their proofs-of-possession (but see delinearization notes below [1])
6. Anything like PVSS or pre-announces for constant block time require usage at least one epoch in advance, so multiple keys can be active but in different roles.
7. It's unclear if keys can always be generated outside the concensus module itself because DFINITY-style VSS+VRF keys are created by DKG.

We'd love to advance keys to the most recent using this idempotence, but idempotence cannot permit updating keys in violation these restrictions 3, 4, 5*, 6, 7, and probably not 2 either.

We'd love more forward security aka key erasure of course, but any chain rollback can revert key roles, and must do so for keys producing shared randomness (3, 6, 7).

We can maybe however have some "roles" abstraction that permits using different keys for different functions. In future, if we discover some role prevents early key erasure then we might fork off a separate subsession key for that role, maybe using implicit certificates

cc @rphmeier @AlistairStewart

[1] There is an alternative to checking proofs-of-possession in which we delinearize all validator keys together, which maybe requires concensus on some superset of the current key set, and likely breaks this idempotence. I think delinearization sounds great for very small validator sets, as scalar multiplication is much faster than pairing, but proof-of-possession scales linearly in key deserializations, while delinearization scales quadraticly, specifically validator set size times number of validator key changes, which makes non-simulanious aka non-epochal key changes suck. I'd think imagine this again favors keys change only at fixed epoch boundaries, so like BABE requires anyways.