Non Membership Proofs

[BlakeMScurr]

This adds a circuit for making zk proofs of non membership in a merkle tree.
It also provides a TS class for preprocessing the tree to easily get the relevant data.
The tests show that our circuits accept some arbitrary valid non membership proof.

This stackexchange post explains the algorithm well.

[coveralls]

Coverage: 88.525%. Remained the same when pulling f311f3f on non-membership into fbf5707 on main.

[sripwoud]

utACK
@wanseob Could you help finding an additional reviewer to give feedbacks to Blake and approve this circuit PR?

[sripwoud]

@BlakeMScurr
Please the resolve conflict
I tried to do it myself because the conflict as shown in the web editor is trivial.
But it seems to mess with your previous PR about pub key check afterwards.

error[T2008]: Duplicated callable symbol
 ... 
ECDSACheckPubKey is already in use

[socathie]

I believe comparators already include bitify. That's why you are getting duplicate dependency error.

[sripwoud]

🤔
I see that comparators does include bitify...
It doesn't cause an error locally though.
So I am not sure...

[socathie]

Circuit looks good to me. Just a question on the practical side though, how do we actually obtain the two adjacent addresses in raw form for comparison in a non-inclusion proof? Does that mean we have a server that actually stores these addresses in raw (instead of hashed) form?

[BlakeMScurr]

Hey @socathie, yes the idea is that someone would be storing this in full unhashed form. The main use case for a non-membership proof that we could think of is a blacklist for a mixer (like tornado cash). In that case some kind of censor would publish a list of disallowed addresses and freely share them.

Now that I think about it, maybe there needs to be a mechanism to make sure they're sharing the full tree, but that would probably be a smart contract where they can manually add addresses to a merkle tree. But either way, for the purposes of withdrawing, you can assume that the blacklist would be published somewhere.

[socathie]

I see. It makes a lot of sense now!

[BlakeMScurr]

@r1oga I had the same issue with ECDSACheckPubKey being duplicated, but I actually just fixed it by rerunning pnpm install. The issue was the this non-membership branch was using my fork of circom-ecdsa (back when we thought I could add the public key check into the depdency), whereas the main branch was not using a fork, and we had ECDSACheckPubKey in our repo instead. So these tests should pass.

[BlakeMScurr]

@r1oga So we have a timeout issue here. We have so many tests that there we seem to be hitting a ~30 minute limit on the github action. I have set the internal jest timeout to over 2 hours (lmao), so it's not that. It takes ~50 minutes for me to run the whole test suite locally, and it all passes:
ECDSACheckPubKey: 842s
Inclusion test: 1017s
Exclusion test: 1012s
Poseidon tests: 5s

[sripwoud]

@BlakeMScurr Github Action jobs can execute for up to 6h so the test should be able to complete within that time.
These are the specs for default runners.
Paid plans have larger runners.
Or later we could config GitHub actions to run on a self hosted runner.

For now let's ignore this and merge. I can confirm I could run the test successfully locally too.