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.