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.

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

Update ICS-4 to pass relayer/signed to modules #579

Merged
merged 2 commits into from
Jun 3, 2021
Merged
Changes from all commits
Commits
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
20 changes: 16 additions & 4 deletions spec/core/ics-004-channel-and-packet-semantics/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -591,11 +591,14 @@ The IBC handler performs the following steps in order:
- Sets a store path to indicate that the packet has been received (unordered channels only)
- Increments the packet receive sequence associated with the channel end (ordered channels only)

We pass the address of the `relayer` that signed and submitted the packet to enable a module to optionally provide some rewards. This provides a foundation for fee payment, but can be used for other techniques as well (like calculating a leaderboard).

```typescript
function recvPacket(
packet: OpaquePacket,
proof: CommitmentProof,
proofHeight: Height): Packet {
proofHeight: Height,
relayer: string): Packet {

channel = provableStore.get(channelPath(packet.destPort, packet.destChannel))
abortTransactionUnless(channel !== null)
Expand Down Expand Up @@ -692,12 +695,15 @@ the calling module on a channel to a counterparty module on the counterparty cha

Calling modules MAY atomically execute appropriate application acknowledgement-handling logic in conjunction with calling `acknowledgePacket`.

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

```typescript
function acknowledgePacket(
packet: OpaquePacket,
acknowledgement: bytes,
proof: CommitmentProof,
proofHeight: Height): Packet {
proofHeight: Height,
relayer: string): Packet {

// abort transaction unless that channel is open, calling module owns the associated port, and the packet fields match
channel = provableStore.get(channelPath(packet.sourcePort, packet.sourceChannel))
Expand Down Expand Up @@ -787,12 +793,15 @@ 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.

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

```typescript
function timeoutPacket(
packet: OpaquePacket,
proof: CommitmentProof,
proofHeight: Height,
nextSequenceRecv: Maybe<uint64>): Packet {
nextSequenceRecv: Maybe<uint64>,
relayer: string): Packet {

channel = provableStore.get(channelPath(packet.sourcePort, packet.sourceChannel))
abortTransactionUnless(channel !== null)
Expand Down Expand Up @@ -859,13 +868,16 @@ to which an unreceived packet was addressed has been closed, so the packet will

Calling modules MAY atomically execute appropriate application timeout-handling logic in conjunction with calling `timeoutOnClose`.

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

```typescript
function timeoutOnClose(
packet: Packet,
proof: CommitmentProof,
proofClosed: CommitmentProof,
proofHeight: Height,
nextSequenceRecv: Maybe<uint64>): Packet {
nextSequenceRecv: Maybe<uint64>,
relayer: string): Packet {

channel = provableStore.get(channelPath(packet.sourcePort, packet.sourceChannel))
// note: the channel may have been closed
Expand Down