cosmos
SlashPackets may lead to delegators getting incorrectly slashed
Problem
As compare to the normal behavior of SDK chains, ICS introduces an extra delay between the time an infraction is committed and the time the misbehaving validator is slashed (i.e., due to relaying). If during this period a delegator delegates to the misbehaving validator, it will get slashed although it's stake did not contribute to power the validator had when it committed the infraction.
Closing criteria
Asses whether this is indeed an issue. In case it is, figure out a way to fix it.
Problem details
Currently, the SDK accepts two types of evidence: downtime and double-signing. For both an infraction height is created that is used by the staking module to avoid slashing undelegations or redelegations that occur before the infraction was committed (i.e., it affects what unbonding stake can be slashed). Note that the infraction height doesn't have any impact on the bonded stake that is slashed. This means that if a delegator manages to delegate to a validator after it committed the infraction but before it got slashed, then that delegator will get slashed as well. The purpose of this issue is to analyze
- If this is a current issue in the SDK.
- If ICS makes this issue worse.
Note that, in the case of ICS, every infraction height on every consumer chain is mapped correctly to a height on the provider (see the mapping from consumer chain block heights to provider chain block heights in the spec).
Downtime
Downtime evidence is generated in slashing.BeginBlock based on the LastCommitInfo received from TM. If at height h a validator V has not voted in enough blocks, then V is slashed at height h for an infraction at height h-2, i.e., https://github.com/cosmos/cosmos-sdk/blob/47f46643affd7ec7978329c42bac47275ac7e1cc/x/slashing/keeper/infractions.go#L85.
This means that a delegator D can delegate to V at height h-1 and as a result get slashed at height h for the downtime infraction at height h-2. ICS makes this worse due to the relaying delay.
Double-singing
Double-signing evidence is passed to the SDK by TM and handled in evidence.BeginBlock. If at height h, some evidence is received for a validator V for an infraction committed at height hi, then V is slashed at height h for an infraction at height hi-1, i.e., https://github.com/cosmos/cosmos-sdk/blob/47f46643affd7ec7978329c42bac47275ac7e1cc/x/evidence/keeper/infraction.go#L101.
This means that a delegator D can delegate to V at any height in the interval [hi, h-1] and as a result get slashed at height h for the double-singing infraction at height hi-1. ICS makes this worse due to the relaying delay.
TODOs
- [x] Labels have been added for issue
- [x] Issue has been added to the ICS project
This means that a delegator D can delegate to V at any height in the interval
[hi, h-1]and as a result get slashed at height h for the double-singing infraction at height hi-1. ICS makes this worse due to the relaying delay.
@sergio-mena Is there any guarantee provided by TM re. the size of the [hi, h-1] interval? In other words, how fast does TM detect double-signing infractions?
A priori there is no strong guarantee on when an infraction (evidence of misbehavior) will be committed to a block. They are pooled like txs, gossiped like txs, but they take priority over tx in the block.
In practical terms, the evidence will be committed as soon as an honest proposer has received it via gossip. However, there is no upper bound on the timeliness of an evidence being committed to a block. Tendermint even has logic to disregard evidences if they are beyond the trusting period: take a look this section.
