Add ibc support

[ethanfrey]

Closes #166

• Update to newest master with ibc types
• More CosmosMsg variants in Go types
• More QueryRequest variants in Go types
• IBC related types in Go
• 6 new IBC-related Entry Points exposed to Go
• Add ibc enabled contract Add Ibc sample contract cosmwasm#714
• Add integration tests to call ibc-enabled contract

In follow up PR #172:

• Expose "ibc enabled" when Instantiating contract (or create?) - see Add optional ibc entry point cosmwasm#692 (comment)

[alpe]

Very cool to see IBC support here! 🎸
Some minor notes on naming and types.

[ethanfrey]

Thanks for the review @alpe

I will make some of the requested changes in the data types in cosmwasm and get a new cosmwasm build out before updating the Go side. My key question before I can properly update the Rust types is this:

Okay, so Timeout height is (version, height). Timeout timestamp is in seconds (millisecond? microseconds?) since UNIX 0 ???
And only one of the two can be set per packet? Is exactly one required or is leaving both blank also valid?

[alpe]

Okay, so Timeout height is (version, height). Timeout timestamp is in seconds (millisecond? microseconds?) since UNIX 0 ???

Timestamp is the absolute timeout. // block timestamp (in nanoseconds) after which the packet times out`` it is the same type used in ConsensusState.return uint64(cs.Timestamp.UnixNano())`

And only one of the two can be set per packet? Is exactly one required or is leaving both blank also valid?

From the packet validation logic I must assume both can be set but one is required

[ethanfrey]

Changes to the ibc types made here: CosmWasm/cosmwasm@62b9fc7

Also, the ibc_enabled flag is now available.

TODO:

• rebuild dlls from Add Ibc sample contract cosmwasm#714
• rebuild contracts from Add Ibc sample contract cosmwasm#714
• Update ibc types from Add Ibc sample contract cosmwasm#714

[ethanfrey]

I will do some cleanup as mentioned before.

@alpe this should be usable for wasmd integration. You will need to copy the updated contracts over.

Note that ibc_test.go in the top level is showing how to test the contract from a high level and can be used as a starting point for wasmd integration tests.

[alpe]

Naming became a bit odd. This field and the height have the same name. This results into: msg.SendPacket.TimeoutHeight.TimeoutHeight

[ethanfrey]

Happy for better names. I copied them both from "somewhere else".

If you want to propose names for all these fields, I can PR that into cosmwasm

[alpe]

This should be type Coin. Transfer does not support multiple. See https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/ibc/applications/transfer/v1/tx.proto#L28

[ethanfrey]

Yup, I did this in Rust. Typo here. I will fix.

    Transfer {
        /// exisiting channel to send the tokens over
        channel_id: String,
        /// address on the remote chain to receive these tokens
        to_address: HumanAddr,
        /// packet data only supports one coin
        /// https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/ibc/applications/transfer/v1/transfer.proto#L11-L20
        amount: Coin,
}

[ethanfrey]

This now resolved in #172
Commit 9404357

[alpe]

ICS-20 port-id is not fix to transport. It can be configured in the genesis and may vary between chain. Although I don't expect this to happen. To fully support ICS-20 transfers we should have the PortID as a field in the message.

[ethanfrey]

To fully support ICS-20 transfers we should have the PortID as a field in the message.

Actually the opposite.
The contract cannot be expected to know the proper port (and would hardcode to transfer). The x/wasm module could read the genesis info "somehow" and then auto-fill with the canonical ICS-20 port for the chain.

At least that is my reasoning. If we could expose this info to a contract, we could just auto-fill.
Or is this info not available to x/wasm?