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: Initial understanding of trusted setup and MPC #9

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

Comments

@oskarth
Copy link
Member

@oskarth oskarth commented Nov 8, 2019

Problem

Using zkSNARKs a trusted setup is required to generate prover and verifier keys. As part of this setup, a toxic parameter lambda is generated. If a party gets access to this lambda, they can prove anything. This means people using zKSNARKs usually have an elaborate MPC ceremony to ensure this parameter doesn't get discovered.

Acceptance criteria

  1. Have an understanding of the threat model for specific deployment, e.g. for spam resistance (spammable network) vs private transactions (loss of funds). In terms of severity*difficulty threat model.

  2. Have an understanding of and a plan for how to run an MPC ceremony and how much work it is to prepare etc.

  3. Have an understanding of to what extent this work can be shared with the community, e.g. if any Semaphore based application can leverage this setup, it might be desirable.

  4. Have an understanding of the alternatives to zkSNARKS trusted setup, and the precise blockers for their use. E.g some ZKPs have no trusted setup, and some have a slightly less trusted setup (?). This is important to community clearly with stakeholders.

Possible solutions

1. In MVP, do it ourselves or with a very KISS small-time ceremony

Assuming the only impact is a spammable network, that's strictly better than what we have now.

2. Do an ambassador program open signup MPC

Together with marketing and more significant spend, similar to Zcash Sapling and AZTEC. Probably overkill for now.

3. Collaborate with more parties on it

Once the basic concepts have been proven (rate limiting, etc). Assumes re-use doable.

4. Use other ZKP technology

Requires understanding blockers much better. E.g. tooling exists for zkSNARKS and it works with Ethereum today. STARKs verification requires a lot of gas, and proof size is bigger than a message.

Worth looking into e.g. how AZTEC works, and recent Zcash research (HALO, Bulletproof?).

@barryWhiteHat

This comment has been minimized.

Copy link

@barryWhiteHat barryWhiteHat commented Nov 8, 2019

Have an understanding of the threat model for specific deployment, e.g. for spam resistance (spammable network) vs private transactions (loss of funds). In terms of severity*difficulty threat model.

I think fi you break the trsuted setup you can spam the network. So you can definetly recover from this. So probably donsnt need to be high priority. You dont lose any privacy.

Have an understanding of and a plan for how to run an MPC ceremony and how much work it is to prepare etc.

The ceremony for groth16 (what we all use now) has two phases, Phase 1 is generla and phase 2 is circuit specific. We are running Phase 1 now and will run it for a long time so you can joni anytime. Phase 2 we will run for semaphore but you will probably use a differnt version of semaphore so will need to re run it then.

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