#pallet-ibc how to get relayer account id?

[dzmitry-lahoda]

context

When ibc pallet calls our module.

We call cosmwasm contract.

Calls should include account of sender.

In Cosmos, as I see some account propagated by IBC module

https://github.com/cosmos/cosmos-sdk/blob/394f1b9478a8dc568d4bab079732932488b46704/client/context.go#L27

https://github.com/CosmWasm/wasmd/blob/48ef13db421b88824b02b5f236363b784edf4b71/x/wasm/ibc.go#L62

issue

there is no guidance what account we should use to pass to VM as caller.

specifically, but not limited to on_chan_open_init needs some account as being caller.

all other Module calls should all imho contain account on behalf of which IBC is calling Module.

[Wizdave97]

The on_recv_packet, on_ack_packet, and on_timeout_packet callbacks have the last parameter Signer which is the relayer account that relayed the packet, this account is there just incase contracts intend to reward the relayer for relaying the packet, nothing more.

But from the links you shared, the contractAdress should be the responsibility of cosmwasm to derive from the port id, it has nothing to do with pallet ibc.

[Wizdave97]

You can use pallet cosmwasm's account Id as the caller if you really need to have a caller for the contracts.

[dzmitry-lahoda]

please check links again. likely you missread simple go code

[dzmitry-lahoda]

i must have because we run same code as cosmos. so you say sometimes sender is singer and sometimes arbitrary pallet? why so? why we should do different? why we should do differently from reference implementation?

imho we all would be safe if bridge will try to align with cosmos reference implementation, or explain if that is not possible.

[dzmitry-lahoda]

so you want to say that while open channel calls are done by ibc, we should not use account from ibc which have done call but put contract as sender? so contract will be sender to self when it is not true neither reference implementation does that?

[Wizdave97]

The ibc messages are submitted to pallet-ibc by the relayer based on events on the counterparty chain, submission of ibc messages is permissionless so anyone can submit an ibc message, doesn't really matter, what matters is that the message is valid and has verifiable proofs.

Pallet IBC handles validating the message alongside it's proofs and allows modules to execute callbacks based on this.
In some cases modules can choose to reward the account that submitted the message, but apart from that the account that submitted the message doesn't play any significant role AFAIK.

Check the callback interfaces here, the only functions that are passed the relayer account that submitted the message is OnRecvPacket, OnAcknowledgementPacket and OnTimeoutPacket and that's what we have in our implementation.

[hussein-aitlahcen]

@dzmitry-lahoda there is no requirement for the relayer account when doing channel handshakes, as @Wizdave97 explains.

In the official std itself, the handshake messages are not embedding the relayer account when dispatching to contracts, see:

• https://docs.rs/cosmwasm-std/latest/src/cosmwasm_std/ibc.rs.html#306
• https://docs.rs/cosmwasm-std/latest/src/cosmwasm_std/ibc.rs.html#317
• https://docs.rs/cosmwasm-std/latest/src/cosmwasm_std/ibc.rs.html#369

On the other hand, packet-related operations do need the relayer, which is what the current trait already provides:

• https://docs.rs/cosmwasm-std/latest/src/cosmwasm_std/ibc.rs.html#405
• https://docs.rs/cosmwasm-std/latest/src/cosmwasm_std/ibc.rs.html#426
• https://docs.rs/cosmwasm-std/latest/src/cosmwasm_std/ibc.rs.html#459

We should be good then, right?

[hussein-aitlahcen]

One more clarification, the IBC exports from a contract don't have access to MessageInfo. This means that no sender nor funds are associated with contracts IBC callbacks.

[dzmitry-lahoda]

so what should be used as sender when calling contract VM? 00000000000000000000000000?

[hussein-aitlahcen]

The pallet account seems reasonable

[dzmitry-lahoda]

in cosmos sdk and ibc host, sender is strait from pb messages decoded (as far as I can read go code). it is not thinked up our of nothing arbitrary. in open channel init.

[dzmitry-lahoda]

Used IBC pallet as sender.