Now hash the TransferTarget into Transaction transparent outputs.

[murisi]

Describe your changes

An attempt to address issue #3300. The approach taken is to include the IBC receiver in the pre-image of shielded Transaction outputs. More specifically, the following changes have been made:

• The target of outgoing shielded actions is the hash of the IBC receiver (plus a 1 byte tag indicating an IBC recipient)
  • For non-IBC receivers, we just prepend a 1 byte tag to the target Address indicating a non-IBC recipient
• Modified IBC transactions to use the raw integer representation of amounts rather than the human readable decimal representation. This involved:
  • Modifying the client to be able to derive the denominations of IBC tokens. This is done by essentially looking up the base token corresponding to an IBC token and finding the denomination of that
  • Making the protocol return no denomination for IBC token instead of a zero
  • This was necessary because MASP uses raw amounts, so we need to make sure that MASP-IBC computations utilize the same units
• Modifying the MASP validity predicate to check MASP transaction inputs and outputs against IBC packets. This involved:
  • Deriving the token Address that corresponds to an transfer PacketData and checking that the transparent inputs and outputs use that
  • Checking that the transparent outputs of a MASP Transaction go to the receiver stated in PacketData in the case of an outgoing shielded action
  • Checking that the transparent inputs of a MASP Transaction are the IBC internal address in the case of a refund or an incoming shielded action

Closes #3300

Indicate on which release or other PRs this topic is based on

Namada v0.37.0
Hermes 1.8.2 using this branch for the Namada SDK

Checklist before merging to draft

• I have added a changelog
• Git history is in acceptable state

[codecov]

Codecov Report

Attention: Patch coverage is 2.44565% with 359 lines in your changes missing coverage. Please review.

Project coverage is 53.74%. Comparing base (6dc1612) to head (423ee7f).
Report is 173 commits behind head on main.

Files	Patch %	Lines
crates/namada/src/ledger/native_vp/masp.rs	0.00%	268 Missing ⚠️
crates/core/src/masp.rs	0.00%	41 Missing ⚠️
crates/sdk/src/rpc.rs	0.00%	35 Missing ⚠️
crates/sdk/src/masp.rs	0.00%	9 Missing ⚠️
crates/node/src/bench_utils.rs	0.00%	3 Missing ⚠️
crates/core/src/token.rs	0.00%	1 Missing ⚠️
crates/ibc/src/actions.rs	0.00%	1 Missing ⚠️
crates/sdk/src/tx.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3320      +/-   ##
==========================================
- Coverage   53.89%   53.74%   -0.15%     
==========================================
  Files         314      314              
  Lines      105704   105919     +215     
==========================================
- Hits        56968    56931      -37     
- Misses      48736    48988     +252     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yito88]

The packet commitment from the packet has been validated in the IBC VP.
We need to check the receiver in the IBC message with that of the MASP transaction, right?
I think we make a packet commitment from the MASP transaction's receiver and the IBC message(tx_data)'s timeout values and compare it with the commitment stored in the storage.

[murisi]

Understood. I'm working on a variant of this PR where the timeout values are extracted from tx_data. I'm just a little concerned that this will cause the VP to be dependent on the transaction format instead of the state changes. Also, I haven't yet checked how this will interact with the removal of Transfer dependence changes in #3232 .

[yito88]

We don't need IBC events because the transaction has only one IBC message.
We can get the IBC transfer info by decoding the tx_data like https://github.com/anoma/namada/blob/879a3268f2edfbdd0da1c98cf0e4bbdac48f5b0d/crates/ibc/src/lib.rs#L156.