Handle IBC deposits/withdraws to/from payment addresses

[sug0]

Describe your changes

Closes #4830
Closes #4168

Allow IBC deposits into payment addresses (without generating MASP transactions), and IBC withdraws from payment addresses (to automatically get refunded, if an IBC unshielding transfer fails on the counter-party).

These changes should substantially improve the UX of MASP over IBC.

Checklist before merging

• If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
  • This will require 2 reviewers to approve the changes
• If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
  • Relevant PR if applies:
• If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
  • Relevant PR if applies: Parse MASP events from protocol shieldings namada-masp-indexer#111

[mergify]

🧪 CI Insights

Here's what we observed from your CI run for ed70e61.

🟢 All jobs passed!

But CI Insights is watching 👀

[sug0]

oops, I broke something between the last two f-pushes

[murisi]

Thanks for your work on this. The code seems okay to me. Since it's been a while since I've looked at this code, I just have one or two basic questions: This PR allows IBC deposits into payment addresses (without generating MASP transactions). Is the main benefit of doing this avoiding having to generate zero-knowledge proofs, or is it something else? Is the main change of this PR that transaction notes are submitted in a vector instead of an actual Transaction object? Or is the change more fundamental? I think I have more questions/comments, but just want to make sure that I am understanding things right.

[sug0]

Is the main benefit of doing this avoiding having to generate zero-knowledge proofs, or is it something else?

The immediate benefits I can think of are a few:

1. Avoiding generating zero-knowledge proofs when depositing via IBC
   i. This translates to less time to process the tx
2. Forgoing the need to include the generated MASP transaction in the memo field of the IBC transaction
   i. This translates to cheaper txs on the counterparty chain, and cheaper IBC relaying fees
3. Refunding failed IBC unshielding transactions back to a payment address
   i. Better UX, no need to manually shield refunds

Is the main change of this PR that transaction notes are submitted in a vector instead of an actual Transaction object?

In this PR, notes are generated by the protocol, the user doesn't submit any MASP data other than a payment address. This is possible due to the fact the submitted IBC ICS-20 packet data already has the necessary information to build a plaintext MASP note. Some of the other changes in the PR are required to figure out if an asset is part of the rewards program, emitting events for clients to pick up the notes minted by the protocol while syncing their local MASP state, etc.

[murisi]

Thanks for clarifying the context of this code. I see nothing obviously wrong or improvable with the changes to the MASP VP or the transfer context. I just wonder if we could utilize existing code and execution paths more in order to minimize risk. For instance, the transfer context has code to update the note commitment tree and the undated balances though apply_shielded_transfer does something similar. In the MASP VP, the new logic skips the anchor check execution paths when the ProtocolIbcShielding condition is met.

I guess I just wonder if there could be a single function to create a dummy transaction based off (owner_pa, token, amount, ...) (potentially having correct anchors) that can be:

• constructed (from the event) and used by clients to update their shielded state
• constructed and used by the transfer context to update undated balances and note commitment tree (somehow using the apply_shielded_transfer function)
• constructed by the MASP VP (from the event) and fed into the existing verification logic in a way that minimizes the number of checks that are disabled/the number of paths through the verification logic.

A unified dummy transaction logic would ensure that IBC transactions are synchronized, executed, and verified in the exactly same way. Overall the code is likely correct, but it would be nice to leverage existing mainnet code as much as possible to minimize risk of unexpected behaviour. Of course, this hypothetical approach might not be practical!