murisi
commented
3 months ago Agreed. The plan I'd had for resolving this was as follows:
- Make E2E tests to test that refunds for IBC shielded transactions work (for both the fungible case and the non-fungible case) when the sender chain is not the source of the IBC token
- Ideally these tests should cover the cases when the refund is caused by an acknowledgement error, timeout, or timeout on close
- Ideally these tests should be failing before applying the following intervention. This will increase confidence that the following intervention addresses the root cause of the failure you identified.
- Add handlers in the MASP VP for
PacketMsg::Ack(only when it is an error),PacketMsg::Timeout, andPacketMsg::TimeoutOnClose:- In the case where the sender chain is not the source of the IBC token, they must increase the IBC internal address PRE balance by the amount stated in the packet
- Doing this will ensure that there are enough funds in the IBC internal address for the refunding MASP
Transactionto draw from and should fix the failures that you discovered above - The final code should look similar to https://github.com/anoma/namada/blob/d2e4fd9a0b68ad6dee33134aee4a32f232296824/crates/ibc/src/lib.rs#L521-L555 once it's done, but with
!is_receiver_chain_source_strreplaced by!is_sender_chain_source_str.
- Doing this will ensure that there are enough funds in the IBC internal address for the refunding MASP
- Finally we should do some (slightly redundant) checks to ensure that the given
PacketMsg::Ack,PacketMsg::Timeout, orPacketMsg::TimeoutOnClosepacket have actually been placed in the correct IBC storage key - This should be similar to how we currently call
check_packet_receivingforPacketMsg::Recv. See also the redundancy discussion at https://github.com/anoma/namada/pull/3409#discussion_r1642646014
- In the case where the sender chain is not the source of the IBC token, they must increase the IBC internal address PRE balance by the amount stated in the packet
When transferring an IBC token back to the source chain from a shielded account, the refund failed because the MASP VP rejected it. The token from the source chain was minted in Namada. So, when transferring back to the source chain, the token is burned on the source Namada. After the IBC transfer has failed by a timeout or a receiving error, it should be refunded by minting it again in Namada.