Unlike Zcash Sapling, notes are not limited to MAX_MONEY. The logic needs to be checked thoroughly, and tests written, to make sure that there are no overflow or other issues when the value is close to i64 or u64 limits.

Title it and change the filename to "multi-asset shielded pool" in some form.

It has large parameters for circuits we don't even use.

If we want to keep the bundled prover, I have anoma/namada-masp-params, though it lacks wagyu-zcash-parameters' hack to be compatible with crates.io.

There is a feature "bundled-prover" which embeds the generated proving params into the binary using wagyu-zcash-parameters (obviously this will need to be updated with different parameters)

There should be a similar feature which bundles or embeds the verifying key in the binary (particularly WASM binaries).

There are two ways to do this: embed the small VerifyingKey (approximately 1.6kB per circuit), or serialize the PreparedVerifyingKey (approximately 40 kB per circuit).

Embedding the small VerifyingKey has the disadvantage that every time the binary is reloaded, the VerifyingKey must be "prepared" for pairing which may waste CPU, particularly in a WASM binary that is reloaded frequently.

However, embedding the PreparedVerifyingKey results in a larger binary, and requires some changes (visibility and serialization) in the upstream bellman crate.

Initial work is located at joe/embed-verifier and joe/embedded-verifier

Is the test-output-params updated?
The hash check is failed and it will get a parse error when downloading the output-params

Let's just add a quick README explaining what the MASP is and linking to the spec.

Mini task:

1. Go to Settings of this repo
2. Social Preview --> pick an image from this folder.
3. Test this on e.g. Wire or Twitter (copy / paste the URL of this repo) and see how it looks like (take a screenshot)

Currently, final_check prepends the public key for signature verification to the sighash to construct the actual msg on which the signature should be verified. This is the correct logic for the single verifier but the batch one doesn't need this because it will reconstruct the correct message on its own. This lead to a signature verification error when using the batch verifier. We should change final_check to expect the correct msg and let the caller pass the correct value to support both verifications.

Currently the circuit tests could be refined a little bit. Right now it tries many random inputs, which takes a long time and doesn't really test edge cases.

libmasp is the forked crate of FFI bindings, which makes sense if calling from C/C++ or Ocaml, but not necessary for Rust.

Currently MASP depends directly on the latest librustzcash. The current principle behind this is that librustzcash is a mature, well tested implementation and the more code reuse that is possible, the more the MASP benefits from this. MASP depends on librustzcash in two ways:

1. Directly as a dependency, and
2. Source code forked from librustzcash, typically only with constants changed

In the long run, it would be nice to reduce (2) if librustzcash natively supports different constants.

There are some tasks which should be done:

1. Pin the librustzcash dependency to a specific commit hash so breaking changes to librustzcash don't break MASP without warning
2. Migrate code updates from librustzcash to masp_primitives and masp_proofs as necessary. In particular, most Sapling-related updates to the zcash_primitives and zcash_proofs crates should be analyzed if they are applicable to masp_primitives and masp_proofs as well

Can we update the README file to reflect:

1. The inclusion of the convert circuit in this repository as well as the MASP circuit
2. The recent audit conducted by Inference AG (we can include the PDF in this repository)

The Convert circuit is prototyped, but there are some missing parts:

• Formalize and complete all specifications for the in-circuit and out-of-circuit behavior of Convert
• Implement building the out-of-circuit Merkle tree of allowed conversions
• Include the Convert description in transaction building and verification
• Implement an example incentive mechanism based on Convert
• Write tests for all of the above and review for errors

the Convert circuit can be used to provide incentives in the following way. When asset type A is shielded during epoch i, the MASP asset name is defined to be A's address || i, essentially timestamping the shielding time. To distribute 1 unit of asset type B for every unit of asset A inside the shielded pool during the entire epoch i+1, then at the end of epoch i+1 (at the beginning of epoch i+2) an allowed conversion of the form: -1 units of A's address || i, 1 unit of A's address || i+1, 1 unit of B's address. This allows the conversion of the timestamp from epoch i to epoch i+1. When the asset A is unshielded, it can be converted to the newest epoch, avoiding the need to leak the original shielding epoch.

To prevent the need for sequentially Converting across many epochs, during fixed epoch j the allowed conversions are between A's address || i and A's address || j for all i < j, allowing direct conversion to the latest epoch in one transaction.

Hi!
Why does cv^{old} apply GroupHash instead of FindGroupHash?

As shown below, FindGroupHash would be appropriate if following Sapling's protocol.

Are FindGroupHash and GroupHash equivalent here?

I would also like to know why [v]FindGroupHash^{J(r)*} -> [v_{old} hJ]vb

Currently, the specifications for MASP are divided among several places:

1. The original Zcash Sapling specification
2. The cryptographic MASP specification at https://github.com/anoma/masp/blob/main/docs/multi-asset-shielded-pool.pdf
3. The MASP transaction format and validity predicate in the Anoma specifications at https://spec.anoma.network/master/architecture/namada/masp.html

This makes it a bit difficult to review the entire protocol. It may be useful to merge everything into a single comprehensive spec.

When compiled for wasm32, the append method of CommitmentTree crashes after the first two insertions, i.e. the first time the function Node::combine is called