cosmos / relayer Goto Github PK

An IBC relayer for ibc-go

License: Apache License 2.0

Go 98.89% Makefile 0.48% Dockerfile 0.55% Shell 0.08%

relayer's Introduction

Relayer

In IBC, blockchains do not directly pass messages to each other over the network. This is where relayer comes in. A relayer process monitors for updates on opens paths between sets of IBC enabled chains. The relayer submits these updates in the form of specific message types to the counterparty chain. Clients are then used to track and verify the consensus state.

In addition to relaying packets, this relayer can open paths across chains, thus creating clients, connections and channels.

Additional information on how IBC works can be found here.

Basic Usage - Relaying Packets Across Chains

The -h (help) flag tailing any rly command will be your best friend. USE THIS IN YOUR RELAYING JOURNEY.

Clone, checkout and install the latest release (releases page).

Go needs to be installed and a proper Go environment needs to be configured
```
$ git clone https://github.com/cosmos/relayer.git
$ cd relayer && git checkout v2.5.2
$ make install
```
Initialize the relayer's configuration directory/file.
```
$ rly config init
```
Default config file location: ~/.relayer/config/config.yaml

By default, transactions will be relayed with a memo of rly(VERSION) e.g. rly(v2.5.2).

To customize the memo for all relaying, use the --memo flag when initializing the configuration.
```
$ rly config init --memo "My custom memo"
```
Custom memos will have rly(VERSION) appended. For example, a memo of My custom memo running on relayer version v2.5.2 would result in a transaction memo of My custom memo | rly(v2.5.2).

The --memo flag is also available for other rly commands also that involve sending transactions such as rly tx link and rly start. It can be passed there to override the config.yaml value if desired.

To omit the memo entirely, including the default value of rly(VERSION), use - for the memo.
Configure the chains you want to relay between.

In our example, we will configure the relayer to operate on the canonical path between the Cosmos Hub and Osmosis.
The rly chains add command fetches chain meta-data from the chain-registry and adds it to your config file.
```
$ rly chains add cosmoshub osmosis
```
Adding chains from the chain-registry randomly selects an RPC address from the registry entry. If you are running your own node, manually go into the config and adjust the rpc-addr setting.

NOTE: rly chains add will check the liveliness of the available RPC endpoints for that chain in the chain-registry. It is possible that the command will fail if none of these RPC endpoints are available. In this case, you will want to manually add the chain config.

To add the chain config files manually, example config files have been included here
```
$ rly chains add --url https://raw.githubusercontent.com/cosmos/relayer/main/docs/example-configs/cosmoshub-4.json cosmoshub
$ rly chains add --url https://raw.githubusercontent.com/cosmos/relayer/main/docs/example-configs/osmosis-1.json osmosis
```
Import OR create new keys for the relayer to use when signing and relaying transactions.

key-name is an identifier of your choosing.

If you need to generate a new private key you can use the add subcommand.
```
$ rly keys add cosmoshub [key-name]
$ rly keys add osmosis [key-name]
```
If you already have a private key and want to restore it from your mnemonic you can use the restore subcommand.
```
$ rly keys restore cosmoshub [key-name] "mnemonic words here"
$ rly keys restore osmosis [key-name] "mnemonic words here"
```
Use the key-name created above.

This step is necessary if you chose a key-name other than "default"
```
$ rly keys use cosmoshub [key-name]
$ rly keys use osmosis [key-name]
```
Ensure the keys associated with the configured chains are funded.

Your configured addresses will need to contain some of the respective native tokens for paying relayer fees.

You can query the balance of each configured key by running:
```
$ rly q balance cosmoshub
$ rly q balance osmosis
```
Configure path meta-data in config file.
We have the chain meta-data configured, now we need path meta-data. For more info on path terminology visit here.

NOTE: Thinking of chains in the config as "source" and "destination" can be confusing. Be aware that most path are bi-directional.

rly paths fetch will check for IBC path meta data from the chain-registry and add these paths to your config file.
```
$ rly paths fetch
```
NOTE: Don't see the path metadata for paths you want to relay on? Please open a PR to add this metadata to the GitHub repo!
Configure the channel filter.

