Key delegation prototype feedback

[danwt]

Problem

I'm working on the Key Delegation feature (issue) which will allow validators to submit a signed transaction TX to the provider with data [chainID, pubKey] which will ultimately cause them to need to start validating consumer chain with id chainID with the priv key associated to pubKey from when the consumer chain receives the next update via IBC.

I have prototyped the business logic of the algorithm for this at this branch.

The problem is: I want to get feedback on the design and decide if this is the best path forward.

Closing criteria

Gathered some feedback and I know the decided path forward.

Detail

I will flesh this section out tomorrow. Short story is:

The design enables validators to submit TX(chainID, pubKey) at any time and as often as they like. They must sign with their provider key and also with the priv key for pubKey. The design is implemented entirely on the provider, the consumer code will not need to change at all. The consumer does not 'know' anything special is going on.
The Validator Set Replication propert is maintained (but keys are mapped accordingly).

It's ensured that consumer initiated slashing will be possible for vscids vscid with greatestMaturedVscid < vscid where greatestMaturedVscid is the greatest one received on the provider for the consumer. (I've implemented but not tested this yet).

It's also ensured that old keys are eventually garbage collected (it's done at a latest maturity time).

The thing is: covering the corner cases results in a non trivial bit of code. I think a good approach might be to take a larger step back and change the overal CCV protocol to send entire active valsets to consumers instead of just diffs. This would make things a lot simpler.

[danwt]

After discussing I think will go with the working solution that requires least changes to established parts of the codebase/protocol