Description

The critical design decision that needs to be made here is how the user should identify which module a given request should be routed to. The most natural instinct here is to make use of the chain-ids of the two chains that a given module connects. However, this approach has a couple challenges.

1. Each module is a single sided relayer. Therefore, to have a complete IBC relayer between two chain's IBC implementations, it takes two modules. Thus, whatever identification scheme we use, it must at least contain two chain id's (source chain-id is not enough)

2. Multiple modules may connect the same chain or chain pairs. This is because there might be multiple IBC implementations for a single chain such as ibc-go, cosmwasm-ibc, or union-ibc. Therefore, identifying each module with a pair of chain-ids would be a artificial limitation.

Proposal

Since identifying each module seems to introduce certain limitations to the relayer, I think we should leave the identification up to the user. This proposes allowing the user to assign an id to each module (instead of a port) in the config file. This also means that the user would have the freedom to identify each module using chain-ids if they think this limitation is reasonable.

For instance, the example config file would change in the following manner:

{
  "server": {
    "log_level": "info",
    "address": "127.0.0.1"
  },
  "modules": [
    {
      "name": "cosmos_to_eth",
-      "port": 3000,
+      "id": "cosmoshub-4-eth-1"
      "config": {
        "tm_rpc_url": "http://public-celestia-mocha4-consensus.numia.xyz/",
        "ics26_address": "0x1234567890abcdef1234567890abcdef",
        "eth_rpc_url": "https://ethereum-holesky-rpc.publicnode.com",
        "sp1_private_key": "0x1234567890abcdef1234567890abcdef"
      }
    },
    {
      "name": "eth_to_cosmos",
-      "port": 3001,
+      "id": "eth-1-cosmoshub-4"
      "config": {
        "tm_rpc_url": "http://public-celestia-mocha4-consensus.numia.xyz/",
        "ics26_address": "0x1234567890abcdef1234567890abcdef",
        "eth_rpc_url": "https://ethereum-holesky-rpc.publicnode.com",
        "eth_beacon_api_url": "https://ethereum-holesky-beacon-api.publicnode.com",
        "signer_address": "cosmos1abcdef1234567890abcdef1234567890"
      }
    },
    {
      "name": "cosmos_to_cosmos",
-      "port": 3002,
+      "id": "cosmoshub-4-osmosis-1"
      "config": {
        "src_rpc_url": "https://noble-testnet-rpc.polkachu.com:443",
        "target_rpc_url": "http://public-celestia-mocha5-consensus.numia.xyz/",
        "signer_address": "cosmos1abcdef1234567890abcdef1234567890"
      }
    }
  ]
}

And the relay request would change to:

// The request message
message RelayByTxRequest {
+    // The identifier for the relayer module to handle this request
+    string relayer_module_id = 1;
    // The identifiers for the IBC transactions to be relayed
    // This is usually the transaction hash
    repeated bytes source_tx_ids = 2;
    // The identifiers for the IBC transactions on the target chain to be timed out
    repeated bytes timeout_tx_ids = 3;
    // The identifier for the target channel
    // Used for event filtering
    string target_channel_id = 4;
}

It is true that it could in theory be multiple implementations of IBC on a single chain, I am not sure it is a limitation we need to worry too much about. Unless we have a clear use case where this is very important, I would not optimize for it, especially not at the cost of user experience.

With an arbitrary ID assigned to the relayer, the user will need to keep a mapping of which chain pairs goes with which ID, which seems unnecessary if that could be simply configured with something like:

modules": [
    {
      "src_chain": "cosmos-hub-4",
      "dst_chain": "eth-1",
      ...

And when you relay, all you need to do is provide those chain ID's which I assume you will have readily available (if not, this argument might not be very strong).

// The request message
message RelayByTxRequest {
    src_chain = 1;
    dst_chain = 2;
    ...
}

At least to me, this feels more intuitive, than even needing to know that they are different modules that are wired up. If the user don't have to know, it seems like it might be better abstraction.

EDIT: Changed from src/dst_chain_id to src/dst_chain after internal discussion.
This allows for a bit more flexibility, as you could just use whatever identifier makes most sense to your own usage (which might just be chain-id, but if you want to use some internal database ID or whatever, you could). It also enables you to target multiple IBC implementations if you would need that.

I think this looks good after the edit. Happy to go with this.

We had a discussion on how adding IBC classic relaying would impact the design, so we need to look at that before we fully implement this, but we should do that asap and get this work started.