CPGF & RPGF over IBC

[cwgoes]

Namada should support CPGF (recurring) and RPGF (one-time) allocations which are sent to an address over IBC (maybe also over the Ethereum bridge, but we can start with only IBC). When these allocations are processed, instead of sending tokens to a Namada address (as we do for CPGF right now), we should generate an ICS20 transfer packet on the specified port, connection, and channel, to the specified destination address on the other chain. We don't need to worry about handling timeouts for now (but we should set a long timeout on the packet, maybe slightly under an epoch length).

@Fraccaman Does this seem straightforward to implement, or is anything potentially tricky?

[Fraccaman]

I haven't look at IBC a lot lately, but I think we it should be douable.

[yito88]

We have two PGF payments now:

• PGFAction::Continuous
• PGFAction::Retro

In PGFAction::Continuous, PGFTarget that has the target address and the amount is stored in the storage. Then the actual payments are executed according to PGFTargets every epoch in apply_inflation().

In PGFAction::Retro, the payment is executed immediately.

To execute these payments over IBC, changes are required to add an IBC transfer in addition to the existing transfer. Specifically, when the target address doesn't exist on this chain, it makes an IBC transfer message (MsgTransfer) and execute IbcAction::execute() with the message. The IBC message requires:

• Port ID
• Channel ID
• Timeout height
• Timeout timestamp
• Token address
• Source address
• Target address

The timeout height and timestamp can be set some long time. The addresses are the same as those of an internal transfer. The port ID and channel ID should be specified for a port/channel that are already open and on which packets are relayed by a relayer.

For the port ID and channel ID, we could add members to PGFTarget and other structs. In this case, a proposal should include the port ID and the channel ID.

pub struct PGFTarget {
    /// The target address
    pub target: Address,
    /// The port ID to fund over IBC
    pub port_id: Option<PortId>,
    /// The channel ID to fund over IBC
    pub channel_id: Option<ChannelId>,
    /// The amount of token to fund the target address
    pub amount: Amount,
}

[cwgoes]

This broadly makes sense to me. We don't care about handling timeouts on PGF-over-IBC packets for now, the timeout parameters can just be set far in the future as you mention. One slight tweak: rather than having optional port ID and channel ID members, we should have the target be either simply an internal address or an "IBC address" which must have the remote chain address, port ID, and channel ID.

[Fraccaman]

agree with @cwgoes, 2 different targets would be better imo