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.

Sign up for GitHub

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

Fix outdated description for optimistic send #1173

Merged
merged 3 commits into from
Dec 19, 2024
Merged

Fix outdated description for optimistic send #1173

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
204c1d1
fix to remove the outdated description for optimistic send
bluele Dec 4, 2024
1a167be
fix to clarify channel state for sending packet
bluele Dec 4, 2024
be6bd7d
update history in ics-004
bluele Dec 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 1 addition & 3 deletions spec/core/ics-004-channel-and-packet-semantics/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -742,7 +742,7 @@ Calling modules MUST execute application logic atomically in conjunction with ca

The IBC handler performs the following steps in order:

- Checks that the channel is not closed to send packets
- Checks that the channel is opened to send packets
- Checks that the calling module owns the sending port (see [ICS 5](../ics-005-port-allocation))
- Checks that the timeout height specified has not already passed on the destination chain
- Increments the send sequence counter associated with the channel
Expand Down Expand Up @@ -1154,8 +1154,6 @@ In the case of an unordered channel, `timeoutPacket` checks the absence of the r

If relations are enforced between timeout heights of subsequent packets, safe bulk timeouts of all packets prior to a timed-out packet can be performed. This specification omits details for now.

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.

We pass the `relayer` address just as in [Receiving packets](#receiving-packets) to allow for possible incentivization here as well.

```typescript
Expand Down
Loading