By default, the relayer will relay packets over all channels on a given connection.
Each path has a src-channel-filter which you can utilize to specify which channels you would like to relay on.
The rule can be one of three values:
- allowlist which tells the relayer to relay on ONLY the channels in channel-list
- denylist which tells the relayer to relay on all channels BESIDES the channels in channel-list
- empty value, which is the default setting, and tells the relayer to relay on all channels
Since we are only worried about the canonical channel between the Cosmos Hub and Osmosis our filter settings would look like the following.
Example:
```
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]
```
Because two channels between chains are tightly coupled, there is no need to specify the dst channels. If you only know the "dst" channel-ID you can query the "src" channel-ID by running: rly q channel <dst_chain_name> <dst_channel_id> <port> | jq '.channel.counterparty.channel_id'
Finally, we start the relayer on the desired path.

The relayer will periodically update the clients and listen for IBC messages to relay.
```
$ rly paths list
$ rly start [path]
# Optionally you can omit the `path` argument to start all configured paths
$ rly start
```
When running multiple instances of rly start, you will need to use the --debug-addr flag and provide an address:port. You can also pass an empty string '' to turn off this feature or pass localhost:0 to randomly select a port.

[TROUBLESHOOTING]

Security Notice

If you would like to report a security bug related to the relayer repo, please follow the instructions in SECURITY.md.

Code of Conduct

The Cosmos community is dedicated to providing an inclusive and harassment free experience for contributors. Please visit Code of Conduct for more information.

Create Path Across Chains -->

relayer's People

Contributors

Stargazers

Watchers

Forkers

kwunyeung anilcse zhangyelong kaustubhkapatral liangping jhernandezb dokiacapital sorawit informalsystems isgasho node-a-team b-thk dryruner agoric-labs franono nylira westaking xiangjianmeng fl-y lzydou sikkatech marcelmws 1xcl randomshinichi saisunkari19 booyoun-kim harsh-98 wangfeiping qosgroup tharamalai dunhill-high cosmiccompass stakezone eg-easy jokerthebond retz80 daluxxx mr-k-validator jaygaga w1t raykyri liamsi nikolayqwerty gunray88 huglester denalimarsh apalaikis stirnetwork isillien yefymdmukh latenthero pylons-tech clawmvp zaketac chainapsis wetezos rich518 edouardlvdl alexticea cyborgshead kalpatech-team novy4 gruberx armyids blackbear10000 scf0220 regen-network thetechtrap aynelis vidorge adrianverde staking-agency chainode andreisid sconeman kysenpool bluele toshihiko-okubo iammelea commercionetwork ivanmolto webhacking p2p-org wjdfx jsimnz blockscapenetwork starclusterteam eddienuta tac0turtle mingderwang akhilkumarpilli sourcenetwork asmodat bl0cks jjangg96 shiki-tak andynog stakefish sifchain ilgooz

relayer's Issues

Add agoric chain to github actions

Error when initializing the chain on the local setup

The server setup works like a charm for me. However, when I do the local setup on a standalone server, I get the following error when initializing the lite client for mychainid:

rly lite init mychainid -f
Error: only one witness left. please reset the light client
only one witness left. please reset the light client

I also reinstalled both machines, and again the same error. Base system is Ubuntu 18.04.

rly version
version: 0.2.1-4-ge655713
commit: e655713
cosmos-sdk: v0.34.4-0.20200419154345-84774907316c
go: go1.14 linux/amd64

After rly lite delete mychainid, still the same error when initializing.

Document Relayer Folder Structure and CLI

There needs to be some documentation on:

relayer folder structure,
formats and purposes of all files in ~/.relayer
notes about the different configuration options.

Segmentation violation while following README

Getting the following error about 1/2 way down the README instructions

$ rly tx full-path demo-path
I[2020-03-24|15:38:42.463] ✘ [ibc0]@{0} - msg(0:create_client) err(sdk: tx parse error)
I[2020-03-24|15:38:42.476] ✘ [ibc1]@{0} - msg(0:create_client) err(sdk: tx parse error)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xe6b065]

