In the current IBC specifications, is the lack of support for optimistic packet sending intentional?
As described here, the channel state is required to be OPEN when sending a packet.
Additionally, I know that the ibc-go has decided to remove support for optimistic packet sending in this issue.
Since we allow optimistic sending of packets (i.e. sending a packet before a channel opens), we must also allow optimistic timing out of packets. With optimistic sends, the packet may be sent on a channel that eventually opens or a channel that will never open. If the channel does open after the packet has timed out, then the packet will never be received on the counterparty so we can safely timeout optimistically. If the channel never opens, then we MUST timeout optimistically so that any state changes made during the optimistic send by the application can be safely reverted.
Could you clarify whether this feature is supported and whether the current description aligns with the intended design?
Hi there,
In the current IBC specifications, is the lack of support for optimistic packet sending intentional?
As described here, the channel state is required to be OPEN when sending a packet. Additionally, I know that the ibc-go has decided to remove support for optimistic packet sending in this issue.
However, if optimistic packet sending is not supported in the ICS-004 as well, the following description about packet timeout in the document seems misleading or incorrect:
Could you clarify whether this feature is supported and whether the current description aligns with the intended design?