Cryptographic equivocation slashing design

Conversation
1

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 received, delegations in the “undelegating” and “redelegating” states are only slashed if they went into this state after the infraction height. So as a delegator, if you undelegate, and the next day, the validator double signs, you will not be slashed.
  • Evidence expires after around 80 days and cannot be submitted any more.

Proposed consumer chain slashing:

  • When evidence is received, all delegations are slashed. This means that if you undelegate or redelegate, and then the next day the validator double signs, you will still be slashed.
  • However, the unbonding period is still in effect. Once you are fully unbonded and have your coins back in your wallet, of course you cannot be slashed.
  • 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. However, due to ICS’s key assignment, if the validator has reassigned their key at least 3 weeks ago, you will not be slashed for infractions committed with their old key.

The effect of these changes is to make slashing somewhat more strict. However, it does not seem to us that this will have much of an effect on the incentives. This post is to gather opinions from the community on this slashing scheme, and if it is satisfactory, it can be deployed soon.

3 Likes
2
  • 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 ?

1 Like
3

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

2 Likes
4

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.

5

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 ?

6

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.

2 Likes
7

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 also possible right now, if Pion was a standalone chain that had run a testnet with the same chainID as production, but due to expiration of evidence in the single-chain case, the risk will only exist for a short time (around 80 days by default).

How this can be mitigated

Simple validator best practices

First of all the slashing scenario above was due to several bad practices from the validator. It could have been prevented if they had used a different key for the testnet, or if they had used a different key for the consumer chain. Basically, if you run a validator, do not use the same key for chains with the same chainID, and do not use a key so many times you forget what chainIDs you have used it on! If you use a new key for every new consumer chain you validate on, this can never happen to you (even if you use the same keys for all testnets for convenience or something).

Simple testnet best practices

Another simple mitigation is to always give testnets a chainID with the word test in it. For example pion-test-1. This may not really be necessary if validators follow the simple best practices around key management above, but it could provide an extra measure of safety.

Check consumer chain spawnTime against evidence time

Another mitigation that we may be able to get into v13 is that the Hub will not slash for evidence with a timestamp before the consumer chain in question even existed. This is very easy to check and will prevent the scenario above. It will not prevent a similar scenario where the testnet is run after the consumer chain is started, but it will allow validators to apply the simple rule “never validate on a testnet with the same chainID as a consumer chain”.

1 Like
8

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.

9

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

10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.