Securing the Cosmos Hub from Compromised Validator Keys and Insecure VaaS Providers

Hub Proposals Signaling/Text
1

Purpose: To safeguard the security of the Cosmos Hub network, promote independent validation, and discourage insecure practices of VaaS providers.

Motion: We propose the following measures to be approved by the community:

Validators with a compromised operator key or consensus key (due to key generation by a VaaS provider, key sharing with a VaaS provider, or any other reason) are not welcome on the Cosmos Hub network.

VaaS providers must demonstrate and publish strong evidence of secure key practices that do not leave their customers with compromised keys at any point. Failure to do so may result in the VaaS provider being barred from operating on the Cosmos Hub network as a VaaS provider and validator.

We encourage validators with compromised keys to withdraw from the active set and request their VaaS providers to cease providing VaaS in an insecure manner.

Rationale: Ensuring the security of the Cosmos Hub is of utmost importance, as it serves as the backbone of the Cosmos ecosystem, providing crucial liveness and censorship resistance properties achieved through independent validation by numerous actors located in diverse geographical locations and jurisdictions. Therefore, the Cosmos Hub is responsible for setting the standard for secure chain operation, given its central role in the ecosystem. Including white-label validators or those with compromised keys in the active set can obscure these important properties and potentially harm the network’s security. With the launch of Interchain Security on the horizon, it is crucial to eliminate insecure practices and compromised validators to ensure the utmost security of the Cosmos Hub and the Consumer chains it supports. This will strengthen the Cosmos Hub and the entire Cosmos ecosystem, making it more secure and reliable for all users.

Discarding such practices and promoting independent validation is necessary to safeguard the network’s security. Additionally, it is essential to establish strict criteria for VaaS providers to ensure secure key management practices to prevent any compromise to the keys of validators using their services.

The Cosmos Hub community must take decisive action to ensure the security of the Cosmos Hub by enforcing strict measures against validators with compromised keys and VaaS providers who do not follow secure key management practices. By promoting independent validation, we can uphold the liveness and censorship-resistance properties of the Cosmos Hub network.

Governance Vote:

The following items summarize the voting options and what it means for this proposal:

By voting YES, you indicate support for this proposal.

By voting NO, you do not support this proposal.

By voting ABSTAIN, you formally decline to vote for or against the proposal but want to contribute to the quorum.

By voting NOWITHVETO, you consider this proposal malicious or harmful and would like to see depositors penalized by revocation of the deposit, contributing to an automatic â…“ veto threshold.

3 Likes
2

Agree with the premise - validators with compromised keys shouldn’t continue operating as-is.

But not sure about the suggested implementation. Points of concern to me are the following, though I don’t have the expertise in either area to explore this more:

  • Legal Concerns - related to what will effectively be a “gated” network. SEC concerns?
    Additionally, and maybe related, right now, anyone can launch a validator, and in the case of a bad actor, could be argued that only their stakers are enabling them. But if we set precedence or sort of mechanism as described here, it could be argued that all Atom holders are enabling the bad actor?

  • Gov Attack Concerns - looking at some recent props (assuming quorum is reached with No’s and Abstains), you could pass a prop with just ~15% voting yes. That equates to just about 3 validators on the current set.
    If we had some sort of “vote->auto kickout” module to implement the described solution, theoretically, just 3 validators could collude and systematically remove all other validators, right? (3 being a smaller number than the ~10ish that’s needed now to pose a systemic risk)

Again, not an expert on either topic, so might be talking non-sense. But these are the questions that I have with implementing something like this.

That being said, something needs to be done about validators with potentially compromised keys