Multiple Validator Consensus Key

Archived Tendermint
1

tendermint repo issue : https://github.com/tendermint/tendermint/issues/4076

I wrote this post to fuel up the discussion in the community about this feature.
Please share ideas and opinions!

Context

This issue deals with more general and easier inclusive approach to active-active validator setup across the globe without relying on trustness on KMS softwares about preventing double-signing. Related discussion here(https://github.com/tendermint/tendermint/issues/1758)

Since this feature brings very significant structural changes on Tendermint codebase, it should be well discussed and reviewed, and it should be a long term goal.

Multiple Validator Consensus Keys

  1. a validator operator mapped with a consensus identity pubkey which does not have private key.(doesn’t matter if it has one) this consensus identity key is only for identifying validator and not for vote signing.

  2. validator register(and also can edit) multiple ordered consensus “voting” keys which belongs to the consensus identity key. these voting keys can sign votes on behalf of the consensus identity key(thus validator operator). registering and editing the list of voting keys can be done via transaction signed by the wallet key of the validator.

  3. only the first voting key can propose blocks, but all voting keys can participate on voting other’s blocks. when multiple votes for one validator exist, the most top ordered voting key gets the voting right and the other votes are ignored

Positive Effect

  1. validator active-active co-location across the globe is easily adaptable without double-signing risk when the validator uses different voting keys for each server. when validator are afraid of voting coming up from any hacker, he/she can just remove the existing keys and make new one and register.

  2. this feature as a solution of active-active co-location validator setup does not have the third party developed KMS failure point which might result in double-signing accident. So, this solution does not rely on any trustness for exterior program(open or closed) to prevent double-signing risk.

  3. well-spread practice of active-active multiple validator setup across the globe environment might open the possibility of shorter blocktime when we design the consensus algorithm changes effectively.(need further discussion)

Negative Effect

  1. more computation needed to decide which key is decided to commit

  2. slash module(in cosmos-sdk) needs historical key rotation information