Cryptographic equivocation slashing design

We’ve been working hard to figure out how to automatically slash for equivocation by verifying evidence on the provider chain. Once we finish and deploy this code, it will eliminate the need for equivocation proposals (eg prop 818). Currently, we have code which is able to verify the two major types of evidence: light client attacks and consensus double signing. This means that the provider chain can verify that a validator has committed either one of these infractions. However, we have not found a way to verify the time and block height at which the infraction occurred without trusting the consumer chain. Without being able to verify the infraction height, slashing for infractions on a consumer chain will be a slightly different than slashing in the single chain case. Let’s compare them and look at the differences: Current single chain slashing: • When evidence is received, every delegation in the “bonded” state is slashed, regardless of whether it was created before or after the infraction height. This means that if you delegate to a validator who had committed an infraction before you delegated but has not yet been slashed, you will be slashed. • When evidence is…

Excerpt (1194 of 2553 characters). Read the whole post on the forum ↗

• When evidence is received, all delegations are slashed. This means that if you undelegate, and then the next day the validator double signs, you will still be slashed.

Just to add more details because you mentioned redelegation in the “single chain slashing” section, here unlike undelegation, if you redelegate before the infraction, you won’t be slashed right ?

Undelegation and redelegation are handled the same in every case. Have edited the post above to clarify.

I think we are punishing many non involved party. IMO in case of any event people delegating at that movement should only be slashed.
Also we should come up with other slashing mechanism. If we keep slashing the security providing chain for the mistakes on ICS chain ( New tech) it will harm the development. And it will be hard to have more hubs within the cosmos ecosystem.

Evidence does not expire. So if you delegate to a validator who double signed years ago but was never slashed for some reason, you could be slashed when the evidence finally comes in.

So you can be slashed for an evidence older than the unbonding period ?

Currently, we have code which is able to verify the two major types of evidence: light client attacks and consensus double signing.

What about the downtime slashing ?

So you can be slashed for an evidence older than the unbonding period ?

In principle, yes, although this would only happen if the validator in question had double signed but for some reason was never slashed during the unbonding period, which seems very unlikely since evidence will be automatically submitted to the Hub by any connected relayers.

Also, if this did somehow happen, the validator could immediately reassign their consumer key. This would result in the old key being pruned after an unbonding period, and the evidence no longer being valid.

On the whole, this scenario seems like a very unlikely edge case, since slashing will usually happen right away.

What about the downtime slashing ?

Verifying downtime cryptographically is an unsolved problem in all of crypto. How it currently works in RS is that the consumer chain sends a message about downtime to the provider. This is trusted, but we also throttle and queue these types of messages so that a consumer chain cannot jail many validators at once.

There might be other solutions, but those are an entirely different subject than equivocation slashing, and in general the stakes for downtime are much lower.

There’s another effect from the lack of evidence expiration discussed above. It could make some types of accidental double signings related to testnets more likely. It’s also somewhat of an edge case, and we don’t think that it’s a big problem, but I want to write it down here. The scenario In this hypothetical scenario, a testnet is run with Hub validators with the chainID `pion-1` (we’ve really had this testnet). Years later, with great fanfare, the Pion blockchain (doesn’t actually exist, to my knowledge) joins the Cosmos Hub as a consumer chain. What’s Pion’s chainID? You guessed it, `pion-1`. Alice validated on the `pion-1` testnet using her production Cosmos Hub key (bad practice, but someone might do it), then later she validated on the `pion-1` consumer chain using her Cosmos Hub key, without doing a key assignment transaction (also a bad practice). Now she could be slashed, since someone could dig up two blocks at the same height with the same chainID. Alice signed two blocks with the same key, at the same height with the same chainID. This is the canonical definition of double-signing. Can this happen in the single chain case, right now? Note that this is…

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

On reflection, we have decided to leave this feature out of Gaia v13, and put it into v14. It is perfectly safe if validators assign a new key each time they start validating on a new consumer chain, but we want to make sure that we have enough time to make sure that all validators have done this before the feature comes out.

is this going to work retroactively? like someone making mistake before this getting passed and getting the axe for it.