Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Research zkSNARKS blocker: Proving key size and bootstrapping #8

Open
oskarth opened this issue Nov 8, 2019 · 6 comments

Comments

@oskarth
Copy link
Member

@oskarth oskarth commented Nov 8, 2019

Problem

Proving key size is ~110mb for Semaphore. Assuming this is embedded on mobile device, it bloats the APK a lot. Current APK size is ~30mb and even that might be high for people with limited bandwidth.

Acceptance criteria

Either drastically reduced key size, or some strategy for getting it after that gives a reasonable UX and.

Details

See https://github.com/vacp2p/research/blob/master/zksnarks/semaphore/src/hello.js#L100-L106

-rw-r--r--. 1 oskarth oskarth 110M Oct 31 18:39 myCircuit.vk_proof
-rw-r--r--. 1 oskarth oskarth 3.0K Oct 31 18:39 myCircuit.vk_verifier

Possible solutions

1. Reduce key size

Don't know what this would entail or to what extent it is possible, needs to be researched. Some thoughts from Barry here:

That supports 224 group members, for smaller groups the key is smaller
If we get to 2
24 unique devices we can optimise in a few ways to get this down.
We can use better hash functions and reduce the cost
We can also drop the security to 80 bits and halve the key size.

2. Get key after install

E.g. strategy to download proof key after install. This becomes a UX problem where you have to download a "big" file to get started messaging. This might be mitigated with basic rate limiting etc, but requires more thought.

3. Use different ZKP technology

The tradeoffs might look different. Didn't find anything regarding proof key size after a cursory search.

@barryWhiteHat

This comment has been minimized.

Copy link

@barryWhiteHat barryWhiteHat commented Nov 8, 2019

#7 (comment) will help.

Also you should decide how many unique devices you want to support. One possible solution is to partition into group of 2^16 but this hurts privacy.

@oskarth

This comment has been minimized.

Copy link
Member Author

@oskarth oskarth commented Nov 8, 2019

Basically we have to minimize the number of constraints to minimize here.
We can half the number of constraints by getting ride of blake2 / pedersen. And half again by reducing security to 80 bits. And half again by replacing mimc with rescue and having 11 leaves on each layer. Instead of binary mt we have a 11-ary merkle tree :)

@barryWhiteHat

This comment has been minimized.

Copy link

@barryWhiteHat barryWhiteHat commented Nov 8, 2019

@kobigurk we want to do semaphore RLN

If we make a proof where 90% of the circuit , witness are the same are there any optimizaitons / precomputations that we can do to save on proving time / compress the proving key?

@oskarth oskarth changed the title Research zkSNARKS blocker: Proof key size and bootstrapping Research zkSNARKS blocker: Proving key size and bootstrapping Nov 8, 2019
@oskarth

This comment has been minimized.

Copy link
Member Author

@oskarth oskarth commented Nov 11, 2019

We can also gzip the key, this should compress key size by ~80% (to verify)

@kobigurk

This comment has been minimized.

Copy link

@kobigurk kobigurk commented Nov 11, 2019

We can also gzip the key, this should compress key size by ~80% (to verify)

gzip does reduce a lot, you can check out MicroMix to see an example.

@kobigurk

This comment has been minimized.

Copy link

@kobigurk kobigurk commented Nov 11, 2019

@kobigurk we want to do semaphore RLN

If we make a proof where 90% of the circuit , witness are the same are there any optimizaitons / precomputations that we can do to save on proving time / compress the proving key?

I think any change in inputs would at least require the recomputation of H, off the top of my head I don't see a way around it. In this case, though, you could think of doing something like Gepetto/LegoSNARK to have two separate proofs and pay a bit more in verification time (you could batch verify to help with the costs maybe).

Curious - how come 90% are the same? Seems like an interesting situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.