Unsigned MASP Changes in SDK

[grarco]

Describe your changes

Closes #3425.

Modifies the Changes type in the SDK to wrap U128Sum instead of I128Sum since changes are guaranteed to be non-negative. Also adjusts from_masp_denominated_i128 and swap the calls to from_nonnegative for from_pair.

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

[codecov]

Codecov Report

Attention: Patch coverage is 63.63636% with 16 lines in your changes missing coverage. Please review.

Project coverage is 72.47%. Comparing base (6d1b9da) to head (6364873).
Report is 188 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/shielded_token/src/masp/shielded_wallet.rs	54.28%	16 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3716   +/-   ##
=======================================
  Coverage   72.47%   72.47%           
=======================================
  Files         338      338           
  Lines      104130   104128    -2     
=======================================
- Hits        75470    75469    -1     
+ Misses      28660    28659    -1     

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

[murisi]

Probably these changes are okay for the most part. The MASP crate uses I128Sums to represent value balances because we needed a signed type that can holds sums and differences of u64s without overflowing or underflowing. Given this, while I understand that it is conceptually clearer to hold unsigned amounts in U128Sums. It seems to me that this comes at the cost of introducing another integer type U128Sum and sometimes having to do fallible conversions from U128Sums to I128Sums for interoperability with the MASP crate. I guess this is fine if we understand that due to the fallible runtime conversions, the U128Sums (just like the I128Sums that they are replacing) can really only hold U127Sums.

[murisi]

Given that this error would be triggered by a failed conversion from u128 to i128, shouldn't this error message be to the effect that the fee amount is too large?

[murisi]

I understand that this conversion is necessary to placate the type checker, but is this conversion necessary at the conceptual level? I could imagine convert_masp_amount_to_namada being generalized or being given a twin that takes U128s instead of I128.

[murisi]

It seems to me like we can avoid this fallible conversion if we declare input_amt as let input_amt = U128Sum::from_pair(asset_type.to_owned(), *fee_amt) or something similar. But doing this would involve using an analogue of convert_masp_amount_to_namada that takes U128Sums...

[murisi]

The fallible conversion here and at

namada/crates/sdk/src/masp.rs

Line 1839 in 6c339f2

i128::try_from(*fee_amt).map_err(|e| {

could be replaced with one fallible conversion of found_amt (declared at

namada/crates/sdk/src/masp.rs

Line 1861 in 6c339f2

let Some(found_amt) = Self::add_inputs(

) to a U128Sum.

[murisi]

Given that a caller might call this function with negative entries inside amt, shouldn't we first check to see if val can be converted to a u128? Or better yet, shouldn't we just change the parameter amt: I128Sum to amt: U128Sum?

[murisi]

I guess this error occurs when fee: U128Sum is too large to be contained by a I128Sum. This sort of error (u128 too large for i128) seems to be less clearly defined than those that were produced when an I128Sum unexpectedly contained a negative quantity. I guess this is because it's clearer that quantities like fees can only ever be positive (or maybe zero).