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 for RLN #9

Open
oskarth opened this issue Nov 8, 2019 · 11 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 and 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
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.

@decanus decanus added this to the zkSNARKS Feasibility milestone Apr 16, 2020
@barryWhiteHat
Copy link

@barryWhiteHat barryWhiteHat commented Sep 10, 2020

This has currently have had 55 participants in phase 1 https://github.com/weijiekoh/perpetualpowersoftau

Also for the RLN the attack space is pretty small. Just means you can spam the network if the setup fails. Which basically degrades to the status quo at the moment. Except you can do another setup and continue.

@oskarth
Copy link
Member Author

@oskarth oskarth commented Sep 15, 2020

Leaving open for now to understand security implications a bit better with the tiered phase setup. Though intuitively I agree with above comment (and participated in the ceremony myself!).

@barryWhiteHat
Copy link

@barryWhiteHat barryWhiteHat commented Sep 15, 2020

How many participants would make you feel more comfortable ?

@oskarth
Copy link
Member Author

@oskarth oskarth commented Sep 15, 2020

Oh it is not participants. I'm quite sure things are fine the way they are! And I agree intuitively re threat model. It is just to close issue I'd like it to be 100% clear for Status people what security implications are. Specifically:

  1. What assumptions are made for first ceremony (afaik 1 trusted out of N participants, very good)
  2. What differences there are for RLN vs PPTau in terms of trust assumptions
  3. What worst case scenario

These should be documented as part of specs, e.g. Though I suppose informal answers to above would be enough to close this issue and then we can elaborate on it in specs and get some of Status security people to look at it.

@barryWhiteHat
Copy link

@barryWhiteHat barryWhiteHat commented Sep 15, 2020

What assumptions are made for first ceremony (afaik 1 trusted out of N participants, very good)

Yes its one of n.

What differences there are for RLN vs PPTau in terms of trust assumptions

Its the same. PPTau also have a circuit specific phase. So in phase 2 you need 1 of m honest participants.

What worst case scenario

The worst case is that someone is able has the toxic waste which means they are able to make fake proofs. This would probably result in a dos attack that should be obvious and simply upgrading to a new trusted setup should work. We can launch with a small trsuted setup and continue adding to it and upgradeign the proving key / verificaion key we are using. Also later we can pugrade to plonk which has just a single phase trsuted setup and later we could even explore starks but this a large proof size cost.

@oskarth
Copy link
Member Author

@oskarth oskarth commented Sep 15, 2020

Its the same. PPTau also have a circuit specific phase. So in phase 2 you need 1 of m honest participants.

How many participants in the circuit specific phase for RLN? Or is this still a TODO?

For:

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.

We can probably remove private transactions from scope and revisit it when relevant.

@barryWhiteHat
Copy link

@barryWhiteHat barryWhiteHat commented Sep 15, 2020

How many participants in the circuit specific phase for RLN? Or is this still a TODO?

Its still todo. PPOT has ~60.

We can probably remove private transactions from scope and revisit it when relevant.

RLN provides just privacy for p2p stuff. It does not provide private transactions. With RLN there is no risk of lass of funds or privacy if the setup was compromised. Just the network could be spammed.

@oskarth
Copy link
Member Author

@oskarth oskarth commented Sep 16, 2020

Its still todo.

Ack.

RLN provides just privacy for p2p stuff. It does not provide private transactions.

Yeah I know, that is a quote from original issue as this pertains to zkSNARKs in general, not just RLN. I'm suggesting we remove general zkSNARKS from the scope of the issue and focus on RLN instead.

With RLN there is no risk of lass of funds or privacy if the setup was compromised. Just the network could be spammed.

Can you elaborate on exactly why it doesn't cause any privacy loss if the setup parameters are known? Not obvious to me.

@oskarth oskarth changed the title Research zKSNARKs blocker: Initial understanding of trusted setup and MPC Research zKSNARKs blocker: Initial understanding of trusted setup and MPC for RLN Sep 16, 2020
@barryWhiteHat
Copy link

@barryWhiteHat barryWhiteHat commented Sep 16, 2020

Yeah I know, that is a quote from original issue as this pertains to zkSNARKs in general, not just RLN. I'm suggesting we remove general zkSNARKS from the scope of the issue and focus on RLN instead.

Agree

Can you elaborate on exactly why it doesn't cause any privacy loss if the setup parameters are known? Not obvious to me.

Sure so when the trusted setup is broken integrity is lost but not privacy. A good intuition for why this happens is that the size of the proof is so small (and contains alot fo randomness) that its really hard to convey any private information inside it.

This is normally a problem. For example Zcash would prefer for privacy to be lost instead of integrity because they don't want people being able to mint infinite zcash if there is a bug. But in our case its quite nice.

So just to give a more high level description, In order to steal funds you need the users private key. If the trusted setup is broken this is still hidden because the proof is very random and so small that you would probably find it hard to encode the private key in it if you wanted to try.

@oskarth oskarth added this to New in vac-research Jul 14, 2021
@oskarth oskarth moved this from New to Icebox in vac-research Jul 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

3 participants