Setup IBC #697
Comments
|
Something is likely going wrong with the commands that configure the light clients (ie. the I see that the script adds secondary peers for each node using the same network address, is that intended? Could you remove the |
|
Yes, you are right, that network address is wrong. Now, the error changed and is the following: |
|
Can you post your full |
|
If you mean the |
Yes it's what I meant, sorry about that! Your config looks good to me. The light client is throwing this error when verifying the initial trusted lightblock, and gets a mismatch between the hash of validator set stored in the header and the hash of the validator set for that height that it computes. I am not sure what could cause that. Maybe a mismatch in the Tendermint version that the nodes are running vs the version supported by tendermint-rs? Can you tell me what version of Tendermint the nodes are running? |
|
No worries @romac! I can give you the output of |
|
The Tendermint version looks good. We are going to try to reproduce the issue on our side and get back to you. /cc @andynog |
|
Hi @Fraccaman, just following up on this. For the stargate chain, is this a local chain you're running or are you testing against a testnet ? |
|
One node is running stargate mainnet, the other a local chain. |
|
When you say your node is running on Stargate mainnet, are you referring to cosmoshub-4 ? Can you please send what you get if you run this API query https://localhost:26657/status Just want to ensure we're talking about the same thing :-) |
|
Sorry for the late response, here is the result: {
"jsonrpc": "2.0",
"id": -1,
"result": {
"node_info": {
"protocol_version": {
"p2p": "8",
"block": "11",
"app": "0"
},
"id": "3ed8666e8e7fe0ae4dac31014841c1828d240cc9",
"listen_addr": "tcp://0.0.0.0:26656",
"network": "cosmoshub-4",
"version": "",
"channels": "40202122233038606100",
"moniker": "heliax-1",
"other": {
"tx_index": "on",
"rpc_address": "tcp://127.0.0.1:26657"
}
},
"sync_info": {
"latest_block_hash": "E1B2EE22FF1B025DA902FA6B732D09BBCF7DBF8B2E406A7D65A26BED8D499CAF",
"latest_app_hash": "A99F8C091DD628CA595098368BC57EC69E42EFC1CAAC9D66FA26929756430DD1",
"latest_block_height": "5201056",
"latest_block_time": "2021-02-18T13:08:36.985091499Z",
"earliest_block_hash": "1455A0C15AC49BB506992EC85A3CD4D32367E53A087689815E01A524231C3ADF",
"earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
"earliest_block_height": "5200791",
"earliest_block_time": "2019-12-11T16:11:34Z",
"catching_up": true
},
"validator_info": {
"address": "84B23508421F2B0C20F1C09308D25F0F6E8AEB41",
"pub_key": {
"type": "tendermint/PubKeyEd25519",
"value": "Abh8gRTD4ZEu5ytdlb+OSkrX7DiRt8vtiPvCLUuQjOY="
},
"voting_power": "0"
}
}
} |
|
Related to informalsystems/tendermint-rs#831 |
|
Hi @Fraccaman, we believe this bug is fixed now. We did encounter a bug and fixed in master. We could reproduce it last week and made modifications in informalsystems/tendermint-rs#831 Please let us know if this is fixed now so we can close the ticket. Thanks! |
|
Ill try again asap and report back! Thanks! :) |
|
Thanks @Fraccaman please keep us posted. 👍 |
|
So, I tried again (same setup). Now I get the following error: {"status":"error","result":"chain runtime/handle error: Light client instance error for rpc address tcp://localhost:26657: invalid light block: not withing trusting period: expires_at=2021-03-04T15:47:08.9667102Z now=2021-04-07T15:16:02.429079517Z"} |
Hi @Fraccaman, you might need to update your light client (primary and witness) if you haven't done so. It's the same command to add so run again. This will update the trusted header and height |
|
I started from a new machine, so I don't think I needed to update the trusted headers. {"status":"error","result":"chain runtime/handle error: Light client instance error for rpc address tcp://localhost:26657: I/O error: fetched validator set is invalid: proposer with address 'C2356622B495725961B5B201A382DD57CD3305EC' not found in validator set"} |
That's strange is this setup a clean one? |
|
Yes, clean setup, same set of scripts. |
|
OK, I might have to try to reproduce that error again. But there's a few changes related to light configuration in the next release (should be coming out soon), so I'd rather test when the new release is out.
@romac any ideas on what might cause this error ? |
|
This error happens when the light client fetches the header and the validator set at height H from the chain, where the latter does not contain a validator whose address matches the Fetching the header and validator set: Building the validator set: Ensuring there is a validator in the set with a matching address: |
|
What version of hermes? I think this may come from the pagination issue in tendermint rpc (where we were getting an incomplete validator set) that was fixed and picked up in hermes |
Oh right, that's probably it! This was fixed in tendermint v0.19.0 and will therefore indeed be fixed in Hermes v0.2.0. |
|
@andynog @Fraccaman Can you try with Hermes |
|
Im still using 0.1.1 so maybe thats the problem! Yep, I will give it a try! |
|
Okay, I had some bugs in the hermes config. Ill keep you posted. |
|
More updates. I have been able to create a client between the 2 chains 🎉🎉🎉 Following the tutorial, I'm trying to create a connection and this one is failing. Second command ( I think it ran successfully, but I need to increase the rpc timeout. Do you have any suggestions? P.s: every command dealing with cosmoshub-4 chain "fails" with the same timeout error. |
|
I made a little progress but I'm still stuck at the same "step". I avoided the timeout error by setting in gaia You can see the transactions here. |
|
@andynog @ancazamfir any suggestion? |
|
Hi @Fraccaman, @ancazamfir and others in the team are looking at this. However, would you be interested in jumping on a call with one of us for quicker troubleshooting? You can reach me for instance and would be glad to fix it together. In the meantime, some suggestions:
|
|
Hi @adizere, yes, sounds good! We can catch up on slack :)
|
|
Some pointers after @romac and I debugged together with @Fraccaman
later edit: the simulation error is below
Note that this error has the same status "InvalidArgument" as the error we obtain when txs are split across multiple batches. In this case, the second batch (and third, fourth, etc.) fails due to missing client updates:
|
|
hello friends, maybe someone knows what this problem is and how to deal with it. Reason: Hermes health check failed while verifying the application compatibility for chain osmosis-1:http://localhost:9120/; caused by: SDK module at version '0.46.0' does not meet compatibility requirements >=0.41, <0.46 |
|
Hey, The warning appears because we didn't update the compatibility check yet (SDK releases went through several back-and-forth and we waited to stabilize). If you notice problems relaying on Osmosis-1, please let us know, we'd be glad to help! |
|
Hello, I have a problem, I need to install a relayer and join an existing cosmos - osmosis channel, I made a configuration, checked it hermes query channel end --chain osmosis-1 --port transfer --channel channel-0 hermes query channel end --chain cosmoshub-4 --port transfer --channel channel-141 Then I started I started the hermes servicer. After a while such errors Sep 26 21:18:09 dedic-cyberG hermes[3669236]: 2022-09-26T19:18:09.358083Z INFO ThreadId(01) spawned client worker: client::cosmoshub-4->osmosis-1:07-tendermint-1532 what could be the problem? |
|
Can you please paste your config here so we can take a look? |
|
Can you also check what the pruning parameters are set to in the Tendermint config? Pruning should be disabled for Hermes to successfully retrieve consensus states from the past. |
|
[global] [[chains]] [[chains]] |
|
root@dedic ~/.hermes # hermes version |
|
I have such assignments in both nodes #default: only the last 100,000 states (approximately 1 week worth of states) are kept; pruning at 100 block intervals |
|
What happens if you do? $ hermes query client state --chain osmosis-1 --client 07-tendermint-1431 |
|
I don't know, but I want to understand how it works it seems to me that this is information about the created client I need to join the already created channel, if you tell me the sequence of actions, I will be very grateful to you |
Let's continue this discussion on Discord. I can be more responsive there. My colleagues will also followup by providing a tutorial on how to join created channels. |
|
Hi, there. |
Crate
Version
v0.5.0
Summary
Hermes fails with
TxNoConfirmationerror constantly when trying to communicate with a full node that does not have indexing enabled.The error can be tracked down using a patched version of Hermes, and looks like this:
Many thanks to @Fraccaman for helping us uncover this corner-case.
A separate, related problem was due to misconfiguration (see heliaxdev/ibc-setup#1).
Acceptance criteria:
TxNoConfirmation)Original discussion
Summary of Bug
Probably this is not a bug, but I can't understand whats wrong. I'm trying to open a channel between a cosmos mainnet node and a "own gaia testnet" node. I am able to build the relayer and configure it correctly (It doesn't complain so I'm assuming it is correct) but as soon as I try to run
hermes channel handshake id-1 id-2 transfer transferit throw the following error:{"status":"error","result":"chain runtime/handle error: Light client supervisor error for chain id heliax: empty witness list"}.p.s: @andynog suggested to open an issue
Version
Steps to Reproduce
I have created a repository with a series of bash scripts to reproduce this use case here.
For Admin Use
The text was updated successfully, but these errors were encountered: