Slashing spec changes: capped slashing-per-period

[cwgoes]

As discussed in the slashing design meeting, introduce the concept of a "slashing period":

Slashing period:

A slashing period is a start and end time associated with a particular validator, within which only the "worst infraction counts": the total amount of slashing for infractions committed within the period (and discovered whenever) is capped at the penalty for the worst offense.

This period starts when a validator is first bonded and ends when a validator is slashed & revoked for double-signing (but does not end if they are slashed & revoked for just missing blocks). When the validator voluntarily unrevokes themselves (and possibly changes signing keys), they reset the period.

Implementation sketch:

1. Create a SlashingPeriod structure:

type SlashingPeriod struct {
  ValidatorAddr sdk.AccAddress
  StartTime uint64
  EndTime uint64
  FractionSlashedSoFar sdk.Rat
}

1. When a validator is first bonded, create a new SlashingPeriod structure for the validator, with the StartTime of the current block, a sentinel EndTime of 0, and FractionSlashedSoFar of 0.

2. When stakeKeeper.Slash() is called, lookup the appropriate SlashingPeriod based on the time-of-infraction, cap the fraction slashed at MaxFractionSlashedPerPeriod - FractionSlashedSoFar, possibly 0 (where MaxFractionSlashedPerPeriod is a configuration parameter), and update the SlashingPeriod struct with the increased FractionSlashedSoFar.

   1. Additionally, if the validator is unbonded as part of this slash, set EndTime of the current SlashingPeriod to the current block time.

3. When a validator is unrevoked, look up its newest SlashingPeriod. If that SlashingPeriod has already ended (EndTime is nonzero), create a new SlashingPeriod as in (1).

4. Somehow cleanup old SlashingPeriod structures once no evidence could possibly be valid (depends on a resolution Slashing: special kind of slashing-by-transaction for infractions older than an unbonding period #1378 among others)

Concerns:

1. Safety
   1. No disincentive for committing more protocol faults (at past heights) after you've already committed the worst offense (and it has been discovered). I guess it's unclear how much this matters in practice - if we slash a lot for just one double-sign, that may be enough of a disincentive - hard to predict.
2. Implementation
   1. Slashing is capped fractionally per period, but the amount of total bonded stake associated with the validator can change (by an unbounded amount) over that period. For example, with MaxFractionSlashedPerPeriod = 0.5, if a validator is initially slashed at 0.4 near the start of a period when they have 100 steak bonded, then later slashed at 0.4 when they have 1000 steak bonded, the total amount slashed is just 40 + 100 = 140 (since the latter slash is capped at 0.1) - whereas if they had 1000 steak bonded initially, the total amount slashed would have been 500. One possible way to avoid this problem is to track a MaxStakeBonded in the SlashingPeriod (which must be updated every time the validator's power changes), and instead cap the total slashing amount (in tokens) within a period by MaxStakeBonded * MaxFractionSlashedPerPeriod.
   2. May create unusual incentives for delegators - if you see that a validator can only be slashed by X amount more, it's now less risky to delegate to. This is not an issue if all the slashing events which change the SlashingPeriod also revoke the validator.
   3. Some (minor) state bloat from old SlashingPeriods

[cwgoes]

• We don't need MaxFractionSlashedPerPeriod, the max is just the slashing fraction of the worst infraction.
• Add ASCII diagrams of slashing period / unbonding period / infraction height + discovery along with resulting consequences.
• Figure out how Tendermint's evidence filtering (MaxEvidenceAge) needs to integrate. (and double check that Tendermint is considering spam prevention in an (ideally future proof) MVP fashion)
• Make sure changing keys before unrevoking is possible (and encouraged!) - but doesn't need to be explicitly incentivized.

Ref slashing-beyond-unbonding period: #1378.

[alexanderbez]

Thanks @cwgoes, this is very insightful.

Few thoughts:

• Should the safety concern(s) you pointed out be addressed in more detail? Im curious to see how this will play out? I imagine the penalty for a double sign would have to be very high if a validator misses a large number of blocks (but still under the threshold).
• To point (2)
  • Is the validator actually slashed once he has been revoked/unboded and the EndTime has been set?

  • Additionally, if the validator is unbonded as part of this slash, set EndTime of the current SlashingPeriod to the current block time.

    • Does this mean unbonded or revoked? If the validator commits a double signs infraction, he is revoked correct? What if he simply missed a few blocks and then wants to unbond?
• Possibly change the nomenclature of FractionSlashedSoFar. Maybe CurrentFractionSlashed?

[cwgoes]

Per slashing design meeting concurred that:

1. Slashing-for-downtime will not utilize the slashing period
2. All infractions which do use the slashing period must also jail the validator, this prevents 2.i above

These constraints will be included in the spec.

[alexanderbez]

Which infractions utilize a slashing period? How does this constitute to what ends a slashing period? Is it still only double signs?

[cwgoes]

Which infractions utilize a slashing period?

Only double-signs.

How does this constitute to what ends a slashing period?

All infractions which utilize the slashing period must also jail the validator.

Is it still only double signs?

Yes, for now (prelaunch).

[alexanderbez]

Thanks!