Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICS 18: Relayer algorithms #37

Open
wants to merge 11 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@cwgoes
Copy link
Collaborator

cwgoes commented Mar 7, 2019

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 cwgoes added ready-for-review and removed wip labels Mar 30, 2019

@cwgoes

This comment has been minimized.

Copy link
Collaborator Author

cwgoes commented Mar 30, 2019

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.

@cwgoes cwgoes marked this pull request as ready for review Mar 30, 2019

@cwgoes cwgoes requested review from ebuchman, Liamsi and mossid Mar 30, 2019

@cwgoes cwgoes added the stage-draft label Mar 30, 2019

@Liamsi

Liamsi approved these changes Mar 31, 2019

Copy link
Member

Liamsi left a comment

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.

Update spec/ics-18-relayer-algorithms/README.md
Co-Authored-By: cwgoes <cwgoes@pluranimity.org>
@cwgoes

This comment has been minimized.

Copy link
Collaborator Author

cwgoes commented Mar 31, 2019

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.

Show resolved Hide resolved spec/ics-18-relayer-algorithms/README.md Outdated
Show resolved Hide resolved spec/ics-18-relayer-algorithms/README.md Outdated
@melekes
Copy link

melekes left a comment

🥑

@zmanian

This comment has been minimized.

Copy link
Member

zmanian commented Apr 15, 2019

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

This comment has been minimized.

Copy link
Collaborator Author

cwgoes commented Apr 15, 2019

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).


### Motivation

In the IBC protocol, a blockchain can only record the *intention* to send particular data to another chain. Physical datagram relay must be performed by off-chain infrastructure. This standard defines the concept of a *relayer* algorithm, executable by an off-chain process with the ability to query chain state, to perform this relay.

This comment has been minimized.

Copy link
@milosevic

milosevic Apr 16, 2019

Should we add short explanation why sending of datagrams must happen by off chain infrastructure?


### Desired Properties

- No safety properties of IBC should depend on relayer behavor (assume Byzantine relayers).

This comment has been minimized.

Copy link
@milosevic

milosevic Apr 16, 2019

behavor -> behaviour


A *relayer* is an off-chain process with the ability to read the state of and submit transactions to some set of ledgers utilizing the IBC protocol.

### Desired Properties

This comment has been minimized.

Copy link
@milosevic

milosevic Apr 16, 2019

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.


`pendingDatagrams` calculates the set of all valid datagrams to be relayed from one chain to another based on the state of both chains. Subcomponents of this function are defined in individual ICSs. The relayer must possess prior knowledge of what subset of the IBC protocol is implemented by the blockchains in the set for which they are relaying (e.g. by reading the source code).

`submitDatagram` is a procedure defined per-chain (submitting a transaction of some sort).

This comment has been minimized.

Copy link
@milosevic

milosevic Apr 16, 2019

Can we imagine relayers organised in some kind of network so not all relayer processes have access to all chains?If yes, I guess that this is outside the IBC scope?

@melekes

This comment has been minimized.

Copy link

melekes commented Apr 18, 2019

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?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.