search

cosmos / ibc

Interchain Standards (ICS) for the Cosmos network & interchain ecosystem.
Other
940 stars 383 forks source link

ICS 18: Off-chain relayer algorithm #35

Closed cwgoes closed 5 years ago

cwgoes commented 5 years ago

Partially a port of the original spec.

Will cover:

mossid commented 5 years ago

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 commented 5 years ago

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

vshvsh commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 - https://github.com/cosmos/ics/issues/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 commented 5 years ago

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.