Relay asynchonous acknowledgements using the packet information emitted on the original packet send

[colin-axner]

Summary

Relay asynchronous acknowledgements using the packet information emitted on the original packet send

Problem Definition

On the destination chain, when an asynchronous acknowledgement is written, hermes also consumes the packet attribute in the event associated with the async ack. Core IBC does not need the async application to store the full packet, except to populate the packet event attribute to support this relayer behaviour. This results in the full packet being stored (including the marshaled packet data) rather than only the essential information (the packet identifier, port/channel/sequence)

If relayers begin pulling the packet information from the original packet send event, then IBC async application can reduce storage costs drastically (minimum 10x reduction). In addition, the full packet wouldn't need to be reemitted in all events for each packet processing step (as it currently is).

Proposal

When processing an async ack, using the source port/channel emitted in the async ack event, lookup the original packet send on the sending chain. Use this to complete the relay of the acknowledgement from the destination chain back to the source chain.

Acceptance Criteria

ibc-go can remove the full packet from being emitted in the async ack event, cosmos/ibc-go#5901 and ics20 v2 can be updated to reduce storage from the full packet to the packet id cosmos/ibc-go#6636

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned