Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple Validator Consensus Keys #4076

dlguddus opened this issue Oct 24, 2019 · 3 comments


Copy link

@dlguddus dlguddus commented Oct 24, 2019


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(#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


This comment has been minimized.

Copy link
Contributor Author

@dlguddus dlguddus commented Nov 5, 2019

I self raise a question on this multiple consensus key system design about liveness and security conflict.

If there co-exist 2 proposed block(B1,B2) for same height/round.(correct me if I am wrong on this assumption) A non-proposing validator has consensus key K1,K2. K1 voted for B1 and K2 voted for B2.

This is possible because the proposed system controls each key in an async fashion, so K1 does not aware that K2 signed B2 before K1 votes on B1. If the system works in sync fashion, it will lose the highly co-location advantage.

Then, this is a fork causing activity so it should be slashed as a double signing. But the votes cannot be classified whether intentional or unintentional.

This is causing a BFT break down case. So, do we have a work around or this is impossible to achieve in any BFT system? I guess there might exist mathematical proof on this proposition.


This comment has been minimized.

Copy link

@melekes melekes commented Nov 7, 2019

This is different from cosmos/cosmos-sdk#5233, right? You want multiple keys


This comment has been minimized.

Copy link
Contributor Author

@dlguddus dlguddus commented Nov 11, 2019

@melekes yes. it is different and this needs longer discussion. I hope to have multiple "concurrent" consensus keys for one validator, but it seems like it conflicts against BFT.

@ebuchman ebuchman added the consensus label Nov 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.