Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Now hash the TransferTarget into Transaction transparent outputs. #3320

Merged
merged 8 commits into from
Jul 5, 2024

Conversation

murisi
Copy link
Contributor

@murisi murisi commented May 28, 2024

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

Copy link

codecov bot commented May 28, 2024

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.

@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch 10 times, most recently from 6de0599 to dddc8aa Compare June 3, 2024 07:02
@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch from dddc8aa to 20d113b Compare June 4, 2024 14:04
@cwgoes cwgoes mentioned this pull request Jun 4, 2024
@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch 3 times, most recently from 098ffe6 to c5c615c Compare June 6, 2024 06:47
@murisi murisi marked this pull request as ready for review June 6, 2024 06:48
@murisi murisi requested review from yito88 and grarco June 6, 2024 06:49
@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch from c5c615c to 949faaa Compare June 6, 2024 07:29
@brentstone brentstone mentioned this pull request Jun 6, 2024
crates/ibc/src/context/token_transfer.rs Show resolved Hide resolved
&msg.timeout_height_on_b,
&msg.timeout_timestamp_on_b,
);
if packet_commitment != storage_commitment {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 .

crates/namada/src/ledger/native_vp/masp.rs Outdated Show resolved Hide resolved
changed_balances.decoder.insert(ibc_address_hash, ibc_address);

// Extract the IBC events
let ibc_events: BTreeSet<_> = self
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

let message = decode_message(tx_data)?;
.

@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch from 949faaa to f6a7580 Compare June 7, 2024 09:55
@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch 3 times, most recently from e713123 to e3ce9a5 Compare June 7, 2024 19:46
@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch from e3ce9a5 to 6ad0a0f Compare June 7, 2024 21:07
@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch from 6ad0a0f to abbf3b2 Compare June 8, 2024 08:23
@cwgoes cwgoes self-requested a review June 8, 2024 08:49
@murisi murisi force-pushed the murisi/masp-ibc-replay-protection branch from f77cf47 to 5547f09 Compare June 11, 2024 17:08
@murisi murisi marked this pull request as draft June 12, 2024 19:36
@brentstone brentstone merged commit 423ee7f into main Jul 5, 2024
13 of 19 checks passed
@brentstone brentstone deleted the murisi/masp-ibc-replay-protection branch July 5, 2024 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Replay Protect Shielded Actions
3 participants