EPIC: validator consensus key rotation

[Hyung-bharvest]

• Related issue on tendermint : Validator key rotation tendermint/tendermint#1136
• We moved this issue from tendermint to cosmos-sdk repository because the implementation causes almost no change in tendermint codebase, and most changes are on cosmos-sdk

1. Objectives

• to provide validators ability to rotate their validator consensus key

2. Use-case Overview

• how to rotate consensus key mapping to validator operator?
  • create new random consensus key
  • create and broadcast a transaction(RotateValCons) that the new consensus key is now coupled with the validator operator with signature from validator wallet key
  • old consensus key becomes unable to participate on consensus after the update of key mapping state on-chain
  • start validating with new consensus key

3. Considerations

• consensus key mapping information management strategy
  • blockchain stores history of each key mapping changes.
  • gaiad can search (from kvstore) corresponding consensus key paired with given validator operator for any arbitrary height in recent unbonding period
  • gaiad does not need any historical mapping information which is past more than unbonding period
• limits
  • a validator cannot rotate its consensus key more than N time for any unbonding period, to prevent spams
  • a validator should contribute X atoms to community fund to rotate its consensus key, also to prevent spams
  • parameters can be decided by governance and stored in genesis file
• slash module
  • slash module can search corresponding consensus key for any height so that it can decide which consensus key is supposed to be used for given height
• pruning
  • blockchain does not need to keep the historical key mapping after unbonding period past.
  • when pruning is on, a node prunes all historical key mapping past unbonding period
• further implementation after this
  • rotation of validator wallet key
  • currently, validator wallet key and validator operator key is having identical root.
  • implementing rotation of validator wallet key will create a lot of necessary structural changes in original codebase

[alexanderbez]

Thanks @dlguddus for proposing this as it's definitely a valid use case!

Some immediate questions I have:

1. Why do we need this? What spam are you preventing here precisely?

a validator should contribute X atoms to community fund to rotate its consensus key, also to prevent spams

2. Is there still an issue in Tendermint? If not, there should be because I imagine there will be a significant amount of thought and work required in Tendermint too. You can't just submit a tx to Tendermint and have the state-machine take care of everything. Most likely, there will need to be some ABCI features and updates to allow this.

[Hyung-bharvest]

1. Both limits are to prevent too much consensus key changes which will cause computational overhead especially for slashing module. But as you asked, fee for rotation has weak reasoning. I guess we can remove that if there is no reasoning from others.

[alexanderbez]

Yes, I understand the limit on rotations for both space and time complexity, but community funds seems unnecessary.

[Hyung-bharvest]

I close this issue because it is now handled by below ADR

#5233

[tac0turtle]

closing this in favour of #18141