Document ibc #884

ethanfrey · 2021-04-15T21:45:35Z

Closes #147

ethanfrey · 2021-04-16T10:39:35Z

Happy for a review on this. This should be a mostly complete version of the current state.

I will be adapting the error handling in on_packet_receive as part of #762 so I left TODOs to update the spec with that PR, but I would like to get the bulk reviewed first.

webmaster128

Very nice, very helpful.

I'm concerned that this valuable document will never get maintained here (as it happened so often in the past). Why do we not have such things in docs?

IBC.md

webmaster128 · 2021-04-19T08:36:52Z

IBC.md

+Note that neither `counterparty_version` nor `counterparty_endpoint` is set in
+`ibc_channel_open` for chain A. Chain B should enforce any


How is this possible with non-optional type counterparty_endpoint: IbcEndpoint?

I think it just gets "" fields. You are right, we should make this optional if it is not present, but maybe that would confused all calls but one where it is optional (I can use IbcChannelWithOptionalCounterparty maybe for this?)

We pass in the counterparty endpoint on init as well: https://github.com/CosmWasm/wasmd/blob/master/x/wasm/ibc.go#L48

I am not sure if these are set in the sdk before calling us

After digging more in the sdk code, I found that counterparty.port is set here (in ChannelOpenInit), but counterparty.channel is not set.

https://github.com/cosmos/cosmos-sdk/blob/88e03e4f4056e8614847fd6adf17ce9252b6a89b/x/ibc/core/04-channel/types/msgs.go#L41-L60

In ChannelOpenTry, the counterparty channel must be set (ignore that comment, the code shows otherwise): https://github.com/cosmos/cosmos-sdk/blob/88e03e4f4056e8614847fd6adf17ce9252b6a89b/x/ibc/core/04-channel/types/msgs.go#L131-L134

Since we collapse these 2 into one call (to limit the number of exports and duplicated code), I am not sure the best way to handle this.

Making channel optional in all IbcEndpoint would be overkill and complicate other logic. Using counterparty: IbcEndpointWithOptionalChannel for a custom type for ibc_channel_open could work, along with a comment that counterparty_version and counterparty.channel are both set or both unset.

Any other ideas?

Do we need counterparty_endpoint.port_id when counterparty_version and counterparty_version.channel is unset? If not, I think

pub counterparty_endpoint: Option<IbcEndpoint>,

would be solid.

Some protocols (like ics27 currently) try to enforce the remote port.
Few if any care about the remote channel_id

Hmm, okay. Then I don't have a great idea. In this case it starts feeling wrong to use the same type for two different calls because we don't have dynamic typing available here.

IBC.md

webmaster128 · 2021-04-19T08:55:30Z

IBC.md

+is a functioning relayer. (In the absence of a functioning relayer, it will
+never get a response).


‼️‼️‼️‼️‼️ 😄

ethanfrey · 2021-04-19T09:11:14Z

I'm concerned that this valuable document will never get maintained here (as it happened so often in the past). Why do we not have such things in docs?

Things in the docs repo are even less connected to our code than md files here.
I echo your concern about not being maintained, but it is better if it is in this repo.

My feeling is that as we hit 1.0 we will no longer have constant breaking changes and the docs will be valid for more than 1-2 months.

webmaster128 · 2021-04-19T10:31:09Z

packages/std/src/ibc.rs

+    Both {
+        timestamp_nanos: u64,
+        block: IbcTimeoutBlock,
+    },


What do you think about this? Both(u64, IbcTimeoutBlock),?

webmaster128 · 2021-04-19T10:38:26Z

packages/std/src/ibc.rs

+    pub fn in_secs(block: &BlockInfo, secs: u64) -> Self {
+        let secs = block.time + secs;
+        let nanos = secs * 1_000_000_000 + block.time_nanos;
+        IbcTimeout::TimestampNanos(nanos)
+    }


I'm not a fan of this tight coupling between the two types IbcTimeout and BlockInfo. I don't think IbcTimeout should need to know BlockInfo exists.

However, I see the point. We need some now + x constructor, which is a pain as we do not have a nanosecond precision time point type.

Could you move this logic back to the contract and we come up with a better solution later? Otherwise we risk the need for breaking changes.

I don't think IbcTimeout should need to know BlockInfo exists.

What is the problem here?
BlockInfo is a super basic primitive. This is to avoid the very typical problem (that I hit a few times) of passing in seconds into the timeout field - both u64.

