A relayer on-chain incentive scheme

[secret2830]

IRISnet is designing a scheme for the relayer incentive in GOZ. The scheme targets incentive, not race coordination. The following is a draft. Expect reviews from the cosmos community.

---

The Relayer On-Chain Incentive Scheme

Synopsis

The relayer on-chain incentive scheme can facilitate users to initiate IBC transactions by specifying a relay fee and stimulate relayers to forward IBC packets to get the corresponding rewards.

Motivation

In the currently implemented IBC protocol, the relayer incentive is conducted off-chain. While this mechanism provides more flexibility for potential service providers like exchanges and wallets, sufficient liveness and motivation may not be guaranteed.

To make incentivation more open and efficient, the on-chain incentive scheme can be adopted, which can better incentivize relayers to participate in the IBC ecosystem.

In the scheme, a user can attach an additional fee in an IBC transaction, then a relayer can forward the packet if satisfied with the fee. Once the packet is executed on the destination chain successfully, the fee will be automatically sent to the transaction signer (i.e. the relayer). In case the packet times out, a similar process can be done (a timeout packet required).

Desired Properties

· Capability with off-chain incentive schemes. If a service provider is willing to relay packets for its users for free, or wants to use an off-chain mode such as credits or platform tokens, uses will not have to set a relay fee.
· Relay fee can be flexibly set on demand by users. Applications do not impose the relay fee.

Technical Specification

Packet

A simple way to do this is to add a field named RelayFee in the application layer packet data. But for generalization and standardization, a new interface for Packet is needed. The new Packet interface is as follows:

interface Packet {
  sequence: uint64
  timeoutHeight: uint64
  sourcePort: Identifier
  sourceChannel: Identifier
  destPort: Identifier
  destChannel: Identifier
  data: bytes	
  relayFee: coins
}

At the same time, the packet commitment will need to include the relayFee field for the relay fee proof.

ICS20 Implementation

Consider the situation where the source is true.

On the sending chain, the relay fee specified by the user will be put in escrow along with the transferred amount. The relay fee has the same denom as the transferred amount. It will be assigned to the RelayFee field when creating the outgoing packet.

Upon the packet successfully executed on the destination chain, the relay fee will be minted to the relayer.

When the packet times out, the repay fee is released to the relayer forwarding the packet with a timeout proof from escrow.

Implementation for other applications

For applications other than ICS20, the ICS20 subprotocol is required to implement the above relay fee logic.

[cwgoes]

I think it is preferable to layer this on top of the core IBC protocol rather than change the Packet type itself. Do you think it could be rearchitected in that way instead? That way it's easier to change or update in the future.

[secret2830]

I think it is preferable to layer this on top of the core IBC protocol rather than change the Packet type itself. Do you think it could be rearchitected in that way instead? That way it's easier to change or update in the future.

Thanks for your review. We considered the design in the application layer instead of the IBC layer. As you said, the way it is more extensible. But knowledges of appliactions are required for relayers due to applications not implemented according to the specification. Thus we attemp to change the Packet interface slightly.

Maybe we will implement this only in ICS20 by adding a RelayFee field to the packet data rather than changing the Packet interface. Later we will consider better schemes.

[cwgoes]

Ah, what I'm proposing is not quite that, more like layering this incentive scheme in-between the core protocol and most application protocols - not making it ICS-20 specific, but rather allowing ICS-20 to be embedded in it - does that make sense?

[secret2830]

Ah, what I'm proposing is not quite that, more like layering this incentive scheme in-between the core protocol and most application protocols - not making it ICS-20 specific, but rather allowing ICS-20 to be embedded in it - does that make sense?

I get it. This is a great proposal. Is there a detailed or rough draft of the design? There is just a bit of concern. Because the incentive-related attribute(s) must be a part of the packet commitment, according to the current `Packet' interface, the attribute(s) must be placed in the packet data which means 'Payload' not including 'Header' conceptually. Maybe I prefer to consider incentive layer as a header regardless of applications.

BTW, what I meant earlier was that we want to initially implement the ICS20 incentive on Irishub in Goz and then improve it. What do you think?

[cwgoes]

I get it. This is a great proposal. Is there a detailed or rough draft of the design?

Not yet, but you could be the first!

Because the incentive-related attribute(s) must be a part of the packet commitment, according to the current `Packet' interface, the attribute(s) must be placed in the packet data which means 'Payload' not including 'Header' conceptually. Maybe I prefer to consider incentive layer as a header regardless of applications.

The attribute would be placed in the packet data, think of it like this:

type IncentivePacketData struct {
  relayFee Coins
  data []byte
}

Then the relayFee is paid to the relayer & the data is just passed on to another ICS handler.

[secret2830]

OK. I will consider the feasibility and some related details of the scheme.

[cwgoes]

Closing as this has seen no recent activity.