goroutine 1 [running]:
github.com/iqlusioninc/relayer/relayer.(*Chain).CreateConnectionStep(0xc000e7c480, 0xc000e7c6c0, 0x0, 0x0, 0x0)
/home/mjackson/iqlusion/relayer/relayer/tx.go:147 +0x4b5
github.com/iqlusioninc/relayer/relayer.(*Chain).CreateConnection(0xc000e7c480, 0xc000e7c6c0, 0x2540be400, 0x4, 0xc000e983d0)
/home/mjackson/iqlusion/relayer/relayer/tx.go:79 +0x84
github.com/iqlusioninc/relayer/cmd.fullPathCmd.func1(0xc000e4a840, 0xc000e700d0, 0x1, 0x1, 0x0, 0x0)
/home/mjackson/iqlusion/relayer/cmd/tx.go:190 +0x39d
github.com/spf13/cobra.(*Command).execute(0xc000e4a840, 0xc000e70090, 0x1, 0x1, 0xc000e4a840, 0xc000e70090)
/home/mjackson/iqlusion/go/pkg/mod/github.com/spf13/[email protected]/command.go:840 +0x453
github.com/spf13/cobra.(*Command).ExecuteC(0x1ee5f40, 0x44563a, 0x1e796c0, 0xc000000180)
/home/mjackson/iqlusion/go/pkg/mod/github.com/spf13/[email protected]/command.go:945 +0x317
github.com/spf13/cobra.(*Command).Execute(...)
/home/mjackson/iqlusion/go/pkg/mod/github.com/spf13/[email protected]/command.go:885
github.com/iqlusioninc/relayer/cmd.Execute()
/home/mjackson/iqlusion/relayer/cmd/root.go:98 +0x55
main.main()
/home/mjackson/iqlusion/relayer/main.go:21 +0x20

Relay connCloseConfirm

As per title, add relaying connCloseConfirm (cli and event based triggered).

gaiad node crash meanwhile was runing

https://paste.ubuntu.com/p/62dfwNjqMT/

Implement IBC transactions

Each individual IBC transaction should be able to be run by the relayer individually as well as in logical groupings (channel, connection). These primitives can then be combined in strategies.go in a number of ways.

Original issue: #10

The following are the necessary txs:

Create Subscribe relayer

Original issue: #48

The subscribe relayer strategy should be the primary mode that the relayer is run under. It will c.Client.Subscribe("ibc-events") to each chain and then take the necessary actions to relay packets between chains.

This mode will Subscribe to all chains in the Config and error if all primitives in Paths are not setup. This is necessary because the data for Packets are not stored in state and are best handled this way.

The relayer should also have a mode for querying against a node with certain indices setup to fetch this data.

execute "systemctl status gaiad" failed

CentOS Linux release 7.7.1908 (Core)

rly version
version: 0.3.0-1-g5879ef9
commit: 5879ef9
cosmos-sdk: v0.34.4-0.20200423152229-f1fdde5d1b18
go: go1.14.1 linux/amd64

gaiad version --long
name: gaia
server_name: gaiad
client_name: gaiacli
version: 0.0.0-333-gd26d6ed
commit: d26d6eddcf8dbb87ed101f69419e3b79cdb568c6
build_tags: netgo,ledger
go: go version go1.14.1 linux/amd64

I try to join the testnet,

Everything looks like ok in Server Setup,
but when I execute "systemctl status gaiad", I get failed.

● gaiad.service - gaiad
Loaded: loaded (/etc/systemd/system/gaiad.service; disabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: exit-code) since 五 2020-04-24 14:54:19 CST; 1s ago
Process: 602 ExecStart=/root/go/bin/gaiad start --pruning=nothing (code=exited, status=1/FAILURE)
Main PID: 602 (code=exited, status=1/FAILURE)

4月 24 14:54:19 iZ6we0wdz6sdpueno5relzZ systemd[1]: gaiad.service: main process exited, code=exited, status=1/FAILURE
4月 24 14:54:19 iZ6we0wdz6sdpueno5relzZ systemd[1]: Unit gaiad.service entered failed state.
4月 24 14:54:19 iZ6we0wdz6sdpueno5relzZ systemd[1]: gaiad.service failed.

I try to execute "/root/go/bin/gaiad start --pruning=nothing",
Then I get:

I[2020-04-24|14:54:31.421] starting ABCI with Tendermint module=main
ERROR: error during handshake: error on replay: validator set is nil in genesis and still empty after InitChain

Do I do something wrong?

Chains Add improvements

Original issue: #51

As a follow-on from #49, there are a couple of features I would like to see added to relayer chains add.

