ICS 18: Off-chain relayer algorithm

[cwgoes]

Partially a port of the original spec.

Will cover:

• Off-chain process relay algorithm
• Permissioning
• Fee payment mechanisms

[mossid]

Should we include relayer incentivization here too, or in a separated issue? Fee accumulated by the packete generator on the source chain will be paid to the relayer on the destination chain, so we need an interchain standard for that.

[cwgoes]

I'm agnostic on that for now, I guess fees are application-layer, so maybe they should be separate.

[vshvsh]

For many real world application we'll need to relay a packet through multiple points (i.e. asset chain -> hub -> DEX). Routing can be done in one of the ICS layers or absolutely off-chain (wallet software tracking all three chains and issuing transactions in time). Arguments can be made for both approaches.

[ebuchman]

Do we have an issue for routing across blockchains? I believe this issue is more for the point-to-point relay from one blockchain to another rather than the potential multi-hop, but I suppose it could be expanded for that? Will depend on chain naming #12

[cwgoes]

Do we have an issue for routing across blockchains? I believe this issue is more for the point-to-point relay from one blockchain to another rather than the potential multi-hop, but I suppose it could be expanded for that? Will depend on chain naming #12

Now we do - #65.

I don't think the algorithms that a relayer process will run actually need to change based on multi-hop routing (multi-hop routing will just define part of the pendingDatagrams function) - do you think they do in another sense? If not, I think keeping multi-hop routing a separate ICS will be cleaner.

[vshvsh]

It is definetely a separate ICS. Multi-hop routing will be complicated given that we might or might not want atomicity, latency/fee/security considerations for route choice, different allowed fee tokens for different hops etc etc.