Research zKSNARKs blocker: Initial understanding of trusted setup and MPC for RLN

[oskarth]

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]

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.

[oskarth]

https://medium.com/coinmonks/announcing-the-perpetual-powers-of-tau-ceremony-to-benefit-all-zk-snark-projects-c3da86af8377

[barryWhiteHat]

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]

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]

How many participants would make you feel more comfortable ?

[oskarth]

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]

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]

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]

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]

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.

[barryWhiteHat]

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.