We recently made a change to replicated security: if a validator commits an equivocation fault (colloquially known as “double signing”) on a consumer chain, they are no longer automatically slashed on the Cosmos Hub.
Instead, evidence of equivocation must now be submitted to Cosmos Hub governance and be voted on. This is an extra safeguard before a validator is slashed. The reason for this move is to prevent a situation where a consumer chain contains exploit code which unfairly slashes a large number of validators.
While we had already built in several mitigations for this attack, as well as requiring that all consumer chains be well-audited, we ultimately decided that no matter how small the risk of unfair slashing might be, it is such a serious attack that we need to be able to rule it out completely.
Note that replicated security changes nothing about how equivocation is handled on the Cosmos Hub. It only affects how equivocation evidence coming from consumer chains is handled. This article deals only with what happens when validators double sign on consumer chains.
We’d like to take this opportunity to explain how governance-gated slashing compares to automatic slashing and why it provides the same security guarantees.
Equivocation is when a validator signs off on two alternate, but completely valid versions of history. The attack that is possible with equivocation is one where two different, but completely valid histories are presented to two victims.
For example, the attacker might show Alice a block where they sent her 5 Atoms, while also showing Bob an alternate history where he was sent those same 5 Atoms. This is known as a “double spend” and is a classic and well-studied blockchain attack scenario.
There are other more complicated attacks but they can be analyzed under the same lens and we won’t describe them here.
The important thing to understand about equivocation is that in Tendermint/CometBFT an attack can only be carried out successfully if at least ⅓ of the validation power on the chain participates. A single dishonest validator cannot carry out the attack by themselves.
In the context of governance-gated slashing, you might be wondering- what if validators with ⅓ of the power carry out an attack by equivocation and then the governance proposal to slash them does not pass? Wouldn’t they get off without punishment? Wouldn’t this possibility incentivize such an attack?
The easiest way to prevent a governance proposal from passing on Cosmos chains is a vote of No With Veto. If ⅓ or more of the validation power votes NWV, the proposal cannot pass. So, yes, that malicious ⅓ who carried out the attack could just veto the slashing proposal and get away without being punished.
However, this is the case with automatic slashing as well! ⅓ of validation power can censor any transaction and completely prevent it from appearing on the chain. The malicious ⅓ could simply censor evidence of their equivocation and not be slashed. Validation power and governance power are the same power.
So, if enough validation power participates in an equivocation attack for the attack to succeed, it follows that they will also be able to prevent punishment, whether governance-gated or automatic slashing is used.
Conversely, if an attack is attempted but does not have enough power to succeed, the attackers will also not have enough power to censor automatic slashing transactions or defeat a slashing proposal. They will then be slashed in either case. Automatic slashing and governance-gated slashing are equivalent under this analysis.
It is important to note that a simple governance proposal cannot slash any validator any time. The equivocation governance proposal we are introducing can only be created for a validator if the Cosmos Hub has received an equivocation slashing packet for that validator from a consumer chain first. So in order for an innocent validator to be slashed, first a consumer chain would need to contain malicious code that would forge an equivocation slashing packet. Then someone would need to introduce an equivocation slashing proposal. Then governance would need to vote yes on the proposal.
We have shown above, that given engaged and active voters, equivocating validators have an equal chance to avoid being slashed for an offense under governance-gated slashing and automatic slashing.
But a “No” or “No with veto” vote is not the only way for a governance proposal to fail. Governance proposals can also fail if they do not reach a defined quorum percentage of token holders voting (40% on the Hub). If a slashing proposal containing evidence of an attack was submitted, and nobody cared enough to verify it and vote, the attackers would not be slashed.
We do not see this as being a risk for a long time. An attack involving equivocation would be an unprecedented event. It has never happened on the Cosmos Hub, and to my knowledge has never happened on any Cosmos chain. Validators have been slashed for double signing, but it has always been as a result of misconfiguration.
An attempted equivocation attack on a replicated security consumer chain would be a very notable event, and threaten the integrity and reputation of the Cosmos Hub itself. There is no chance in the short term that slashing proposals would be ignored.
However, in the long term, when we scale to thousands of consumer chains voter apathy might become more of a risk. This is why we are working on bringing back automatic slashing by allowing the Cosmos Hub to completely verify equivocation evidence on its own instead of trusting consumer chains to send correct evidence.
We don’t foresee any serious need for this until we have at least hundreds of consumer chains
We have shown above that there is no significant difference in the chances that equivocating validators can avoid punishment under governance-gated or automatic slashing, there is one important difference that we should mention. It has to do with the governance voting period.
Governance proposals must go through a 2 week voting period before they are passed. The unbonding period, after which delegators and validators can unbond their stake is 3 weeks. This means that if malicious validators participate in an equivocation attack and then immediately unbond their stake, and then the governance proposal is not put up for voting for at least a week, the validators could avoid the 5% slashing penalty. They would still be tombstoned, meaning that they could never validate again with the same keys.
We believe that this is acceptable in the short term. Governance proposals are not generated automatically upon receiving a slash packet from a consumer chain, but the packets are logged and then anyone can create the proposal from this information. Given what a serious matter a real equivocation attack would be, we have no doubt that someone would create the proposal.
One other concrete change resulting from this has to do with light clients. Due to some complicated factors related to the reduced time available to submit evidence due to the voting period, it is important that IBC connections to consumer chains are updated at least once every 5 days. The IBC trusting period parameter must also be set to 5 days. Relayers already update connections every time they relay a packet, and automatically update connections frequently even when not relaying packets, so this shouldn’t be an issue.
We should be able to remove this caveat in the next release, bringing things back to the normal state of affairs where relayers must update IBC connections at least once every 2 weeks.
Our team is working on some code for a future release that will make it so that the Cosmos Hub can verify double signing evidence from consumer chains cryptographically, allowing automatic slashing to work safely. This is one of our top priorities. This is an ongoing area of research, and we’ll be announcing some updates on it soon. One caveat is that it ties Replicated Security more tightly to Tendermint/Comet, since other consensus protocols will have other equivocation evidence formats which cannot be verified with the same code.
Follow Informal on Twitter for more info and monthly updates.