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

Discuss how to deal with Acknowledgements for MultiPayload Packets #1158

Open
AdityaSripal opened this issue Nov 5, 2024 · 0 comments
Open

Comments

@AdityaSripal
Copy link
Member

IBC v2 is introducing the ability to allow multiple payloads in the same packet.

We want to allow atomic processing of the Receive for the multiple payloads. If any of the applications return an Ack error, then all the receive logic should be reverted and an error acknowledgement should be written.

However, there is a problem when it comes to Acknowledgement and Timeout. In these cases, an error returned by any application callback will cause the entire transaction to revert. In the single payload case, this can be ok since the single application is at fault and must recover from this situation.

In the multipayload case, a single app's failure can cause other applications to never acknowledge or timeout their packet.

Potential solutions:

  1. Accept this as a possibility and document for app developers to handle
  2. Do not revert tx on an error in OnAcknowledgement or OnTImeout packet. Instead just revert app-specific changes. This requires partial rollback of state. Perhaps we only support multipayload in these platforms
  3. Split acknowledgements and timeouts to occur on a per-payload level even if the packet included multiple payloads atomically on receive.

I'm generally in favor of option 2 as it seems the simplest to me. This does increase the platform requirements for a full implementation of IBC v2 (namely partial rollback of state changes within tx execution)

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

No branches or pull requests

1 participant