relayer chains add --url [url] - This would fetch the json and add the chain after verifying it. Think usage from a github repo (https://raw.githubusercontent.com/cosmos/relayer/tree/master/demo/ibc0.json)
relayer chains add --cosmos [url] - This would query the /genesis endpoint to fetch most of the data and then would rely on sane defaults for gas and gasPrices based on that. This is basically figuring out how to unmarshal gaia based config.

Estimate gas prices instead of using a constant value

Constant gas (e.g. 200,000) in the configuration will not work in general, as IBC packet receipt may initiate further state transitions which consume more gas, and it's less efficient than estimating gas first, since 200,000 gas (or whatever the config value is) may not be required.

Make relayer actually only relay over channel/port that is configured.

Improved failure case when another relayer has already relayed a packet

Use lite client to verify all data coming back from queries

Original issue: #53

Concurrency and account queries

Sometimes transactions will fail due to incorrect account sequence numbers that haven't been updated properly.

Gracefully handle signature verification failed errors

Most of these errors come from a stale account state query. We should ignore these errors and retry. In the case of other transaction errors we should fail.

can't open lite client database: resource temporarily unavailable

This is an error we should gracefully handle in all cases with an exponential backoff.

Add ability to send on local chain

This is for sending tokens between two accounts.

rly tx link demo , i am get error

I cannot perform operations of "https://github.com/iqlusioninc/relayer". I'm getting an error. Where am I making mistakes.

root@cb520bd2d4e2:~# rly tx link demo
I[2020-04-21|14:59:27.222] ✘ [ibc0]@{0} - msg(0:create_client) err(sdk: tx parse error)
I[2020-04-21|14:59:27.241] ✘ [ibc1]@{0} - msg(0:create_client) err(sdk: tx parse error)
I[2020-04-21|14:59:28.152] ✘ [ibc0]@{29406} - msg(0:channel_open_init) err(connection: connection not found)
I[2020-04-21|14:59:37.558] ✘ [ibc0]@{29415} - msg(0:channel_open_init) err(connection: connection not found)
I[2020-04-21|14:59:47.950] ✘ [ibc0]@{29425} - msg(0:channel_open_init) err(connection: connection not found)
E[2020-04-21|14:59:47.950] ibc0: err(! Channel failed: [ibc0]chan{ibconexfer}port{transfer} -> [ibc1]chan{ibczeroxfer}port{transfer})

`rly version` requires to be executed in relayer directory

Running rly version from $HOME throws

$ rly version
Error: open go.mod: no such file or directory
open go.mod: no such file or directory

But from the relayer directory, it works.

$ cd go/src/github.com/iqlusioninc/relayer/
$ rly version
version: 0.1.0-115-g03bef79
commit: 03bef79312ebd12485427a41f2192aca5f7737bb
cosmos-sdk: v0.34.4-0.20200417201027-11528d39594c
go: go1.14 linux/amd64

Misbehaviour monitoring & relay

Given a particular configuration option, using the local light clients, the relayer should periodically check if any conflicting (equivocating) headers have been submitted to any on-chain IBC light clients on the chains which are being monitored (relayed between), and if they have, the relayer should automatically submit proof-of-misbehaviour to freeze the on-chain light clients (and print a very scary red warning message encouraging the user to immediately investigate).

Two-Chainz silent failure on unconventional gaia setup

When running ./two-chainz, there will be a silent failure if the user does not have the origin remote setup (on their gaia repo) or has their origin remote pointing to a different repo (a fork) other than github.com/cosmos/gaia. It silently fails because the output is being directed to /dev/null

Unlikely scenario, but I figured I'd open an issue in case someone runs into this issue. One side effect of this failure is the data/ directory not being created and filled.

Support Unordered channels

We need to support unordered channels for IBC.

Better way to install docker in tests

Currently we are installing docker on top of an ubuntu base image to run the unit tests for various chain compatibility tests. It would be ideal if we could avoid that step by having an image with it preinstalled.

Path negotiation commands

This command will look for existing clients, connections, and channels that link any pair of chains on the relayer and create a Path or Paths in the config to mirror that. Optionally, if some primitives don't exist, then names for them are generated and those primitives are created. This may be a number of different commands as the number of options here will grow quickly.

Unhandled connection and channel state case

A few first observations after trying the relayer commands.

many IDs local to ibc0 are of form ibcone<item> which for me intuitively meant <item> on chain ibc1. Maybe <item>toibc1...like connectiontoibc1, or connAtoB, etc if this is a connectionID with ibc0/ A scope (see demo json files)
the query connections command doesn't return local connection ID:

$ relayer query connections ibc0
[{"state":"OPEN","client_id":"ibconeclient","counterparty":{"client_id":"ibczeroclient","connection_id":"ibczeroconnection","prefix":{"type":"ibc/commitment/MerklePrefix","value":{"key_prefix":"aWJj"}}},"versions":["1.0.0"]}]

With multiple connections it's going to be hard to figure out the ID to query a given connection on a chain, ibc0 in this case

ditto for channels, query channels doesn't return local channel ID
error numbers are shown on SDK failures, hard to determine what is going on
looking at SDK connection handlers, it seems that both ends can be in INIT state and ConnOpenTry relayed to either end would still progress the handshake (rhis is not the case in the IBC specification). However the relayer does not relay for this case. Same for channel.

[I will collect more here]

Dynamic unbonding time

Currently unbonding time is hardcoded in the client creation command. We should have this be populated via the chain configuration.

Original issue:#56

Basic web-hook alerting system

Original issue: #57

Transition cli cmds to use x/ibc cli implementations

Currently it seems all the cli commands are fully implemented on this repo and do not rely on the cli implementation on x/ibc. I think it would be useful to eventually transition these cli commands to use the x/ibc code since folks developing ibc will probably use that. If I'm not mistaken Game of Stakes provided good user feedback on cli interactions and bugs and Game of Zones will likely lead to the same feedback and usage

Sequence send not found

My first test of two-chainz was successful, but having issues after retrying due to sequence send not found. I've closed and re-opened the channel, re-started both chains locally, verified balances, and initiated lite clients. I'm not sure what else I am missing. The following error occurs with both chains trying to transfer to each other.

stoner@stonerzone:~/iqlusion/relayer$ rly tx transfer ibc0 ibc1 10000n0token false $(rly keys show ibc1 testkey) [2020-04-14|12:20:10.690] ✘ [ibc0]@{56323} - msg(0:transfer) err(channels: sequence send not found) Error: failed to send first transaction

Failed connection or channel query with EOF unhandled

Sometimes during channel or connection operations the following error occurs. We should handle this error properly and potentially retry the query.

I[2020-03-23|00:56:50.175] ✔ [pylonchain]@{52612} - msg(channel_open_ack) hash(757A38A631F436E8705419FD52F82A7F768C1157AD87DD7CBD701367C6372FFC) 
Error: err: query channel failed: ABCIQuery: Post failed: Post "http://ibc-alpha.desmos.network:26657": EOF

Transfers are failing on different account-prefix chains

Transfers are not going through between chains with different account-prefix's
Here is the log:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xead32c]

