ICS20v2 path forwarding: simplify revert in-flight changes #1110
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
receivedPacket
is the received packet on the middle hop and thesentPacket
is 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]