search

noislabs / noisd

13 stars 3 forks source link

Notes for nois #52

Open faddat opened 1 year ago

faddat commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?