goroutine 1 [running]:
github.com/iqlusioninc/relayer/relayer.(*Chain).CreateConnectionStep(0xc000d57560, 0xc000d57320, 0x0, 0x0, 0x7f0760e8a2d8)
 /home/sys-597/go/src/github.com/iqlusioninc/relayer/relayer/tx.go:153 +0x93c
github.com/iqlusioninc/relayer/relayer.(*Chain).CreateConnection(0xc000d57560, 0xc000d57320, 0x2540be400, 0xd, 0xc000df6090)
 /home/sys-597/go/src/github.com/iqlusioninc/relayer/relayer/tx.go:75 +0x84
github.com/iqlusioninc/relayer/cmd.fullPathCmd.func1(0xc000d13600, 0xc000d23780, 0x2, 0x2, 0x0, 0x0)
 /home/sys-597/go/src/github.com/iqlusioninc/relayer/cmd/tx.go:180 +0x384
github.com/spf13/cobra.(*Command).execute(0xc000d13600, 0xc000d23700, 0x2, 0x2, 0xc000d13600, 0xc000d23700)
 /home/sys-597/go/pkg/mod/github.com/spf13/[email protected]/command.go:840 +0x460
github.com/spf13/cobra.(*Command).ExecuteC(0x1f65620, 0x43f13a, 0x1efa600, 0xc000000180)
 /home/sys-597/go/pkg/mod/github.com/spf13/[email protected]/command.go:945 +0x317
github.com/spf13/cobra.(*Command).Execute(...)
 /home/sys-597/go/pkg/mod/github.com/spf13/[email protected]/command.go:885
github.com/iqlusioninc/relayer/cmd.Execute()
 /home/sys-597/go/src/github.com/iqlusioninc/relayer/cmd/root.go:97 +0x55
main.main()
 /home/sys-597/go/src/github.com/iqlusioninc/relayer/main.go:21 +0x20

Looks like the client connection is failing and QueryClientState returning empty state for second chain

Support listening on multiple paths at once

As title, e.g. with rly start, instead of accepting only one path, accept any number of paths, and listen on all of them simultaneously.

It will likely be easier to do this by adding a list of paths to listen on by default to the configuration.

Fix ci lint

The CI linter is failing intermittently, should be fixed.

`rly st [path]` fails if killed and run again

The first time I ran rly st [path], everything is going OK.

➜  rly st path12
I[2020-04-08|21:26:50.881] - No packets to relay between [bibc1]port{zoracle} and [bibc2]port{zoracle}
I[2020-04-08|21:26:50.966] - listening to events from bibc1...
I[2020-04-08|21:26:51.052] - listening to events from bibc2...
I[2020-04-08|21:26:55.201] • [bibc1]@{57788} - actions(0:request) hash(F9D70E3375BAC5EEC758D61A40C9613DED72CEA8BE170606F0F700C7F098FAB1)
I[2020-04-08|21:26:57.541] ✔ [bibc2]@{57315} - msg(0:update_client,1:ics04/opaque) hash(845A326BDBF6671426F3838A66B66069E663FEA2A9DADFADA77EAFED7F3A8894)
...

But when I killed it and ran it again, I got the following error.

➜  rly st path12
Error: unmarshal to types.StdTx failed after 6 bytes (error reading array contents: unrecognized prefix bytes 1359C6E6): 0A381359C6E60801120D626A7978666578756F714254431801200128904E30904E38904E42140D5E4BC456DDF0C7E7000C778E88878C3B4F0D12120410C0843D1A6A0A26EB5AE987210224B78C8E0CE303F402A9FEE1186D7A89C117CD90BF3751E8E185176AE514A3241240E89E8DFF3F7A25E0FBBEFC4409D107A5E521F0045B07F81E7C12F0F8CE304AA5617BBB0844B32C64BC98ECFA90C8065606A3DFD6632F3987004703371B26E8F0
Usage:
  rly start [path-name] [flags]

Aliases:
  start, st

Flags:
  -h, --help   help for start

Global Flags:
      --config string   set config file (default "config.yaml")
  -d, --debug           debug output
      --home string     set home directory (default "/Users/sorawit/.relayer")

unmarshal to types.StdTx failed after 6 bytes (error reading array contents: unrecognized prefix bytes 1359C6E6): 0A381359C6E60801120D626A7978666578756F714254431801200128904E30904E38904E42140D5E4BC456DDF0C7E7000C778E88878C3B4F0D12120410C0843D1A6A0A26EB5AE987210224B78C8E0CE303F402A9FEE1186D7A89C117CD90BF3751E8E185176AE514A3241240E89E8DFF3F7A25E0FBBEFC4409D107A5E521F0045B07F81E7C12F0F8CE304AA5617BBB0844B32C64BC98ECFA90C8065606A3DFD6632F3987004703371B26E8F0

Implement IBC Queries

The following queries for IBC need to be implemented on the relayer. All of these queries should also return proofs. They will be mainly useful for use in tx commands (as a way to query the chain for the necessary on-chain data) but should also be exposed to the user:

Original Issue: #19

Integration tests

The current plan is to test the relayer package using something like https://github.com/ory/dockertest and a gaia image that allows for passing in addresses to be funded for genesis. Will work on getting this setup.

Packet Commitment verification fails on transfer with different account prefix

Packet commitment verification fails when transferring to a destination chain that uses a different prefix .

I[2020-03-23|12:25:29.051] ✔ [ibc0]@{286} - msg(transfer) hash(CB9A024A586095C64540B3970026DA203BB0CD386305EE6D93DAE6786E7AB321)
I[2020-03-23|12:25:30.307] - [ibc1] -> sending transaction:
TRANSACTION INFO

I[2020-03-23|12:25:30.308] ✘ [ibc1]@{0} - msg(ics20/transfer) err(client: packet commitment verification failed)

{
  "height": "0",
  "txhash": "E1D8903BB782104761074433A2CA0495FD00293CB525309E3039265B04A21E02",
  "codespace": "client",
  "code": 16,
  "raw_log": "packet commitment verification failed: verifying value: leaf value hash not same: invalid proof: couldn't verify counterparty packet commitment",
  "gas_wanted": "200000",
  "gas_used": "98142"
}

