Specification changes for asynchronous acknowledgements

[cwgoes]

Per discussion with @michaelfig, ref cosmos/cosmos-sdk#7200.

At present, when a packet is received by a state machine implementing IBC, the state machine must write an "acknowledgement", an arbitrary bytestring, to a pre-specified key. This acknowledgement is used for two purposes at once:

1. It confirms that the packet has been received, so that it can no longer be timed-out on the source state machine.
2. It allows the receiving state machine to write data resulting from packet execution, e.g. success/failure, which the sending state machine can subsequently process once it verifies the acknowledgement.

Packet receipt - (1) - must be confirmed immediately, synchronously, so as to retain the correct timeout semantics. Packet processing results - (2) - could in principle be confirmed independently, asynchronously, but at the moment since the same key & value are used this must also be synchronous.

This proposal would separate these two concerns, making the following specification changes (high-level outline):

Separate keys for receipt and acknowledgement

The current acknowledgement which happens on recvPacket will turn into a simple proof-of-packet-receipt without any data, with a new key (receipt instead of acknowledgement). Timeout verification will be updated to use this key instead of the acknowledgement key.

The current store key used for acknowledgements will be retained for that purpose.

New writeAcknowledgement function

An asynchronous (can be called anytime after recvPacket) function called writeAcknowledgement will be added, which writes the acknowledgement data resulting from processing a particular packet to the store under the acknowledgement key. This data will still be used in the acknowledgePacket processing function on the source chain.

Changes to relayer logic

Timeout logic remains unchanged, but relayers must wait for acknowledgements to be written, which may happen after (e.g. not in the same transaction or block) recvPacket is called, before calling acknowledgePacket on the source chain.

Does this make sense? Am I missing anything?

[colin-axner]

It might be worth noting the semantics of ORDERED channels changes slightly right? Packet processing results can now be processed out of order on the receiving chain (only after receipt of in order packets)

[cwgoes]

It might be worth noting the semantics of ORDERED channels changes slightly right? Packet processing results can now be processed out of order on the receiving chain (only after receipt of in order packets)

Good question; this we can choose - if we want to keep a separate acknowledgement counter to ensure in-order acknowledgement processing for ordered channels, that shouldn't be difficult.

[michaelfig]

Does this make sense? Am I missing anything?

This looks good to me. Thanks for taking this on!