Open cwgoes opened 5 years ago
Do we care about the "multi-chain execute or rollback" case or is that out of scope?
Chain A executes state transition 1, chain B executes state transition 2, either:
Right now this would need to be done at the application layer, since A and B would have independent channels to C.
With acyclic ordering, this would be possible if a packet receive on C were dependent on a send on A and a send on B, and the timeout of that packet could rollback both A & B - I think it breaks the channel abstraction though, so perhaps not worth it for now.
Alternatively we could implement atomic co-dependencies:
x
to C which depends on y
y
to C which depends on x
x
and y
atomically or executes neitherx
or y
work to rollback on A or BWhat about that? Not too complex, and I think it does the trick...
Note that validity predicates can be used across connections so new connections are not needed.
Decided not to put this in IBC v1.
Partial cross-chain ordering is a very interesting research topic and should be planned for IBC v2!
Very cool idea here. And I definitely agree to keep this as a 2.0 feature.
Let's get the basic ordered/unordered channels implemented, and deployed and then have some real use cases where this will be a useful optimizations.
I :heart: DAG, vector clocks, and CRDTs... it would be awesome to enable some advance distributed system techniques on top of IBC.
Interchain Accounts would benefit greatly from this (it would order based on account sequences). See discussion
I think this would be a great feature to add to TAO v1.1.0
Split off from https://github.com/cosmos/ics/issues/126.
Desiderata
Implementation
(source connection || source channel || packet sequence || packet data)
Questions