MASP Rewards Distribution Algorithm Mints (Slightly) Too Much NAM

[murisi]

The current MASP rewards distribution algorithm mints NAM in order to be able to service claims for shielded rewards. The problem is that it mints too much NAM for a few reasons including users choosing to unshield without claiming their rewards and the token being distributed across shielded accounts in such a way that the majority of token owners never meet the conversion threshold.

The specific case this issue is concerned with is overminting due to rounding errors occurring in the execution of the rewards distribution algorithm. This overminting can be observed at

namada/crates/tests/src/integration/masp.rs

Line 2285 in 63665af

assert!(captured.contains("nam: 0.003216"));

where the MASP address' NAM balance is slightly more than zero even though all assets have been unshielded. This amount though it is probably unclaimable still counts as "locked" and will impact future inflation/rewards computations.

The cause of this problem is that for non-native tokens NAM is currently minted based on the inflated reward instead of the deflated reward. (See:

namada/crates/shielded_token/src/conversion.rs

Line 470 in 63665af

.u128_eucl_div_rem((reward, precision))

). This is problematic because the AllowedConversions that are actually put into the conversion Merkle tree use the deflated reward. A potential solution to this is to first compute the total deflated reward in NAM[0] and then inflate that amount to the current epoch using a NAM conversion. This approach is attempted in #4369 .

But even #4369 (which mints NAM based on deflated rewards) still overmints NAM. See:

namada/crates/tests/src/integration/masp.rs

Line 2285 in 11a2498

assert!(captured.contains("nam: 0.000012"));

. The reason is that in order to have sufficient NAM for the case where users first combine their pre-existing NAM[0] with NAM[0] rewards from their non-native tokens before converting to the current epoch, this algorithm avoids rounding down amounts to the nearest conversion threshold too early.

The PR #4285 manages to avoid overminting of NAM, but this comes at the cost of removing compounding rewards. See:

namada/crates/tests/src/integration/masp.rs

Line 2287 in 817bc6e

assert!(captured.contains("nam: 0"));

. In this PR overminting does not happen because (1) rewards for non-native tokens are no longer deflated into NAM[0] terms meaning that the same value that's put into the conversion tree also determines minting and (2) rounding down to the nearest conversion threshold happens early.