Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notes for nois #52

Open
faddat opened this issue May 13, 2023 · 3 comments
Open

Notes for nois #52

faddat opened this issue May 13, 2023 · 3 comments

Comments

@faddat
Copy link

faddat commented May 13, 2023

The first thing that I want to mention is that Katarina described what's actually a fairly common issue to me. What she was saying is that relayers are finding it necessary to use multiple pieces of relay software to appropriately service the network.

She is saying that the TS relayer forgets to do client updates and then that can harm reliability, is that the go relayer is used for something? I didn't quite catch what, and that Hermes is just too slow when relaying WASM.

Thing is this is totally normal! I have been trying to observe IBC

@kaisbaccour
Copy link

we have two kinds of relaying channels to maintain.
the first is a regular ICS-20 and there we have no issues.
The second is a wasm channel and for that hermes is very slow because websocket doesnt catch the wasm events but ts-relayer is fast. only issue with ts-relayer is that sometimes it starts to have gas estimation issues and fails to update the client, this is why we need the go relayer to work along side the ts-relayer to make it fast which is not ideal (We want one software to be able to be fully independant). For more info about the IBC communication in Nois you can check this article.
The IBC stuff is defined in this repo https://github.com/noislabs/nois-
So in the repo in the contract folders, two contracts are important. the nois-proxy and the nois-gateway. Because they are the ones that the wasm channel binds to. From the Nois chain part it is the nois-gaeway, and from the consumer chain part it is the nois-proxy.
They use some custom IBC version nois-v7 which is pretty much some structs to define what the beacon data includes. and that you can find here but not as important https://github.com/noislabs/nois-contracts/tree/main/packages/nois-protocol
The reason we don't just use go-relayer is because the go-relayer has issues relaying the wasm messages for some reason.
the only success relaying wasm is whether from hermes when it clears the channel, or from ts-relayer.
ts-relayer is faster than hermes in this regard because when you ask hermes to clear the channel it takes a while to start. And starting it with clear interval seems to not do the job

@faddat
Copy link
Author

faddat commented May 13, 2023

Just reviewed your hermes configuration and I think that you should enable the connection field. You see, the TS relayer relays by connection. All of the channels on a given connection will be covered. This way you don't have to configure channels specifically.

@kaisbaccour
Copy link

Aha, so the hermes can discover all channels on a specific connection. nice because it is easier to maintain such config will change that and if it works will let Nois relayers know in case they some are not aware of that, but would this change make an difference on the actual relaying part, probably not right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants