ICS 18: Relayer algorithms

[cwgoes]

Closes #35.

This is a pretty minimal specification for now, since the details of pendingDatagrams will be defined in individual ICSs and I think it's too early to spend much time working out relayer fee reimbursement.

[cwgoes]

Ready for review as a draft. Specific functions for calculating valid datagrams will need to be defined in individual ICSs as mentioned. Possibly this ICS could include more detail about relayer incentivization later, but I think that design discussion would be too early now (it doesn't seem particularly difficult, and is unlikely to require low-level protocol changes).

I suggest reviewing the rendered Markdown.

[liamsi]

Clear high-level description of the relayer algorithm. To be able to implement actual relayers implementers will need to know more internals of pendingDatagrams and submitDatagram. My understanding is that these will be part of separate ICSs.

[cwgoes]

My understanding is that these will be part of separate ICSs.

Yes, that's right. I think that makes more sense because chains are likely to implement subsets of the IBC protocol - that way relayers can compose pendingDatagrams based on which ICSs the chain implements.

[melekes]

🥑

[zmanian]

Question: Do we need to creation some notion of an ID for each datagram.

The relayer algorithm would then be expected to insert any detected datagram if the id wasn't already in the mempool.

[cwgoes]

Question: Do we need to creation some notion of an ID for each datagram.

The relayer algorithm would then be expected to insert any detected datagram if the id wasn't already in the mempool.

This is expected to be included in pendingDatagrams (which can read the state of the ledger).

I think usually we will (certainly for packets), but occasionally other state will be sufficient (connection state, for example, in the connection handshake).

[milosevic]

These properties are not necessarily telling us what we expect from relayer. It's more telling us what other part don't expect from relayers.

[cwgoes]

Hmm, I suppose - these are desired properties of how we construct the relayer algorithm (e.g. permissionless - all datagrams are verified by the blockchain state machine itself). Some are a bit vague but I think still worth listing.

What properties do you think are in scope here?

[melekes]

Questions I have so far:

• do relayers programmed to use a Hub?
• if yes, how do they choose what Hub to use?
• do they first send IBC transaction to a Hub? What if a Hub detects a double spend? How it can signal the relayer that IBC transaction is malicious?

[cwgoes]

@melekes I don't think any of the current IBC specifications talk about "Hubs" yet - that's a distinction at the level of expected network dynamics (for now), not a distinction at the protocol layer.

There's some discussion in progress at #59.

[cwgoes]

Merging to the "draft" stage, further comments always welcome.