Implementation and spec divergence

[danwt]

The spec at cosmos/ibc@f20ba86
allows different behavior than the implementation.

Consider onRecvVSCMaturedPacket

https://github.com/cosmos/ibc/blob/0a43605fe869e1cf004103dd0f6994e9d8b81055/spec/app/ics-028-cross-chain-validation/methods.md?plain=1#L134-L146

Consider the following

Execution 1 (Spec)

• Provider handles VSCMatured packet
• The unbonding validator becomes unbonded
• Provider handles Slash packet
• The slash is ignored due to

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

  Lines 223 to 229 in 3416e4c

  	// make sure the validator is not yet unbonded;
  	// stakingKeeper.Slash() panics otherwise
  	if !found || validator.IsUnbonded() {
  	// TODO add warning log message
  	// fmt.Sprintf("consumer chain %s trying to slash unbonded validator %s", chainID, consAddr.String())
  	return false, nil
  	}

• The validator receives more delegations
• Provider EndBlock occurs, and validator becomes bonded

At this point EndBlock commits a state where the validator is bonded.

Execution 2 (SUT)

However, a different result is possible in the current SUT, given the same transactions:

• Provider handles VSCMatured packet
• The maturity is saved for processing in EndBlock
• Provider handles Slash packet
• Validator is jailed
• Provider EndBlock occurs, and validator is not bonded

At this point EndBlock commits a state where the validator is not bonded.

This is a different result.

[mpoke]

Re. Execution 1

• Provider handles VSCMatured packet
• The unbonding validator becomes unbonded

This is not true. At this point, the state of the validator changes (see here) so it can potentially become UNBONDED in staking.EndBlock (see here).

In the spec, the stakingKeeper.UnbondingCanComplete(op.id) is called on receiving a VSCMaturedPacket (see https://github.com/cosmos/ibc/blob/0a43605fe869e1cf004103dd0f6994e9d8b81055/spec/app/ics-028-cross-chain-validation/methods.md#ccv-pcf-rcvmat1).

[danwt]

AH yeah I made a mistake 👍