cosmos
Decide if IBC err acks are important
Problem
#542 makes it more explicit for which cases we return an IBC err ack when a slash packet is recv. However, we could simplify a lot of code if we do not return IBC err acks in any case, and always drop slash packets when there is something wrong with the data. This warrants a larger question, how much does it matter whether or not we return IBC err acks? Does this affect anything?
Should relayers be aware of the fact that they are relaying invalid packets? There are some cases that we currently silently fail slash packets for example, without a relayer being aware of such silent failures
CC @mpoke
Closing criteria
Decide if IBC err acks are important, act accordingly
Related to this, if IBC err acks are deemed to be neccessary. There are additional places we could return them when something goes wrong. Namely, VSCMatured packets could be validated upon being recv, and return an IBC err ack if there is something invalid with the vscID
Note: this would require logic and/or additional state to determine what makes a vscID invalid. There's not any sensible stateless validation we can make AFAIK
Message from @colin-axner
In ibc-go the main difference is that core IBC will revert all application state changes if an error acknowledgement is returned. Other than that, the acknowledgement should be seen as opaque. See here
Doesn't an error ack close the channel?
AFAIK, not in the IBC module. Only if we close it on the application side (i.e., in the OnAck code).
AFAIK, not in the IBC module. Only if we close it on the application side (i.e., in the OnAck cod
Let's check. I think a while ago in a WIP PR I accidentally returned an error and it automatically closed the channel.