How to fix "rly tx link [paths-name]" Errors.

The following error occurs when 'rly tx link [path-name]' command is used after setting paths in some validators.

$ rly tx link achain_pylonchain
I[2020-03-27|13:29:47.131] ✘ [achain]@{0} - msg(0:create_client) err(sdk: tx parse error)
I[2020-03-27|13:29:47.524] ✘ [pylonchain]@{0} - msg(0:create_client) err(sdk: tx parse error)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xf6bdee]

Solution.

Install the latest versions of gaiad and relayer for gaiad.service and faucet.service and restart.

After applying the solution, I checked that the information in my chain is coming out correctly.
However, the problem remains because the other party's chain is not updated.
In order to solve the issue, it seems that all validators need to update gaiad and relayer.

$ rly tx link achain_pylonchain
I[2020-03-27|17:52:37.942] ✔ [achain]@{374} - msg(0:create_client) hash(76DD51C120D07A629C2B278CA7A7A7145D096BE41E207CFC310101FBDDA64189)
I[2020-03-27|17:52:38.404] ✘ [pylonchain]@{0} - msg(0:create_client) err(sdk: tx parse error)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xf6be48]

Updated version.

$ gaiad version
0.0.0-244-g276e9b7

$ rly version
version: 0.1.0-77-g66162a7
commit: 66162a7c8b55136b7aac478034329fd07818fd07
cosmos-sdk: v0.34.4-0.20200324184639-0ed9ed648788
go: go1.14 linux/amd64

Auto Updating Headers to limit database access

auto updating lite client from chain.Subscribe("tm.event 'New Block'") which keeps a map[string]*tmclient.Header updated. This will be used to limit database access when running multiple relayers simultaneously

Concurrent design patterns

Moved from #36.

Should we recreate a light client each time we need one, to avoid locking the database, or should we alternatively find some way of persisting a light client instance without having the light client lock the database (maybe we can make all our calls using the light client API)?

Support Unordered channels

original issue: #52

// PathEnd represents the local connection identifers for a relay path
// The path is set on the chain before performing operations
type PathEnd struct {
	ChainID      string `yaml:"chain-id,omitempty" json:"chain-id,omitempty"`
	ClientID     string `yaml:"client-id,omitempty" json:"client-id,omitempty"`
	ConnectionID string `yaml:"connection-id,omitempty" json:"connection-id,omitempty"`
	ChannelID    string `yaml:"channel-id,omitempty" json:"channel-id,omitempty"`
	PortID       string `yaml:"port-id,omitempty" json:"port-id,omitempty"`
        Order        string `yaml:"order,omitempty" json:"order,omitempty"
}

This change also needs to be reflected in the configuration, validation and transactions. Likely we should default to ORDERED if the prop is not passed in

Rest server for all CLI functionality

Implement rest APIs for CLI commands (#323 )
Fix all TODOs and rework on PostRelayerListenHandler API
Add swagger docs

Keys add should just output the mnemonic

Add testDenom or Denoms to testChains

The test chains themselves should know which denoms they have

Add sanity check that link is ready to be relayed over before starting relayer

Bootstrap light clients from already-trusted chains

Let's say I've already set up a light client for chain Alpha, and chain Alpha has IBC light clients (i.e. in state) for chains Bravo and Charlie. Since I can verify state on Alpha, I should be able to pull the data (configuration, consensus state, unbonding period, etc.) from the on-chain clients to setup local clients for Bravo and Charlie - then I can relay between all three chains.

Generate chain specific keys (address-prefixes)

rly keys add $CHAINID $RLYKEY is generating cosmos prefix-accounts. It should be chain specific

Support multiple kinds of light clients

As far as I can tell, right now, the relayer just support Tendermint light clients (ICS 7).

We should update the code to deal with clients more generically, and we should be able to support loop-back clients (spec, implementation) now, and other types (e.g. GRANDPA) later.

What does it mean to support a solo machine client? Does it have to provide an HTTP API? What does Agoric think / what do they need?

Incorporate IBC application versioning into relayer

Currently we have the ibc-app-version hardcoded to ics20-1 for all messages. This needs to be changed to allow for more dynamic input.