Ensure unbonding ops cannot complete during initialization

[mpoke]

During the initialization period, the consumer chain has the same initial validator set V1. To keep the security model of Tendermint, none of the validators in V1 should be able to unbond any amount of their stake during this period. In other words, no unbonding delegation would complete during the CCV initialization protocol.

This feature would enable CCV to guarantee the following invariant that would preserve the security model of Tendermint on the consumer chains:

• Let t be an instance of time and power(T) be the function that calculates the voting power granted to some validators given an amount T of tokens bonded by these validators on the provider chain. Then, the voting power granted to validators on any consumer chain at time t MUST NOT exceed power(T_t), where T_t is the amount of tokens bonded by these validators on the provider chain at time t.

This feature can be easily added to the current implementation.

• First, in UnbondingDelegationEntryCreated we need to iterate over all consumer chains, not just the ones with established channels, i.e.,

  interchain-security/x/ccv/parent/keeper/keeper.go

  Line 409 in ddc91d3

  h.k.IterateBabyChains(ctx, func(ctx sdk.Context, chainID string) (stop bool) {

  This will block the completion of any unbonding delegation until ACKs are received from all consumer chains.
• Second, once the CCV channel is set to VALIDATING, the consumer chain still has the initial validator set V1. In the meantime, the provider chain may have gone through multiple updates, e.g., V1 → V2 → ... → V10. Thus, the first packet sent to the consumer chain should contain all the validator set changes e.g., from V1 to V10. As in the previous step, we need to iterate over all consumer chains, i.e.,

  interchain-security/x/ccv/parent/module.go

  Line 158 in ddc91d3

  am.keeper.IterateBabyChains(ctx, func(ctx sdk.Context, chainID string) (stop bool) {

  and if there is no established channel, then accumulate all validator updates; otherwise, send a ValidatorSetChange packet with all accumulated validator updates.
  Note that this step needs to be done regardless of the completion of unbonding operations.
• Third, we need to enable the completion of unbonding (delegation) operations. At the moment, the UBDEs are mapped to ValidatorSetUpdateIds , i.e.,

  interchain-security/x/ccv/parent/keeper/keeper.go

  Line 414 in ddc91d3

  ubde := ccv.UnbondingDelegationEntry{

  For each packet sent, ValidatorSetUpdateId is incremented and it's added to the packet. When receiving a packet ACK, the associated ValidatorSetUpdateId is used to get the associated UBDEs that have matured, i.e.,

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

  Line 73 in ddc91d3

  UBDEs, _ := k.GetUBDEsFromIndex(ctx, chainID, data.ValsetUpdateId)

  For this functionality to be preserved when sending multiple validator set changes in a single packet, we need to find another way to map UBDEs to ValidatorSetUpdateIds, i.e., a packet will be associated with multiple ValidatorSetUpdateIds.

[mpoke]

A fix for this issue is specified in cosmos/ibc#646

[danwt]

Nice work. I have a one thought

• we need to find another way to map UBDEs to ValidatorSetUpdateIds, i.e., a packet will be associated with multiple ValidatorSetUpdateIds.

Could we just send multiple packets instead?

EDIT: I see in the code it is done with multiple packets 👍