Investigate & document learnings from the Go relayer

[adizere]

Summary

Goals:

• learn from their design decisions
• compare performance

Preliminary findings

last few blocks are cached so they save on client update queries during relaying. Also the pending packet data and state (sent, received, acked) is kept. This is maintained by events processing that updates the packet state. I know we talked about maintaining more state in hermes before but maybe now it’s a good time to do this and reduce the full node pressure.

in their legacy architecture the relayer is polling everything periodically to figure out what work needs to be done (there is no event based relaying). This is the same as hermes initial packet clearing done forever.
There have been a few issues raised by people wrt to performance and the high number of queries. Just looked now and i think that the main improvements were done under the “event processor” and the changes are described here:
cosmos/relayer#743
cosmos/relayer#813
Very high level with the -p events flag now they query all blocks since the last query, extract all IBC events from all tx-es, create some sort of message cache and relay based on that.

[AlianBenabdallah]

• An IBC-go instance relays on only one path.
• It is possible to have multiple wallets for a given chain.
• IBC-go had a REST API Server which could manipulate the relayer removed in this commit but they are now working on a basic dashboard.
• They'll add recommended vm settings in the docs.
• The config file is a yaml file that can be initialized with rly config init.

hubosmo:
  src:
    chain-id: cosmoshub-4
    client-id: 07-tendermint-259
    connection-id: connection-257
  dst:
    chain-id: osmosis-1
    client-id: 07-tendermint-1
    connection-id: connection-1
  src-channel-filter:
    rule: allowlist
    channel-list: [channel-141]

• The current config can be showed with rly config show. The output of rly config show can be formatted in json and other formats :

global:
    api-listen-addr: :5183
    timeout: 10s
    memo: ""
    light-cache-size: 20
chains: {}
paths: {}

• It is also possible to show the config of a specific chain with rly chains show chain_id :

type: cosmos
value:
    key: default
    chain-id: cosmoshub-4
    rpc-addr: https://rpc.cosmoshub.pupmos.network:443
    account-prefix: cosmos
    keyring-backend: test
    gas-adjustment: 1.2
    gas-prices: 0.01uatom
    debug: false
    timeout: 20s
    output-format: json
    sign-mode: direct

• It is possible to add a chain to the config file from a chain.json file, in bulk from a directory, from a remote file or from recommended settings by just typing the name of the chain (ex: rly chains add cosmoshub osmosis).
• It can fetch path information from the interchain folder with rly paths fetch and output them with rly paths list.

0: hubosmo              -> chns(✔) clnts(✔) conn(✔) (cosmoshub-4<>osmosis-1)
1: osmohub              -> chns(✔) clnts(✔) conn(✔) (osmosis-1<>cosmoshub-4)

• rly chains list shows the current state of the config :

0: cosmoshub-4          -> type(cosmos) key(✔) bal(✔) path(✔)
1: osmosis-1            -> type(cosmos) key(✔) bal(✔) path(✔)

• Their CLI is lighter. They have both long and short name for flags and subcommands. They use fixed-position arguments.
  Example : rly q bal cosmoshub-4 wheras Hermes would have hermes keys balance --chain cosmoshub-4.

• Their transfer command can specify the destination address and does not use the port rly transact transfer src_chain_name dst_chain_name amount dst_addr src_channel_id.