From 2a81e3f8909d6647cf244451c146bee8f07d6b49 Mon Sep 17 00:00:00 2001 From: Ethan Frey Date: Thu, 3 Jun 2021 13:13:23 +0200 Subject: [PATCH] Update ICS-4 to pass relayer/signed to modules (#579) * Update ICS-4 to pass relayer/signed to modules * Add relayer arg to timeoutOnClose --- .../README.md | 20 +++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/spec/core/ics-004-channel-and-packet-semantics/README.md b/spec/core/ics-004-channel-and-packet-semantics/README.md index 2e7b1e212..2b05b0205 100644 --- a/spec/core/ics-004-channel-and-packet-semantics/README.md +++ b/spec/core/ics-004-channel-and-packet-semantics/README.md @@ -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) @@ -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)) @@ -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): Packet { + nextSequenceRecv: Maybe, + relayer: string): Packet { channel = provableStore.get(channelPath(packet.sourcePort, packet.sourceChannel)) abortTransactionUnless(channel !== null) @@ -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): Packet { + nextSequenceRecv: Maybe, + relayer: string): Packet { channel = provableStore.get(channelPath(packet.sourcePort, packet.sourceChannel)) // note: the channel may have been closed