You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Accept this as a possibility and document for app developers to handle
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
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)
The text was updated successfully, but these errors were encountered:
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:
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)
The text was updated successfully, but these errors were encountered: