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

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.…

Excerpt (1195 of 3021 characters). Read the whole post on the forum ↗

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…

Excerpt (1197 of 1395 characters). Read the whole post on the forum ↗