Discuss Inter-tx Proposal Type Functionality

[okwme]

The core of Interchain Accounts allows for the creation of account specific port/channel pairs and the execution of transactions on behalf of the accounts created via that port/channel. This functionality needs to be augmented by logic on a sending chain to authorize the initialization of transactions to be executed on destination chains. This document outlines the user story for a specific use of interchain accounts and the authorization implemented to support that use. I'll refer to this particular use as inter-gov that should be implemented in a similarly named module.

The user story that inter-gov supports is for the distribution module account controlled by the governance module (often referred to as the community pool) to control an interchain-account on a remote chain. An account on a remote chain controlled by the governance module on a local chain supports the following capabilities:

• Local chain can collectively manage funds located on a remote chain on behalf of an associated remote interchain account.
• Local chain can collectively delegate staking tokens on a remote chain to a remote chain's validator set on behalf of an associated remote interchain account.
• Local chain can collectively buy, sell or provide liquidity to token pairs on a remote chain dex on behalf of an associated remote interchain account.
• Local chain can collectively vote with remote funds on a remote chain's governance module on behalf of an associated remote interchain account.
• Local chain can collectively execute any transaction on a remote chain on behalf of an associated remote interchain account.

In order for these flows to be possible an initial port/channel connection needs to be established between the local chain and the remote chain. This creates a connection to the remote chain interchain account module on behalf of the local distribution module account. This should only need to take place once per local/remote chain pairs and could be initialized within the genesis of the local chain, or be initiated via a standard Message type on behalf of the distribution module account by anyone. Since it only needs to take place once, if executed via standard Message type, it should check whether the registration has already taken place and fail otherwise. If initiated via genesis it should likely have a manual initialization regardless in case the registration fails as part of genesis. Furthermore should the interchain account need to be registered on more than one destination chain a standard Message should be possible for multiple destination chains.

Once an interchain account has been registered on behalf of the distribution module account on one (or more) destination chains, proposals to execute transactions on behalf of the interchain account need to be added to the local chain governance module. This proposal type should be added to the inter-gov module to be handled by a proposal handler. The Proposal Type should look similar to the following:

message CommunityPoolICARunTXProposal {
  option (gogoproto.equal)            = false;
  option (gogoproto.goproto_getters)  = false;
  option (gogoproto.goproto_stringer) = false;

  string   title                           = 1;
  string   description                     = 2;
  string   ibcTransferPort                       = 3;
  string   ibcTransferChannel                       = 4;
  repeated cosmos.base.v1beta1.Coin amount = 5
      [(gogoproto.nullable) = false, (gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.Coins"];
  string icaDestPort = 6
  string icaDestChannel = 7
  repeated cosmos.base.v1beta1.Msg msgs = 8
      [(gogoproto.nullable) = false, (gogoproto.castrepeated) = "github.com/cosmos/cosmos-sdk/types.Msg"];
}

Notably this proposal type includes both a slice of Coins and a slice of Msg. To begin we'll focus on the Msg. These are to be included as part of a proposal that when successfully voted are to be executed in sequence on the remote chain on behalf of the distribution module account instantiated on the remote chain as an interchain account. The sender of these messages will always be the distribution module account, which is the module account that holds all community pool funds.

The Coins type is necessary because a remote account is only as useful as the assets it controls within its local context and it can be assumed that many transactions executed remotely will depend on the presence of funds to be relevant. It would also be possible to break up the action into two separate proposals, one to fund the remote account, and another to execute on behalf of the remote account. However the decision to fund the remote account will likely be dependent on the decision to execute on behalf of the remote account and it would be undesirable to be in a situation where the decision to fund the remote account passed but the decision to execute failed (or vice-versa). Should the remote account already be funded it is easy enough to leave the Coin parameter empty.

A ProposalHandler should be added to the inter-gov and registered as a route in the local chain governance module. This handler is executed upon successful passing of a vote of the previously mentioned Proposal Type. If the proposal includes any Coins it will require the execution of a standard IBC Transfer message and so the IBC Transfer keeper will need to be accessible by the inter-gov module. Should the transfer be successful, as designated through the callbacks provided within the IBC Transfer module, the RunTx component of the Proposal should be executed by the core Interchain Account keeper (also imported to the inter-gov module). This does open up the unfortunate possibility that an IBC Transfer could be successful while the subsequent RunTX of the Interchain Account could fail. Should that be the case it would be possible to initiate a subsequent Interchain Account RunTx that would include an IBC Transfer to move the funds back to the origin chain. Or this action could be contained within a subsequent inter-gov CommunityPoolICARunTXProposal that if passed would attempt to execute a remote IBC Transfer message.

[ethanfrey]

Looks very nice Billy.

Two minor points:

• Clarify validation/organization - if amount is empty, then both ibcTransferPort and ibcTransferChannel may be empty, otherwise required. At least that makes sense with you declaring that all optional. Would it also make sense to have one that only transfer funds and not a message?If so, we would need similar handling of msgs. We just ensure at least one of those two actions is fully defined. Maybe we create sub-structs for each of those two movements, and require at least one?
• ICA identifier - wouldn't it make more sense to declare icaSrcPort and icaSrcChannel (not dest). I mean there is a 1:1 mapping and defining one side will define the other side. But defining the source allows the ICA module to just use that to send. Defining the dest means it must store a mapping and look that up.

Otherwise, the flow looks good and I like the idea of combining funding and execution in one message. I also like that you define the ordering such that only after successful fund transfer is the RunTx packet written. Also big thanks for explicitly including the use cases.