ICS20v2 path forwarding: simplify revert in-flight changes #1110
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
crodriguezvega
requested review from
AdityaSripal,
colin-axner,
damiannolan and
sangier
as code owners
3 tasks
AdityaSripal
approved these changes
Jun 19, 2024
There was a problem hiding this comment.
Yes this is much cleaner. Thanks for the clarification @crodriguezvega !!
AdityaSripal
added a commit
that referenced
this pull request
Jun 24, 2024
* add recv logic and revert logic on error ack/timeout * multiple denoms but still support forwarding * lint * Apply suggestions from code review Co-authored-by: Carlos Rodriguez <carlos@interchain.io> * address reviews * Apply suggestions from code review Co-authored-by: Carlos Rodriguez <carlos@interchain.io> * small fixes * generate forwarding address if it doesn't exist * blank memo for now * only do revertInFlightChanges or refund packets on error ack, not both * make same changes for timeout * forwarding info struct, individual memos * fail early since forwarding must be atomic * address some small review comments * only set memo on last hop * address Stefano's and my review comments * missing bracket * destinationChannel -> destChannel * ICS20v2 path forwarding: simplify revert in-flight changes (#1110) * simplify revert in-flight changes * typo * nit: rename ForwardingInfo to Forwarding (#1112) * ICS20v2: use protobuf encoding for packet data of v2 (#1118) * ics20: use protobuf encoding for packet data of v2 * Update README.md * delete previously forwarded packet (#1119) * Update spec/app/ics-020-fungible-token-transfer/README.md Co-authored-by: Damian Nolan <damiannolan@gmail.com> * Apply suggestions from code review Co-authored-by: Cian Hatton <github.qpeyb@simplelogin.fr> Co-authored-by: Carlos Rodriguez <carlos@interchain.io> * ICS20v2: use `Denom` and `Trace` types (#1115) * nit: rename ForwardingInfo to Forwarding * use Denom and Trace types * Apply suggestions from code review Co-authored-by: Aditya <14364734+AdityaSripal@users.noreply.github.com> * comments --------- Co-authored-by: Aditya <14364734+AdityaSripal@users.noreply.github.com> * review comment --------- Co-authored-by: Carlos Rodriguez <carlos@interchain.io> Co-authored-by: Damian Nolan <damiannolan@gmail.com> Co-authored-by: Cian Hatton <github.qpeyb@simplelogin.fr>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following up on the discussion from the walkthrough, it does seem like we can simplify the logic of
revertInflightChanges(I actually had also hinted that to Aditya when I first reviewed the spec...)To make it easier for everyone to reason about this (although please double check that I haven't made any mistake), the following outlines what happens with the escrow accounts and forwarding account assuming that there is a timeout or error ack and changes on the middle hop need to be reverted. The
receivedPacketis the received packet on the middle hop and thesentPacketis the packet sent from the middle hop as a result of forwarding.Scenario 1 (source when receiving, source when sending)
transfer tokens
escrow[receivedPacket.destinationChannel]->forwarding[receivedPacket.destinationChannel]transfer tokens
forwarding[receivedPacket.destinationChannel]->escrow[sentPacket.sourceChannel]transfer tokens
escrow[sentPacket.sourceChannel]->forwarding[receivedPacket.destinationChannel]transfer tokens
forwarding[receivedPacket.destinationChannel]->escrow[receivedPacket.destinationChannel]Scenario 2 (source when receiving, not source when sending)
transfer tokens
escrow[receivedPacket.destinationChannel]->forwarding[receivedPacket.destinationChannel]burn tokens
forwarding[receivedPacket.destinationChannel]mint tokens
forwarding[receivedPacket.destinationChannel]transfer tokens
forwarding[receivedPacket.destinationChannel]->escrow[receivedPacket.destinationChannel]Scenario 3 (not source when receiving, source when sending)
mint vouchers
forwarding[receivedPacket.destinationChannel]transfer vouchers
forwarding[receivedPacket.destinationChannel]->escrow[sentPacket.sourceChannel]transfer vouchers
escrow[sentPacket.sourceChannel]->forwarding[receivedPacket.destinationChannel]burn vouchers
forwarding[receivedpacket.destinationChannel]Scenario 4 (not source when receiving, not source when sending)
mint vouchers
forwarding[receivedPacket.destinationChannel]burn vouchers
forwarding[receivedPacket.destinationChannel]mint vouchers
forwarding[receivedPacket.destinationChannel]burn vouchers
forwarding[receivedpacket.destinationChannel]