Support ics-29-fees

[alpe]

A new MsgPayPacketFee was introduce to attach fees to an IBC packet. Both messages are normally bundled in a single TX to incentivise the right IBC package. See this nice article for the full workflow.

I think that we could fully create and handle the MsgPayPacketFee for "fee enabled channels" in wasmd without exposing any internals to the contracts. The RecvFee, AckFee and TimeoutFee coin values could be added to our IBCMsg messages for this.

[webmaster128]

Looking at how this is implemented as separate messages, I think we could just add support for the two message types MsgPayPacketFee and MsgPayPacketFeeAsync as new enum cases to IbcMsg. Since this is #[non_exhaustive] we can add message types in a non-breaking way.

[alpe]

With CosmWasm/wasmd#1154, we have the foundation to support a pay fee msg released. But IMHO this makes sense for only some very advanced use cases where people want to tweak their fee amounts.

Instead I propose a single fee field as first class attribute in our ibc TransferMsg + SendPacketMsg types We should handle all the complexity for contract developers in wasmd instead.

[webmaster128]

I have two questions here, pretty independent of the implementation:

1. How would the contract know which IBC fee is appropriate?
2. If the contract say it pays X foocoin, how should we split this in the fee components by default?

[alpe]

• How would the contract know which IBC fee is appropriate?

There is no mechanism like "gas used" to build a fee amount. It is also unclear to me, what a "fair fee" is for a packet to be relayed. When IBC fees are used on mainnets, I would expect some algorithms built into common relayer tools that can help us here. At current stage, I would only assume, higher fees = higher priority and probability to be relayed, which is also not backed by real data.

• If the contract say it pays X foocoin, how should we split this in the fee components by default?

Without more production data, this is also completely unclear to me. The timeout_fee != ack_fee must be there for some edge cases where timeout does not matter or is super important. IMHO a ratio of 1/2 fee for all values would be a good start. Some people may be clever to add the full fee to ack/timeout but I would not trust the relayer tools to consider this already.

In wasmd the ratio could be configured by chains but I don't know how this could be done in CosmWasm with stability guarantees. Maybe we can have a query for this to wasmd? It would also be good to get some more information on fees from an ibc channel.

[webmaster128]

Do I understand correctly that the fee payer must always be the contract itself? I.e. refund_address can be set automatically by wasmd to the contract and we only support the Fee fee field? Nevermind, what we need to fill is MsgPayPacketFee and there signer will just be the contract.

[alpe]

what we need to fill is MsgPayPacketFee and there signer will just be the contract.

That is correct. For the contract developer though we can have a nicer interface.

[alpe]

Contract developers will have a hard time to come up with some reasonable IBC fees. I had talked with the IBC-Go team on private slack about this in the past and they opened cosmos/ibc-go#3336 to provide some data on chain. We can then have a query for contract devs. Alternatively some people may want to maintain price oracle contracts that could be queried.

[webmaster128]

We can then have a query for contract devs. Alternatively some people may want to maintain price oracle contracts that could be queried.

That sounds like a reasonable path. In this case the contract can query a struct with all 3 fields set right away, decide if it wants to change values and send the price info along with the packet. Merging the price info in a single amount (i.e. losing information) and then having to split it back in wasmd does not seem to be very helpful.

[webmaster128]

Getting the data from chain directly would be limited to contract executions with a stable gas consumption. If a relayer usually accepted a certain price and the next packet now requires 10x the gas, the price of the past packets will be too low. In general, paying per packet assumes constant or limited relaying cost.