Divergence spec and impl: slashing after tombstoning.

[danwt]

The spec has not mention of tombstoning (see here) but the code does use tombstoning

interchain-security/x/ccv/provider/keeper/relay.go

Lines 217 to 240 in 4e40e09

	if k.slashingKeeper.IsTombstoned(ctx, consAddr) {
	return false, nil
	}
	// slash and jail validator according to their infraction type
	// and using the provider chain parameters
	var (
	jailTime time.Time
	slashFraction sdk.Dec
	)
	switch data.Infraction {
	case stakingtypes.Downtime:
	// set the downtime slash fraction and duration
	// then append the validator address to the slash ack for its chain id
	slashFraction = k.slashingKeeper.SlashFractionDowntime(ctx)
	jailTime = ctx.BlockTime().Add(k.slashingKeeper.DowntimeJailDuration(ctx))
	k.AppendSlashAck(ctx, chainID, consAddr.String())
	case stakingtypes.DoubleSign:
	// set double-signing slash fraction and infinite jail duration
	// then tombstone the validator
	slashFraction = k.slashingKeeper.SlashFractionDoubleSign(ctx)
	jailTime = evidencetypes.DoubleSignJailEndTime
	k.slashingKeeper.Tombstone(ctx, consAddr)

There is a mismatch between the code and the spec.

What is the intended behavior?

@mpoke we said today that after a double sign is received the validator shall be tombstoned. But what if downtime slashing packets are subsequently received? Should they be ignored, as they are in the code?

interchain-security/x/ccv/provider/keeper/relay.go

Lines 217 to 219 in 4e40e09

	if k.slashingKeeper.IsTombstoned(ctx, consAddr) {
	return false, nil
	}

or not?

[mpoke]

what if downtime slashing packets are subsequently received? Should they be ignored, as they are in the code?

Yes, that's the expected behavior.

[danwt]

See

• ICS28: Reflect that downtime slashing is not allowed after doublesign slashing in spec ibc#796

[danwt]

Reopened :)

[mpoke]

what if downtime slashing packets are subsequently received? Should they be ignored, as they are in the code?

Yes, that's the expected behavior.

I'm not sure actually that we want this. Should a validator that is already slashed and jailed for double-signing be also slashed for downtime on another consumer chain? This would be important as a deterrent for tombstoned validators to not stop validating on the consumer chains (especially during channel initialization). @okwme What do you think?

[danwt]

See also

• Decide slashing behavior for downtime and double signing #234

[danwt]

For the record to proceed with testing I will take the code as correct, until we have an update from product side.

[okwme]

once a validator is tombstoned on the hub it is just a matter of time until the validator is removed from all consumer chains right?
if the validator stops validating on all consumer chains before the packet is received that removes them from the validator set i don't think it makes sense for trying to slash them for this.
if anything it's "more" correct.
they should not be validating after being tombstoned, it's just a matter of time for that to be propogated.
it seems that it would also complicate the code to have them further slashed.
i think it is unnecessary to slash them further for missed blocks after being tombstoned.

[jtremback]

How it currently works in the implementation:

Downtime:

• Once you get slashed for downtime, you will be jailed and slash.
• If you get downtime on other chains you can get slashed for downtime there too
• The more consumer chains there are, the more validators are going to get slashed (if they have correlated downtime)

Double Sign:

• You can only get slashed once, regardless of how many times you double sign

[danwt]

Can we close this?

[mpoke]

The spec and the code are still inconsistent. The question is, do we need to mention tombstoning in the spec?

[danwt]

Hmmm good question. I think we should. If not, we should explicitly mention in the spec that there are divergent details w.r.t slashing module.

[mpoke]

I opened an issue on cosmos/ibc (cosmos/ibc#820). Thus, we can close this.