Should registering counterparty address be based on channel ID or client ID?

[soareschen]

Summary

From the relayer stand point, registering counterparty address based on client ID may be more efficient than channel ID.

Problem Definition

Currently in #276, the counterparty address is registered based on channel ID. This works fine in today's setting, where most IBC clients only have one associated channel. With the introduction of Interchain Accounts, there may be many more channels associated with an IBC client. If incentivized fee is enabled on all these channels, the relayer may need to perform repeated work of registering its counterparty address every time it relays on a new channel.

A potentially more efficient approach is to allow a relayer to register its counterparty address based on the client ID instead of channel ID. That way, it can reuse the same counterparty address for all channels created on the client.

We should still consider if there can be any case where a relayer would want to register different counterparty addresses on different channels on the same client. It could also be possible that registering counterparty address on every channel do not introduce as much overhead as we imagined, depending on the actual use cases of IBC.

Proposal

Register counterparty addresses based on client ID instead of channel ID.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[crodriguezvega]

Thanks for opening these issues, @soareschen!

[colin-axner]

This is a great point, what if we try to do the best of both worlds. It'd be slightly awkward under the hood, but we could introduce a new message to allow relayers to register a counterparty address for a client ID. The address associated with a clientID would be the default address, if an address is registered with a channel ID then that takes precedence

So two mappings:
channelID -> counterparty address
clientID -> address

two messages:

Register counterparty address:
set counterparty address for channelID
if clientID mapping DNE -> set counterparty address for clientID

Register default counterparty address:
set counterparty address for clientID

When getting forward relayer address:
if channelID mapping DNE -> check for clientID mapping

[colin-axner]

Given that my proposed solution can be made backwards compatible and that the unknown concern here is whether it is desirable to have a counterparty address per channel rather than a default address for all channels associated with a client ID, I'd be in favor of changing our existing mapping to use the clientID

Then, if we get feedback/desire for a per channel counterparty address, we could add in a new message to do the channel ID mapping. This could be accomplished in a minor release

[AdityaSripal]

Thanks for the suggestion @soareschen. I'd actually like to push back and keep the mapping to be channelID for now for a number of reasons.

---

1. ChannelID is the natural mapping to use here.

Each relayer is choosing to relay on a particular channel not over particular clients. Thus the natural architecture for relayer incentivization especially as it is being implemented at the channel layer, is to use the channelID.

2. Using ClientID requires more state reads.

If we use channelID, then we get the following state reads:

state read: retrieve relayer mapping using channelID
state read/write: pay relayers

If we use clientID, then we get the following state reads:

state read: retrieve channel from channelID
state read: retrieve connection using channel.connectionID
state read: retrieve relayer from mapping using connection.clientID
state read/write: pay relayers

Of course, we can reduce the number of state reads in the second case by caching the channelID->clientID mapping in the middleware state. But this is still an additional state read, and additional state to store in the middleware. I believe we should keep the middleware as lightweight and stateless as possible.

So there is a tradeoff between number of relayer msgs and state reads during packet execution. Since there will be many more packet executions than relayer registration msgs, I think we should optimize on simplifying the packet execution logic in our middleware.

3. The number of relayed channels/client is expected to be low.

I expect that an individual relayer will relay a small number of channels/client for the foreseeable future. This optimization becomes more attractive if there are many many channels that a relayer will relay for on a given client. But realistically most relayers will only relay on one canonical channel per application between two chains. And it isn't even clear to me that relayers will choose to relay on all applications. I imagine there will be transfer-only relayers and ICA-only relayers.

So I would like to see this play out in the ecosystem before implementing a premature optimization.

4. Simpler relayer workflow

It is trivial implementation-wise for relayers to integrate the once-per-channel registration msg whenever they create a new channel or decide to relay on an existing one. It is a bit more complicated to figure out if you've already registered on the underlying client but not too difficult so this is a minor benefit.

5. Easier per-channel revenue monitoring

Another minor benefit is that relayers may intentionally use different addresses for different channels so they can easily track the revenue/cost/profit of each individual channel and use this to make operator decisions. If all of it is pooled by client, it is more difficult to assess whether it is worth relaying on a particular channel.

---

Given that channelID mapping is more natural and has some benefits over clientID mapping, I think we should leave the spec as is. And if relayer operators request the clientID mapping, we can add it in as a backwards-compatible feature rather than doing it as a premature optimization