MASP validity predicate

[juped]

Depends on #54, #55.

Desired abilities:

• stores notes/nullifiers
• verifies (proof, notes nullifiers) sets from transactions
• exposes readable Merkle tree roots for clients in its storage
• holds assets (just balances for now?)

┆Issue is synchronized with this Asana task by Unito

[cwgoes]

@murisi this is done, right?

[murisi]

@cwgoes If I'm not mistaken, I believe @juped has completed these tasks. But I would need to review the validity predicate code to ascertain whether the validation is sufficient, i.e. to ensure that the VP does not in any circumstances accept any transactions that should be rejected.

[juped]

yes; but we were discussing porting it to native, which would be so much less flaky

[murisi]

@juped Ah, I see. Great! Regardless of whether or not we port, I see a potential issue at https://github.com/anoma/namada/blob/main/wasm/wasm_source/src/vp_masp.rs#L75 . If the client somehow manages to construct a Transaction with shielded_tx.value_balance equal to zero (and hence having no components), the VP might crash in the process of unwrapping.

More generally to prevent potential exploits, we should probably try (whether here or in the port) to enforce the 4 conditions at https://github.com/anoma/namada/blob/main/documentation/specs/src/masp/ledger-integration.md#boundary-conditions . They serve to ensure that the outer Transfer object is consistent with the inner Transaction in terms of the numbers and fields of the transparent inputs/outputs. I think we haven't really had an issue here yet because the CLI client has been well behaved so far.

[murisi]

yes; but we were discussing porting it to native, which would be so much less flaky

@juped I'm not sure what the status of this is, but I've identified some potential further issues in the MASP VP code as it currently stands: #1373 .