Break the src directory into a depedency

[barryWhiteHat]

We want to use this with miximus so its a good idea to break the ./src directory into a depedency that can be called from miximus and sepaphore.

[HarryR]

So, the library is going to be a generic on-chain contract to verify proofs, maintain the Merkle tree, perform verification etc. then associated tooling to generate proofs etc.

[barryWhiteHat]

So the libary should just create a proof about a merkle tree , merkle proof, merkle root, proving key, verification key. Then output the proof as json that Miximus will use to create a withdraw.

For example with miximus we should output some public inputs; signal (recipiend address) , signal_variables (null), external_nullifier(null) this would require some changes to the miximus contract as well to be tracked barryWhiteHat/miximus#28

We get a bunch of value from this less audit, UI reuse.

[HarryR]

Hi,

I've started work on this on my fork at: https://github.com/HarryR/ethsnarks

I've implemented the verifying code in Python using py_ecc (proving code will always be in a native library), as I need to have a couple of end-to-end examples of prove/verify so I can change things quicker.

I'll be spending about a week adding:

• Continuous builds
• tests for Solidity and Python using standard testing frameworks
• Accepting and returning JSON for proofs, will make the function calls much easier to use and not require writing files to disk
• making it more usable as a library with supporting Python module
• documentation of the SNARK circuit

For the documentation, I need to document how the miximus and semaphore libraries are using it, so I can make sure that the circuit and supporting library supports them fully without adding complex stuff.

Will update you when I have more progress.

[barryWhiteHat]

Wow that is gr8. Thank you!!!

Accepting and returning JSON for proofs, will make the function calls much easier to use and not require writing files to disk

This might be difficult as the proving key is 800mb and could take alot of ram.

[barryWhiteHat]

If you want to make testing work faster you can change teh tree_depth = 29 to tree_depth = 2 in snarkWrapper/deploy.js this should really speed up the testing.

Secondly there is a current plan to compile the proving circuit to WASM so that it can be run in browser or by ZoKrates or by a similar language. So that might be an idea to move the proving out of CPP which is an annoying dependency.

EDIT: I can send you more info on this if you are interested.

[HarryR]

tree_depth = 2

Have already done this.

This might be difficult as the proving key is 800mb and could take alot of ram.

Just for the proof and verifying key, the proving key needs to be loaded from disk due to the size.

Secondly there is a current plan to compile the proving circuit to WASM so that it can be run in browser

It should be fairly easy to re-build the library with emscriptem, or WASM.

So that might be an idea to move the proving out of CPP which is an annoying dependency.

C++ is fine, having a supported and well tested library makes a big difference versus using super bleeding edge stuff or implementing it all yourself.