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

ICS4: Receive, Acknowledge, and Timeout Packet should be structured to indicate already relayed messages #574

Open
colin-axner opened this issue May 20, 2021 · 4 comments
Labels
implementation Tracking an external implementation of the spec. tao Transport, authentication, & ordering layer.

Comments

@colin-axner
Copy link
Contributor

Currently, if N relayers relay on the same channel end, N-1 relayers will likely waste fees per packet relayed. This can be even worse if relayers attempt to retry relay attempt. Then it is N-1 * avgRetryAttempts wasted fees per packet

I am planning on adjusting the ibc-go code to indicate well known error codes for already relayed packets. This can allow retry attempts to be dropped. In the SDK, it may eventually be possible to use this mechanism to drop already relayed messages from the mempool

I'd be great if the spec could structure the receive, acknowledge, timeout packet checks in the same way to indicate the exact point at which a packet can be deemed as already relayed.

For acknowledge packet, this might be the place where the next send sequence > packet.sequence && packet commitment doesn't exist

@colin-axner
Copy link
Contributor Author

I've started work on this on ibc-go, ran into a question.

@cwgoes is it intentional that only one packet can be timed out on an ordered channel? ie if 10 packets are unreceived and one packet times out, none of the other packets can be timed out

@colin-axner
Copy link
Contributor Author

Here is the ibc-go pr. The only case unaccounted for is already timed out packets on ordered channels (since the channel closes, it is hacky to add an error code for)

@cwgoes
Copy link
Contributor

cwgoes commented May 24, 2021

@cwgoes is it intentional that only one packet can be timed out on an ordered channel? ie if 10 packets are unreceived and one packet times out, none of the other packets can be timed out

Hmm, if a packet times out which was sent after other packets? The issue is that always-increasing expiration times aren't enforced.

@colin-axner
Copy link
Contributor Author

colin-axner commented May 24, 2021

Hmm, if a packet times out which was sent after other packets?

Or a packet times out which was sent before other packets. My point is that there's an inherent restriction on ordered channels that they must not have per packet revert logic in the timeout handler since only one packet could ever be timed out. It seems to me we should make this more explicit somehow or enable all ordered packets to be potentially timed out

@mpoke mpoke changed the title Receive, Acknowledge, and Timeout Packet should be structured to indicate already relayed messages ICS4: Receive, Acknowledge, and Timeout Packet should be structured to indicate already relayed messages Mar 17, 2022
@mpoke mpoke added tao Transport, authentication, & ordering layer. implementation Tracking an external implementation of the spec. labels Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
implementation Tracking an external implementation of the spec. tao Transport, authentication, & ordering layer.
Projects
None yet
Development

No branches or pull requests

3 participants