x/ibc: transfer specs #7580

fedekunze · 2020-10-16T12:09:46Z

No description provided.

…ibc-transfer-spec

x/ibc/applications/transfer/spec/01_concepts.md

Co-authored-by: colin axnér <25233464+colin-axner@users.noreply.github.com>

x/ibc/applications/transfer/spec/01_concepts.md

…s-sdk into fedekunze/ibc-transfer-spec

Co-authored-by: Christopher Goes <cwgoes@pluranimity.org>

cwgoes

ACK though I still don't quite see how the proposed relayer service would work (in a verifiable fashion).

x/ibc/applications/transfer/spec/01_concepts.md

AdityaSripal

I don't believe connecting to all chains is a workable solution for multi-hop tokens. Client-trusted IBC explorers seem like the only viable approach to me.

EDIT: See comment below, retracted

AdityaSripal · 2020-11-02T15:06:15Z

x/ibc/applications/transfer/spec/01_concepts.md

+1. `GET /ibc_transfer/v1beta1/denom_traces/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` -> `{"path": "transfer/channelToA", "base_denom": "uatom"}`
+2. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer/client_state"` -> `{"client_id": "clientA", "chain-id": "chainA", ...}`
+3. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer"` -> `{"channel_id": "channelToA", port_id": "transfer", counterparty: {"channel_id": "channelToB", port_id": "transfer"}, ...}`
+4. `GET /ibc/channel/v1beta1/channels/channelToB/ports/transfer/client_state" -> {"client_id": "clientB", "chain-id": "chainB",}`


This looks wrong, in a direct connection there would be no need to query the counterparty chainID information because we already know our own chain-id.

Suggested change

1. `GET /ibc_transfer/v1beta1/denom_traces/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` -> `{"path": "transfer/channelToA", "base_denom": "uatom"}`

2. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer/client_state"` -> `{"client_id": "clientA", "chain-id": "chainA", ...}`

3. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer"` -> `{"channel_id": "channelToA", port_id": "transfer", counterparty: {"channel_id": "channelToB", port_id": "transfer"}, ...}`

4. `GET /ibc/channel/v1beta1/channels/channelToB/ports/transfer/client_state" -> {"client_id": "clientB", "chain-id": "chainB",}`

1. `GET /ibc_transfer/v1beta1/denom_traces/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` -> `{"path": "transfer/channelToA", "base_denom": "uatom"}`

2. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer/client_state"` -> `{"client_id": "clientA", "chain-id": "chainA", ...}`

AdityaSripal · 2020-11-02T15:06:35Z

x/ibc/applications/transfer/spec/01_concepts.md

+4. Retrieve the the client identifier or chain identifier from the client state (eg: on
+   Tendermint clients) and store it locally.
+
+Using the gRPC gataway client service the steps above would be, with a given IBC token `ibc/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2`:


Suggested change

Using the gRPC gataway client service the steps above would be, with a given IBC token `ibc/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2`:

Using the gRPC gataway client service the steps above would be, with a given IBC token `ibc/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` stored on `chainB`:

AdityaSripal · 2020-11-02T15:08:59Z

x/ibc/applications/transfer/spec/01_concepts.md

+2. Query the channel with the `portID/channelID` pair, which corresponds to the first destination of the
+   token.
+3. Query the client state using the identifiers pair. Note that this query will return a `"Not
+   Found"` response if the current chain is not connected to this channel.
+4. Retrieve the the client identifier or chain identifier from the client state (eg: on
+   Tendermint clients) and store it locally.


Suggested change

2. Query the channel with the `portID/channelID` pair, which corresponds to the first destination of the

token.

3. Query the client state using the identifiers pair. Note that this query will return a `"Not

Found"` response if the current chain is not connected to this channel.

4. Retrieve the the client identifier or chain identifier from the client state (eg: on

Tendermint clients) and store it locally.

2. Query the client state associated with the `portID/channelID` channel, which corresponds to the source of the

token.

Note that this query will return a `"Not Found"` response if the current chain is not connected to this channel.

3. Retrieve the the client identifier or chain identifier from the client state (eg: on

Tendermint clients) and store it locally.

you need to perform the query using the channel counterparty to get the origin chain

AdityaSripal · 2020-11-02T15:09:34Z

x/ibc/applications/transfer/spec/01_concepts.md

+3. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer"` -> `{"channel_id": "channelToA", port_id": "transfer", counterparty: {"channel_id": "channelToB", port_id": "transfer"}, ...}`
+4. `GET /ibc/channel/v1beta1/channels/channelToB/ports/transfer/client_state" -> {"client_id": "clientB", "chain-id": "chainB",}`
+
+Then, the token transfer chain path for the `uatom` denomination would be: `chainB` -> `chainA`.


Suggested change

Then, the token transfer chain path for the `uatom` denomination would be: `chainB` -> `chainA`.

Then, the token transfer chain path for the `uatom` denomination would be: `chainA` -> `chainB`.

x/ibc/applications/transfer/spec/01_concepts.md

AdityaSripal · 2020-11-02T15:33:34Z

x/ibc/applications/transfer/spec/01_concepts.md

+For clients that want to display the source of the token, it is recommended to use the following
+alternatives for each of the following cases:
+
+#### Direct connection


Suggested change

#### Direct connection

#### Single Channel Hop

Connection is a name-clash with IBC connection which is separate

AdityaSripal · 2020-11-02T15:37:08Z

x/ibc/applications/transfer/spec/01_concepts.md

+- **Relayer as a Service (RaaS)**: A longer term solution is to use/create a relayer service that
+  could map the denomination trace to the chain path timeline for each token (i.e `origin chain ->
+  chain #1 -> ... -> chain #(n-1) -> final chain`). Clients would be advised to connect to public
+  relayers that support the largest number of connections between chains in the ecosystem. Unfortunately, none of the existing public relayers (in [Golang](https://github.com/cosmos/relayer) and [Rust](https://github.com/informalsystems/ibc-rs)), provide this service to clients.


This isn't necessarily a relayer function (though relayers could also provide this service). This really is describing an IBC explorer which is a separate thing from a relayer service.

Suggested change

- **Relayer as a Service (RaaS)**: A longer term solution is to use/create a relayer service that

could map the denomination trace to the chain path timeline for each token (i.e `origin chain ->

chain #1 -> ... -> chain #(n-1) -> final chain`). Clients would be advised to connect to public

relayers that support the largest number of connections between chains in the ecosystem. Unfortunately, none of the existing public relayers (in [Golang](https://github.com/cosmos/relayer) and [Rust](https://github.com/informalsystems/ibc-rs)), provide this service to clients.

- **IBC Explorer**: Another solution is to use/create an IBC explorer service that maps the locally used channel and client identifiers used by each chain to the global identifiers (chain-id) that they correspond to. A client can then take a given denomination trace and iteratively query each channel identifier against the chain that uses that identifier in the token's timeline. This prevents clients from having to establish connections to every chain in the timeline, but it does introduce a trusted party in the IBC explorer.

Given the existence of an IBC explorer service. A client psuedo algorithm may look like this:

1. Retrieve the denomination trace of the token => `transfer/channelC/transfer/channelB/transfer/channelA` on the current chain `chainD`.

2. Retrieve the immediately preceding blockchain `chainC` in the timeline by querying the explorer against our current `chainD` with the first channel-id `channelC` in the trace.

3. Use the resulting `chainC` to query for the prior blockchain in the timeline by querying the explorer for the blockchain corresponding to `channelB` on `chainC`.

4. Use the resulting `chainB` to query for the prior blockchain in the timeline by querying the explorer for the blockchain corresponding to `channelA` on `chainB`.

This will provide a full history of the token: `chainA (source location)` -> `chainB` -> `chainC` -> `chainD (current location)`

**Important Note**: The only thing that is provable from `chainD` is the token trace which is a list of the local channel- and port-identifiers the token passed through from source to the current location. From this information, the chain-id of the immediate predecessor is also provable as shown in the `Single channel hop` example. IBC explorers must be trusted by clients to provide the correct chain history given a list of local channel identifiers. Since this is a relaxation of the security model of the core IBC spec, any chain history provided by an IBC explorer must be explicitly understood and displayed as coming from a (potentially) untrustworthy IBC explorer so that end users may decide whether or not to trust that information.

An implementation of an IBC explorer does not currently exist, though they may become an important part of the ecosystem as multi-chain token histories become more common.

x/ibc/applications/transfer/spec/01_concepts.md

AdityaSripal · 2020-11-02T15:41:00Z

x/ibc/applications/transfer/spec/01_concepts.md

+The only viable alternative for clients (at the time of writing) to tokens with multiple connection hops, is to connect to all chains directly and perform relevant queries to each of them in the sequence.
+:::
+
+## Locked Funds


In addition to this, we should also mention that to retrieve a token in its original form, the token must be sent back along the exact route that it took originally. Sending a token back to the same chain across a different channel will not move the token back across its timeline. If a channel in the chain history closes before the token can be sent back across that channel, then the token will not be returnable to its original form.

This is a really important point and something user interfaces should help with

AdityaSripal · 2020-11-02T16:01:15Z

Misunderstood the Connecting to All Chains solution. Going to resolve all irrelevant commments

x/ibc/applications/transfer/spec/01_concepts.md

AdityaSripal · 2020-11-02T16:15:16Z

One very important thing to note in the context of transfer security is that chain-ids (or denominations) are not globally unique. I can very easily create my own blockchain called cosmos-hub with my own tokens uatom and send them around with IBC and the token history will show that these uatom tokens originated from a cosmos-hub blockchain. From a user standpoint, this is very easily confusable with the real cosmos-hub and real uatom and in my opinion is the easiest attack vector in ibc-transfer at the moment.

This is IBC working exactly as intended, but leaves users vulnerable to potentially catastrophic mistakes imo. Perhaps the IBC team should suggest a way to mitigate this potential attack as well in this doc.

jackzampolin · 2020-11-02T20:53:06Z

x/ibc/applications/transfer/spec/01_concepts.md

+1. `GET /ibc_transfer/v1beta1/denom_traces/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` -> `{"path": "transfer/channelToA", "base_denom": "uatom"}`
+2. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer/client_state"` -> `{"client_id": "clientA", "chain-id": "chainA", ...}`
+3. `GET /ibc/channel/v1beta1/channels/channelToA/ports/transfer"` -> `{"channel_id": "channelToA", port_id": "transfer", counterparty: {"channel_id": "channelToB", port_id": "transfer"}, ...}`
+4. `GET /ibc/channel/v1beta1/channels/channelToB/ports/transfer/client_state" -> {"client_id": "clientB", "chain-id": "chainB", ...}`


We should add a route that does this instead of pushing this work on to clients

jackzampolin · 2020-11-02T20:55:15Z

x/ibc/applications/transfer/spec/01_concepts.md

+  Additionally, client would be advised in the future to use RaaS that support the largest number of
+  connections between chains in the ecosystem. Unfortunately, none of the existing public relayers


I think adding support for this in the upcoming relayer rest interface would be doable.

jackzampolin · 2020-11-02T20:56:48Z

x/ibc/applications/transfer/spec/01_concepts.md

+The only viable alternative for clients (at the time of writing) to tokens with multiple connection hops, is to connect to all chains directly and perform relevant queries to each of them in the sequence.
+:::
+
+## Locked Funds


This is a really important point and something user interfaces should help with

jackzampolin · 2020-11-02T20:59:26Z

x/ibc/applications/transfer/spec/06_metrics.md

+| `tx_msg_ibc_transfer`           | The total amount of tokens transferred via IBC in a `MsgTransfer` (source or sink chain)  | token           | gauge   |
+| `ibc_transfer_packet_receive`   | The total amount of tokens received in a `FungibleTokenPacketData` (source or sink chain) | token           | gauge   |
+| `ibc_transfer_send`             | Total number of IBC transfers sent from a chain (source or sink)                          | transfer        | counter |
+| `ibc_transfer_receive`          | Total number of IBC transfers received to a chain (source or sink)                        | transfer        | counter |


Tagged with src/dst chan/port and other metadata I would assume?

okwme · 2020-11-03T09:59:58Z

Relevant to this topic is ongoing conversation at the Chain Agnostic Improvement Proposal repo:
ChainAgnostic/CAIPs#27

fedekunze · 2020-11-03T10:49:04Z

I agree with @jackzampolin that we should create a route that allows clients to get the client and chain data from a given IBC denomination. Although it is out-of-scope for this spec and should be done in a separate PR.

addressed

x/ibc: transfer specs

a553c2e

fedekunze added the x/ibc label Oct 16, 2020

update titles and list todos

565a73f

fedekunze added spec backport/0.40.x (Stargate) labels Oct 16, 2020

fedekunze and others added 6 commits October 27, 2020 14:13

Merge branch 'master' of github.com:cosmos/cosmos-sdk into fedekunze/…

bac8d80

…ibc-transfer-spec

denom trace and client UX

2b4720e

Merge branch 'master' into fedekunze/ibc-transfer-spec

45566dc

add UX recommendations and locked funds section

14a7f1f

metrics

727197b

state transitions

df7af68

fedekunze marked this pull request as ready for review October 29, 2020 14:06

fedekunze requested review from aaronc, alessio and alexanderbez as code owners October 29, 2020 14:06

fedekunze requested review from colin-axner, AdityaSripal, anilcse, blushi, cwgoes and amaury1093 October 29, 2020 14:07

fedekunze commented Oct 29, 2020

View reviewed changes

x/ibc/applications/transfer/spec/01_concepts.md Outdated Show resolved Hide resolved

fedekunze requested review from jackzampolin and zmanian October 29, 2020 14:28

zmanian reviewed Oct 29, 2020

View reviewed changes

x/ibc/applications/transfer/spec/01_concepts.md Show resolved Hide resolved

colin-axner reviewed Oct 29, 2020

View reviewed changes

fedekunze and others added 3 commits October 29, 2020 17:16

Apply suggestions from code review

8d1edf4

Co-authored-by: colin axnér <25233464+colin-axner@users.noreply.github.com>

address comments from review

abdc4ed

conflicts

e66a6c9

jackzampolin reviewed Oct 29, 2020

View reviewed changes

x/ibc/applications/transfer/spec/01_concepts.md Outdated Show resolved Hide resolved

fix

334f37f

fedekunze requested review from zmanian, colin-axner and jackzampolin October 29, 2020 17:55

fedekunze mentioned this pull request Oct 30, 2020

Extend CAIP 19 to account for assets moved off of their native chain? ChainAgnostic/CAIPs#27

Open

cwgoes reviewed Oct 30, 2020

View reviewed changes

fedekunze and others added 5 commits November 2, 2020 11:46

Merge branch 'master' into fedekunze/ibc-transfer-spec

7d30b74

address comments from call with @zakimanian

d74ca2a

Merge branch 'fedekunze/ibc-transfer-spec' of github.com:cosmos/cosmo…

dd67f1f

…s-sdk into fedekunze/ibc-transfer-spec

Update x/ibc/applications/transfer/spec/01_concepts.md

2a3e677

Co-authored-by: Christopher Goes <cwgoes@pluranimity.org>

Merge branch 'master' into fedekunze/ibc-transfer-spec

eb70a25

cwgoes approved these changes Nov 2, 2020

View reviewed changes

x/ibc/applications/transfer/spec/01_concepts.md Show resolved Hide resolved

add comment about verification

a349a93

AdityaSripal previously requested changes Nov 2, 2020

View reviewed changes

AdityaSripal reviewed Nov 2, 2020

View reviewed changes

x/ibc/applications/transfer/spec/01_concepts.md Show resolved Hide resolved

jackzampolin approved these changes Nov 2, 2020

View reviewed changes

address comments from review

2b8fb82

zmanian approved these changes Nov 4, 2020

View reviewed changes

fedekunze requested a review from AdityaSripal November 4, 2020 15:50

fedekunze added 2 commits November 4, 2020 16:50

Merge branch 'master' into fedekunze/ibc-transfer-spec

742d728

Merge branch 'master' into fedekunze/ibc-transfer-spec

20efdf8

fedekunze added the A:automerge Automatically merge PR once all prerequisites pass. label Nov 9, 2020

mergify bot merged commit f294db9 into master Nov 9, 2020

mergify bot deleted the fedekunze/ibc-transfer-spec branch November 9, 2020 08:49

clevinson mentioned this pull request Dec 7, 2020

Stargate RC5 Tracking Issue #8104

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

x/ibc: transfer specs #7580

x/ibc: transfer specs #7580

fedekunze commented Oct 16, 2020

cwgoes left a comment

AdityaSripal left a comment •

edited

Loading

AdityaSripal Nov 2, 2020

AdityaSripal Nov 2, 2020

AdityaSripal Nov 2, 2020

fedekunze Nov 4, 2020

AdityaSripal Nov 2, 2020

AdityaSripal Nov 2, 2020

AdityaSripal Nov 2, 2020 •

edited

Loading

AdityaSripal Nov 2, 2020

jackzampolin Nov 2, 2020

AdityaSripal commented Nov 2, 2020

AdityaSripal commented Nov 2, 2020

jackzampolin Nov 2, 2020

jackzampolin Nov 2, 2020

jackzampolin Nov 2, 2020

jackzampolin Nov 2, 2020

okwme commented Nov 3, 2020

fedekunze commented Nov 3, 2020

	Using the gRPC gataway client service the steps above would be, with a given IBC token `ibc/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2`:
	Using the gRPC gataway client service the steps above would be, with a given IBC token `ibc/7F1D3FCF4AE79E1554D670D1AD949A9BA4E4A3C76C63093E17E446A46061A7A2` stored on `chainB`:

	Then, the token transfer chain path for the `uatom` denomination would be: `chainB` -> `chainA`.
	Then, the token transfer chain path for the `uatom` denomination would be: `chainA` -> `chainB`.

-- **Relayer as a Service (RaaS)**: A longer term solution is to use/create a relayer service that
-  could map the denomination trace to the chain path timeline for each token (i.e `origin chain ->
-  chain #1 -> ... -> chain #(n-1) -> final chain`). Clients would be advised to connect to public
-  relayers that support the largest number of connections between chains in the ecosystem. Unfortunately, none of the existing public relayers (in [Golang](https://github.com/cosmos/relayer) and [Rust](https://github.com/informalsystems/ibc-rs)), provide this service to clients.
+- **IBC Explorer**: Another solution is to use/create an IBC explorer service that maps the locally used channel and client identifiers used by each chain to the global identifiers (chain-id) that they correspond to. A client can then take a given denomination trace and iteratively query each channel identifier against the chain that uses that identifier in the token's timeline. This prevents clients from having to establish connections to every chain in the timeline, but it does introduce a trusted party in the IBC explorer.
+Given the existence of an IBC explorer service. A client psuedo algorithm may look like this:
+. Retrieve the denomination trace of the token => `transfer/channelC/transfer/channelB/transfer/channelA` on the current chain `chainD`.
+. Retrieve the immediately preceding blockchain `chainC` in the timeline by querying the explorer against our current `chainD` with the first channel-id `channelC` in the trace.
+. Use the resulting `chainC` to query for the prior blockchain in the timeline by querying the explorer for the blockchain corresponding to `channelB` on `chainC`.
+. Use the resulting `chainB` to query for the prior blockchain in the timeline by querying the explorer for the blockchain corresponding to `channelA` on `chainB`.
+This will provide a full history of the token: `chainA (source location)` -> `chainB` -> `chainC` -> `chainD (current location)`
+**Important Note**: The only thing that is provable from `chainD` is the token trace which is a list of the local channel- and port-identifiers the token passed through from source to the current location. From this information, the chain-id of the immediate predecessor is also provable as shown in the `Single channel hop` example. IBC explorers must be trusted by clients to provide the correct chain history given a list of local channel identifiers. Since this is a relaxation of the security model of the core IBC spec, any chain history provided by an IBC explorer must be explicitly understood and displayed as coming from a (potentially) untrustworthy IBC explorer so that end users may decide whether or not to trust that information.
+An implementation of an IBC explorer does not currently exist, though they may become an important part of the ecosystem as multi-chain token histories become more common.

		Additionally, client would be advised in the future to use RaaS that support the largest number of
		connections between chains in the ecosystem. Unfortunately, none of the existing public relayers

x/ibc: transfer specs #7580

x/ibc: transfer specs #7580

Conversation

fedekunze commented Oct 16, 2020

cwgoes left a comment

Choose a reason for hiding this comment

AdityaSripal left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdityaSripal Nov 2, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdityaSripal commented Nov 2, 2020

AdityaSripal commented Nov 2, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

okwme commented Nov 3, 2020

fedekunze commented Nov 3, 2020

AdityaSripal left a comment •

edited

Loading

AdityaSripal Nov 2, 2020 •

edited

Loading