Future proofing ICS20 transfers for potential flow-encrypted token transfers

[plaidfinch]

The ICS20 format has four String-valued fields in a FungibleTokenPacketData:

• sender
• receiver
• denom
• amount

For our initial release, the ICS20 design puts all these fields in cleartext, but with an ephemeral, unlinkable address used as the receiver. This makes sense because:

(a) It requires no extra tooling to be developed by counterparty chains, only wallet support to form ephemeral penumbra addresses, and (b) It doesn't make sense to shield IBC transfers incoming from transparent chains, because the transaction that produced the packet is unencrypted on the counterparty chain to begin with.

However, in the private interchain future, we may want to privately interoperate with other private chains, do flow-encryption-based batching of transfer amounts, and other such things. We want to make sure that the choices we make about the parsing of our FungibleTokenPacketData (on the incoming side) don't prevent us from these possible upgrades in the future.

One problem that could arise is the lack of a domain separator or "variant tag" to use PL terminology, to distinguish between a current, transparent FungibleTokenPacketData, and a future, shielded one. The issue would arise if the same FungibleTokenPacketData could be simultaneously, ambiguously parsed as either our transparent format or some future shielded format. At the same time, we can't impose changes to the format now that require code changes on the part of ordinary transparent chains to interoperate with us. How to proceed?

A solution which requires us to do nothing at all right now:

When we choose to support some future encrypted incoming IBC transfer format, use the Human Readable Part of the Bech32 encoding of the receiver field to distinguish which kind of transfer it is. An ordinary penumbra1 address as the receiver would mean that the packet should be parsed as a transparent transfer. However (name deliberately too long for a real HRP, to ensure that it is properly bikeshedded) a penumbrashieldedincoming1 address would indicate that the packet is to be parsed as an encrypted packet. Adopting this approach would require no code changes except parsing an additional HRP in the Penumbra codebase as a valid Address (a field to the internally-parsed struct should probably be added so it can be pretty-printed back as the same format it was received? or maybe not!), and of course whatever changes are necessary to support the new encrypted transfer functionality.

[hdevalence]

Wait, why would a future shielded cross-chain token transfer use ICS20? Since it needs changes on both chains, wouldn't it be better to use a different protocol, rather than trying to stuff it into ICS20? And at that point, there's no issue here, correct?

[plaidfinch]

It would need changes on both chains, so it needn't get put in ICS20, that's right. I was assuming from context in discussion with @avahowell that we were potentially constrained to keep using ICS20 even in that situation.