Hi all
When I was building out the IBC monitoring on Namadata I noticed that tx’s around acknowledge_receipt messages and update_client are duplicated.
For instance with each IBC tx there’s 5-7 update client msg’s.
example block
As the number of relayers grow and the IBC tx traffic increases this is going to put a lot of cost on the relayers and make IBC inefficient.
I had a bit of a look at why its different to Cosmos - in the Cosmos SDK code, there’s a check on the updateClient function where it checks if the header is less than or equal to the current clientState height, if it’s less it returns an error - so this makes it so that only the first updateClient message succeeds each block - not sure if suitable for Namada, but it could be a way to get relaying costs down.
The acknowledge receipt is probably a similar method but with only the first for the packet.
Might be worth looking at a fix in a future upgrade to keep costs down for relayers and future proof IBC from an efficiency perspective.
4 Likes
Thank you for the report!
As the number of relayers grow and the IBC tx traffic increases this is going to put a lot of cost on the relayers and make IBC inefficient.
Could you tell me what “cost” you are concerned about?
so this makes it so that only the first updateClient message succeeds each block
Only one of them would update the state, and other transactions would succeed without errors, too. But they should do nothing (not change the state at all).
1 Like
Absolutely - so NAM gas as well as state bloat.
We’re at 5-14 tx per relay on Namada right now.
I’m not sure I fully follow point 2 - if tx are processed in an order - with the check, all the subsequent update_client tx wouldn’t be valid, since last update height = current.
I think the issue is that all transactions with the same message, except for the first one, are wasted.
Hermes submits a transaction immediately when a corresponding event is caught. It means that almost all relayers submit the same transactions at the same time. That’s why almost all transactions didn’t change the state. They were not needed as a result but were submitted.
As you said, the subsequent update_client transactions do nothing.
Even if Namada rejects these transactions, these transactions have already been submitted, and relayers have already paid the fees. So, it won’t be resolved if the transaction returns an error.
It might be helpful for each relayer to check events by configuring the event_source parameter with each different longer delay or increasing the delay longer than clear_interval, though the relay response might be worse.