Agoric's dynamic IBC use case

[michaelfig]

Crate

ibc-relayer-cli

Summary

Meta-issue for Agoric's required features.

Problem Definition

https://github.com/Agoric/agoric-sdk implements IBC features for smart contracts running in our Javascript VM. We've converged on a certain workflow, which we made the Go relayer support, and we would love it if Hermes also supported it.

We expect these things turn out to be common for other chains implementing dynamic IBC functionality, so if they are coherently implemented in Hermes, it will benefit everyone involved.

If there are disadvantages to this workflow, we would hope to engage Informal to adjust it to better fit your architecture.

Proposal

We need the following features:

• Establish a new IBC connection (not channel) between two chains. Either have a script, or builtin functionality to keep retrying the process until it succeeds. -- Connection create CLI #630
• Query the above-established connection configuration and report it in a consistent (both human- and machine-readable) way. This is needed to give the JS contracts a way to name an established connection to another chain with just a connectionID. -- Hermes: replace default JSON with human-readable output #796
• Establish a new channel given just a source chain, already-established connectionID on that chain, source and destination portIDs, channel mode (ordered/unordered), and source version (these could be used to build a fresh "path"). -- Channel create CLI #715
• Start a streaming relayer, given only the path config (which could be copied from another relayer instance)
• There should be no restrictions on the number of paths relayed via the same connection. It may be worthwhile to make a "connection" its own first-class object that can support multiple "paths". -- Channel create CLI #715
• For ft-transfer, allow the supplied destination "address" to optionally be an arbitrary string. On the Agoric chain, where our bech32 prefix is "agoric", the transfer destinations are in their own namespace and look something like "board:1938586739". - Hermes token transfer CLI should permit custom destination address #806

I've only done a quick review of the docs to decide if they are implemented. Please feel free to check off the ones that have been implemented.

Comments welcome!

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[adizere]

Query the above-established connection configuration and report it in a consistent (both human- and machine-readable) way. This is needed to give the JS contracts a way to name an established connection to another chain with just a connectionID.

Can you provide more details on this? Wondering if this output fulfils your definition of both human- and machine-readable.

{
  "status": "success",
  "result": {
    "client_id": "07-tendermint-2",
    "counterparty": {
      "client_id": "07-tendermint-1",
      "connection_id": "connection-0",
      "prefix": "ibc"
    },
    "delay_period": 0,
    "state": "Open",
    "versions": [
      {
        "features": [
          "ORDER_ORDERED",
          "ORDER_UNORDERED"
        ],
        "identifier": "1"
      }
    ]
  }
}

Source: https://hermes.informal.systems/query_connection.html#query-the-connection-end-data

[michaelfig]

Can you provide more details on this?

How do I find out the source connectionID (connection-1, for example) in order to make the query you suggested? For the Go relayer, I can run tx conn which after establishing the connection, prints out the connectionIDs mapped to the chain names:

I[2021-02-04|12:05:02.693] ★ Connection created: [ibc0]client{07-tendermint-0}conn{connection-0} -> [ibc1]client{07-tendermint-0}conn{connection-0} 

It fails my requirement of being easily machine-readable, but it's a start.

Ideally would be something a little bit like:

$ [run the command to establish the connection, which logs to stderr, and eventually prints to stdout:]
{
  "src": {
    "chainID": "ibc0",
    "clientID": "07-tendermint-0",
    "connectionID": "connection-0"
  },
  "dst": {
    "chainID": "ibc1",
    "clientID": "07-tendermint-1",
    "connectionID": "connection-1"
  }
}

[michaelfig]

@colin-axner here is the issue I mentioned in the IBC meeting. Feel free to chime in!

[colin-axner]

This all sounds good to me. I'm a fan of the machine-readable output. Relayers shouldn't be run by normal users but rather services who will likely want to integrate a relayer into their own existing code.

I have no idea how this relayer is designed, but one thing the golang relayer does poorly is reusing off-chain connections to chains for different channel relaying. For example, if you wanted to relay for 2 channels both with the same underlying connection, the golang relayer will create two separate RPC connections to the same connected node. As @michaelfig stated above, making connection a first class object will be useful. Once more IBC application modules are added, relayers will likely want to relay all the channels on an existing connection

[ancazamfir]

How do I find out the source connectionID (connection-1, for example) in order to make the query you suggested? For the Go relayer, I can run tx conn which after establishing the connection, prints out the connectionIDs ..

I believe the proposal by @adizere is the output for a connection end query. The output for the equivalent tx conn command for the Rust relayer would be very similar to what we have in the channel handshake CLI, just showing the two connection ends instead:

{
    "status": "success",
    "result": {
        "a_side": {
            "client_id": "07-tendermint-1",
            "chain": "ibc-1",
            "connection_id": "connection-1"
        },
        "b_side": {
            "client_id": "07-tendermint-1",
            "chain": "ibc-0",
            "connection_id": "connection-1"
        }
    }
}

Should be available soon in master, will let you know.