IBC Callbacks #2025
IBC Callbacks #2025
Conversation
chipshort
force-pushed
the
ibc-callbacks
branch
2 times, most recently
from
2aed858
to
3b18e9e
Compare
chipshort
force-pushed
the
ibc-callbacks
branch
2 times, most recently
from
83c2b6a
to
ee37d1e
Compare
chipshort
force-pushed
the
ibc-callbacks
branch
from
1f0f92c
to
6aa17e2
Compare
chipshort
force-pushed
the
ibc-callbacks
branch
6 times, most recently
from
15eab52
to
5a7f6b6
Compare
| #[derive(Serialize, Deserialize, Clone, Debug, PartialEq, Eq, JsonSchema)] | ||
| pub struct IbcDestinationChainCallbackMsg { | ||
| pub packet: IbcPacket, | ||
| pub ack: IbcAcknowledgement, |
There was a problem hiding this comment.
On the destination chain, how do we know if there is an ack or not?
- What about notifications for timeouts (e.g. someone tried to send you funds but failed)?
- What about cases where a packet is received but no acknowledgement is written because the protocol never writes them?
There was a problem hiding this comment.
In general we don't know that, but I just learned that my understanding of how this works was slightly off. Here's how it actually works:
If the ack is async (using WriteAcknowledgement), then the callback is called both for successful and unsuccessful acknowledgements.
If the ack is not async (by returning from OnRecvPacket), then the callback is only called if it was successful.
I originally thought only successful acks cause a callback, so we need to change the interface here to convey whether it was successful or not.
- Regarding timeout: The destination chain does not get to know about timeouts because (AFAIK) the IBC protocol has no mechanism for that. It would require the protocol built on top to support it (by sending another packet).
- Regarding no ack: If no ack is written, no callback is received.
There was a problem hiding this comment.
The destination chain doesn't know about timeouts at all (even core ibc), so it is not possible to do a callback anyway.
If OnRecvPacket returns an unsuccessful ack, core ibc reverts the cached context, so there is no reason to make a callback since it'd be reverted anyway. The intuition is that an unsuccessful ack means that the packet couldn't be received. The knowledge that a sender has attempted and failed to make a transfer is only useful to the sender (not the destination).
However, things get more complicated with async acknowledgements. (Note that no application in ibc-go currently supports async acknowledgements.) This is because async acknowledgements are initiated by an application module, not core ibc (unlike RecvPacket). This means that the decision to revert state on unsuccessful acknowledgement is up to the application module, and thus, we perform the callback in this case.
chipshort
force-pushed
the
ibc-callbacks
branch
from
5a7f6b6
to
ff8b0f5
Compare
chipshort
force-pushed
the
ibc-callbacks
branch
from
7b98eb6
to
2ea0c1f
Compare
chipshort
force-pushed
the
ibc-callbacks
branch
from
97ea02f
to
35d1592
Compare
Co-authored-by: srdtrk <59252793+srdtrk@users.noreply.github.com>
chipshort
force-pushed
the
ibc-callbacks
branch
from
fb845d9
to
381be55
Compare
packages/vm/src/calls.rs
Outdated
| /// Max length (in bytes) of the result data from a ibc_source_chain_callback call. | ||
| pub const RESULT_IBC_SOURCE_CHAIN_CALLBACK: usize = 64 * MI; | ||
| /// Max length (in bytes) of the result data from a ibc_destination_chain_callback call. | ||
| pub const RESULT_IBC_DESTINATION_CHAIN_CALLBACK: usize = 64 * MI; |
There was a problem hiding this comment.
Independent of this PR: those are generous limits given that the Wasm contract has a memory size limit of 32 MiB. See in wasmd
// contractMemoryLimit is the memory limit of each contract execution (in MiB)
// constant value so all nodes run with the same limit.
const contractMemoryLimit = 32
Co-authored-by: Simon Warta <2603011+webmaster128@users.noreply.github.com>
closes #1938
Implements the following:
ibc-callbackscontract: a new contract that keeps track of the callbacks that were called and provides a query to get the data that was passed to the callbacks. This is used in wasmd for an e2e test.ibc_source_chain_callbackandibc_destination_chain_callback, as well as the corresponding message typesIbcCallbackRequesttype (and types it contains): Allows constructing the json format for thememofield with strong typing