ADR 016: Validator consensus key rotation #5233
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,63 @@ | ||
| # ADR 016: Validator Consensus Key Rotation | ||
|
|
||
| ## Changelog | ||
|
|
||
| - 23-10-2019: initial draft | ||
|
|
||
| ## Context | ||
|
|
||
| Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator | ||
| key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of | ||
| validator consensus key rotation implementation mostly onto Cosmos-SDK. | ||
|
|
||
| ## Decision | ||
|
|
||
| ### Pseudo procedure for consensus key rotation | ||
|
|
||
| - create new random consensus key. | ||
| - create and broadcast a transaction(RotateValConsensusKey) that the new consensus key is now coupled with the validator operator with signature from validator wallet key. | ||
Hyung-bharvest marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - old consensus key becomes unable to participate on consensus immediately after the update of key mapping state on-chain. | ||
| - start validating with new consensus key. | ||
| - validators using HSM and KMS should update the consensus key in HSM to use the new rotated key for signing votes. | ||
Hyung-bharvest marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
|
|
||
alexanderbez marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ### Considerations | ||
|
|
||
| - consensus key mapping information management strategy | ||
| - store history of each key mapping changes in the kvstore. | ||
| - the state machine can search corresponding consensus key paired with given validator operator for any arbitrary height in a recent unbonding period. | ||
| - the state machine 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 spam. | ||
| - 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. | ||
|
There was a problem hiding this comment. the double sign evidence is now handled by the cc: @alexanderbez There was a problem hiding this comment. thanks for pointing that out! as you said, evidence module gets pubkey from slashing keeper to use for double signing detection. edited as below - evidence module |
||
|
|
||
|
|
||
| ### Special note on implementation | ||
|
|
||
Hyung-bharvest marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - tendermint already has ability to change a consensus key by ABCI communication(`ValidatorUpdate`). | ||
| - validator consensus key update can be done via creating new + delete old by change the power to zero. | ||
| - therefore, we expect we even do not need to change tendermint codebase at all to implement this feature. | ||
|
|
||
| ## Status | ||
|
|
||
| Proposed | ||
|
|
||
| ## Consequences | ||
|
|
||
| ### Positive | ||
|
|
||
| - Validators can immediately or periodically rotate their consensus key to have better security policy | ||
|
|
||
Hyung-bharvest marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ### Negative | ||
|
There was a problem hiding this comment. Missing an important negative of it allows a validator to effectively sell their entity, in a way that before would require hardware assumptions. (They can change their key to give it to new management, without any oversight from their delegators) |
||
|
|
||
| - Slash module needs more computation because it needs to lookup corresponding consensus key of validators for each height | ||
|
|
||
Hyung-bharvest marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ### Neutral | ||
|
|
||
| ## References | ||
|
|
||
| - on tendermint repo : https://github.com/tendermint/tendermint/issues/1136 | ||
| - on cosmos-sdk repo : https://github.com/cosmos/cosmos-sdk/issues/5231 | ||
| - about multiple consensus keys : https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698 | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this has been asked a few times already, but I'd be nice if you could add the reasoning of why does this feature fit into the SDK instead of Tendermint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for noting that. I add below sentences to clarify the reason.
We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another.