Bundle proving and verifying key in binary

[joebebel]

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

[XuyangSong]

It seems that the work is almost done except the visibility and serialization of PreparedVerifyingKey?

[joebebel]

Ah, I didn't upload my local branches of bellman and bls12_381 (it's boring, I just make the necessary fields public)

Also the branches are different: joe/embedverifier embeds the VerifyingKey (no changes to bellman or bls12_381 necessary) joe/embeddedverifier embeds the PreparedVerifyingKey, but does the (de)serialization in the masp_proofs crate (requires public visibility in bellman and bls12_381

It might be worth doing some quick benchmarks between the two approaches to see if it matters at all (the important target is WASM). For example, the huge binary in from embedding PreparedVerifyingKey might have loading costs which are bigger than the compute costs of embedding VerifyingKey and computing PreparedVerifyingKey (making the debate between the two pointless)

[XuyangSong]

benchmark results for joe/embedverifier: VerifyingKey deserialize from binary: 138us 960ns VerifyingKey preparation: 35us 233ns (pairing + other computation) VerifyingKey pairing: 30us 15ns

Since pairing operation takes up the most time of VerifyingKey preparation, we can only precompute the pairing and it won't add extra space as PreparedVerifyingKey.

You can review the code here

[joebebel]

OK, it's better to embed the VerifyingKey and not the PreparedVerifyingKey. Also, we can cache the prepared value.

So we should:

1. Add testing params for Convert circuit (can be generated using https://github.com/heliaxdev/masp-mpc/tree/joe/update)
2. Do some cleanup of the joe/embedverifier branch
3. Merge joe/embedverifier into main

[XuyangSong]

The commit(https://github.com/anoma/masp/commit/c62a1513c77fd88e1fd68a2c28ec5d5c53d8c80e) in branch joe/embedverifier is ready to merge? There are some tests error to fix in the commit. If needed, I'll fix and merge.

[joebebel]

I was waiting to merge the current state of https://github.com/murisi/masp/tree/murisi/masp-transaction3 into that commit (basically, I was trying to update the note encryption to be in sync with the latest librustzcash)

Maybe let's merge the embedded VerifyingKey first, then merge the transaction/note encryption parts later.

[XuyangSong]

The benchmark result is wired since the pairing operation needs at least 1ms. I found that the easybench_wasm is only useful with a running time in the range 1 ns < x < 1 ms. Therefore I tested those cases manually in both wasm and general environment. The conclusion is the same by accident. The pairing operation takes up the most time of VerifyingKey preparation. So I deleted the wasm bench code in PR.

[juped]

Over in Namada we're ready to handle params correctly; how does this look on this side @joebebel? (Bundling the full params into the node makes it really huge, and as I understand it the small verifying key is enough?)

[cwgoes]

Closing in favor of https://github.com/anoma/namada-masp-verification.