Consensus Key Rotation

Archived Tendermint
1

1. Objectives

  • to provide validators ability to rotate their validator consensus key
  • to synergy with subkey features for the best validator key management

2. Use-case Overview

  • keys
    • mainkey : normal full-authority key generated when creation of an address
    • consensus key(priv_validator_key) : the only key mapped with the mainkey which is used for consensus voting
  • how to rotate consensus key mapping to mainkey?
    • create new random consensus key
    • create and broadcast a transaction that the new consensus key is coupled with the mainkey with signature from mainkey
    • old consensus key becomes useless 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 key for any arbitrary height
  • slash module
    • slash module can search corresponding consensus key for any height so that it can decide any consensus vote signature is valid or not
4 Likes
2

Iā€™m strongly in favor of a possibility to rotate consensus keys. Thanks for opening a topic, @bharvest! How much effort do you think this would take to implement? I could imagine it has quite some influence on the slashing module, right?

1 Like
3

Our team does not imagine very huge difficulty on the modification of slash module, but @zaki insisted that it will be quite a headache.

So although we think it is quite doable, it needs deeper research. But we are sure that B-Harvest can implement this.

So I hope @zaki comes into discussion to discuss about slash module impact.

4

This is something I have looked into before. In an ideal world we would be able to rotate both the consensus keys AND the account keys - the latter is hard because the valoper key (thus, the account key) is used as a key in many places; the former I suspect requires changes to both tendermint and the SDK.

The ā€˜oldā€™ key however does not need to be kept around indefinitely - only for max_evidence_age if I am correct?

I would say this is a very strong idea for funding from the community pool.

Perhaps an extension of this is that when a validator is tombstoned, they are able to return to signing from the same valoper key (as this is where delegations are registered) by rotating out the tombstoned consensus key (thus not necessarily lose all delegators - nothing stops them from moving away of course)

2 Likes
5

  1. account key is equal validator operator key. The validator operator key is the permanent identity of a validator so it cannot be rotated.

  2. But I think mapping of account key and validator operator key can be rotated(original account key can submit a tx to map a new account key for controlling the validator operator key) I think this can be another security extension. In short, the account key is just a tool to control the validator operator, hence rotation makes sense.

  3. tombstone intention is to prohibit validator to doublesign several times in short period. Therefore I am not sure it is a good thing that rotation allow revive of tombstoned validator.

  4. if only consensus key changes are recorded in blockchain, it is not a big data to hold. Also as @joe-bowman said, only latest 3 weeks of mapping changes can be keeped.

6

Whilst this is true now; I believe it is something we have to tackle at some point. It would mean changing all delegations - and other references to the valoper key - at the point of change (so it is computationally heavy - it needs to be an expensive operation), but I donā€™t think it is infeasible, just a larger challenge than consensus key change :slight_smile:

I somewhat agree, but there must be a way to handle repeat double-sign prevention without tombstoning a validatorsā€™ identity (+ brand + reputation, etc.) indefinitely. Perhaps with the ability to rotate account keys does away with this requirement entirely - but this is likely a later discussion :slight_smile:

1 Like
7

How about

  1. validator operator key only has public key and has no private key to handle the validator

  2. instead, validator owner can map any account key to the validator operator and be able to rotate this handle key.

There is no private key for validator operator so there is no need to rotate the validator operator key, but only rotating handle key is needed.

Also we need to clarify what tombstone can affect the validator and delegator. Does it have to allow validator key rotation to restart validating without changing its identity?? If so, why tombstone exists??

The intention of tombstone is not very clear so it is difficult to clearly define validator key rotation spec.

I really cannot understand the idea of key=account in blockchain space begun by satoshi. If you have a bank account, the acc number(public key of address) is completely independent with the otp key. Users map any arbitrary otp key with his/her account. Otp is Not an account and account is Not a key. Most blockchain key/account structure is really counter-intuitive and wrongly-designed as a financial service.

ā€œIf you lost your private key, it is your fault. Be responsible.ā€ - this is very irresponsible design of a system. It is a flaw and we should try our best to allow users become ā€œirresponsibleā€(at least much less responsible) about his/her private key management. It is the responsible system for users.

8

The intention of Tombstone is to prevent a validator who is compromised or malfunctioning from being slashed to repeatedly.

Weā€™ve seen on Tezos incidents where operators were on vacation etc and large amount of value being destroyed.

1 Like
9

We should optimize for designs that enable the validator operator key to held in cold storage.

The challenge is that at the moment validators need to have access to their validator operator key to participate in governance.

We need to preserve the relationship in the staking keeper after the key rotation.

We could have some kind of clean up function that runs in 21 days to remove the value from the store.

1 Like
10

Thanks for the points. Both points are definitely necessary condition for this feature.

And we decided to simplify the topic to only rotation of consensus key(not including rotation of validator operator key) because rotation of valoper<>walletkey mapping can be achievable by subkey feature.