I think this is the simplest and most straight-forward approach to that. I can pull this into a separate function and not a method if you want, but I would like to keep it in cosmwasm_std

A number of types and contracts depend on BlockInfo (like all the Expiration times)

What is the problem here?

The problem is we throw all of BlockInfo into IbcTimeout that does not care about the block info at all (height, chain ID) and simply needs a proper time format. The time in BlockInfo is not a great Rust type. It is designed for JSON compatibility.

I can create a better solution that as part of this PR if you want. My idea was to unblock this PR by avoiding standard library design discussions here.

A number of types and contracts depend on BlockInfo (like all the Expiration times)

No type in cosmwasm-std depends on BlockInfo other than Env.

Fine, I will move this to the contracts, but I don't see that as more than a placeholder.

Ah, I see you made the Timepoint. Thanks

ethanfrey · 2021-04-19T11:04:51Z

As I see we are left with a discussion on how to encode the optional channel for the first call, as well as where to put the helper for ibc packet timeout. Nothing else is an open question, right?

Add Timestamp type

ethanfrey · 2021-04-19T15:03:59Z

Created this as a follow-up for the one minor issue left: #888

ethanfrey added 5 commits April 15, 2021 22:56

Write overview doc, not yet entrypoints

4e5f146

Document Channel lifecycle

6401dca

Rough draft of packet lifecycle

50f09c5

More info

874f8bf

Complete docs for current state (pre-762)

0f19bc0

ethanfrey requested review from webmaster128 and alpe April 16, 2021 10:38

ethanfrey mentioned this pull request Apr 16, 2021

Add a section on encoding IBCReceive errors #885

Merged

2 tasks

webmaster128 reviewed Apr 19, 2021

View reviewed changes

ethanfrey added 4 commits April 19, 2021 11:35

Fix typos

a2b7f0a

Fix typo in IbcMsg::CloseChannel rustdoc

f99fd1b

Update IbcTimeout format for packets

f13fc2e

Update IbcTimeout usage in contracts

298a421

ethanfrey marked this pull request as ready for review April 19, 2021 10:21

webmaster128 reviewed Apr 19, 2021

View reviewed changes

Update reflect schema

e83b995

webmaster128 and others added 2 commits April 19, 2021 13:43

Create Timestamp

1242d87

Merge pull request #887 from CosmWasm/add-Timepoint

dfc584e

Add Timestamp type

webmaster128 approved these changes Apr 19, 2021

View reviewed changes

ethanfrey mentioned this pull request Apr 19, 2021

Investigate different channel types for ibc_channel_open #888

Closed

Update timeout types in the IBC.md file

61a3749

ethanfrey merged commit f0c3d6b into main Apr 19, 2021

ethanfrey deleted the document-ibc branch April 19, 2021 15:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Document ibc #884

Document ibc #884

ethanfrey commented Apr 15, 2021

ethanfrey commented Apr 16, 2021

webmaster128 left a comment •

edited

Loading

webmaster128 Apr 19, 2021

ethanfrey Apr 19, 2021

ethanfrey Apr 19, 2021

ethanfrey Apr 19, 2021

webmaster128 Apr 19, 2021

ethanfrey Apr 19, 2021

webmaster128 Apr 19, 2021

webmaster128 Apr 19, 2021

ethanfrey commented Apr 19, 2021

webmaster128 Apr 19, 2021

webmaster128 Apr 19, 2021

ethanfrey Apr 19, 2021 •

edited

Loading

ethanfrey Apr 19, 2021

webmaster128 Apr 19, 2021

ethanfrey Apr 19, 2021

ethanfrey Apr 19, 2021

ethanfrey commented Apr 19, 2021

ethanfrey commented Apr 19, 2021

		Note that neither `counterparty_version` nor `counterparty_endpoint` is set in
		`ibc_channel_open` for chain A. Chain B should enforce any

		is a functioning relayer. (In the absence of a functioning relayer, it will
		never get a response).

Document ibc #884

Document ibc #884

Conversation

ethanfrey commented Apr 15, 2021

ethanfrey commented Apr 16, 2021

webmaster128 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ethanfrey commented Apr 19, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ethanfrey Apr 19, 2021 • 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

ethanfrey commented Apr 19, 2021

ethanfrey commented Apr 19, 2021

webmaster128 left a comment •

edited

Loading

ethanfrey Apr 19, 2021 •

edited

Loading