Tracking Issue: decentralized setup to generate proving and verification keys for mainnet

[redshiftzero]

In #711 we described generating parameters for our zkproofs for development and testnet purposes. This ticket is for replacing the parameters from #711 with those generated in a decentralized setup ceremony suitable for mainnet.

As part of this ticket, we should research prior setups such that we can potentially reuse or extending parameters from an existing ceremony (e.g. powers of tau, see also https://eprint.iacr.org/2022/1683.pdf).

[redshiftzero]

Notes so far: https://hackmd.io/jr1MmCevRVek_PSbhR7hhg?view

[conorsch]

At sprint planning we discussed converting this to a tracking ticket, given all the subtasks likely to fall out of it. @cronokirby will take a look at the work planning and try to identify concrete tasks as an epic.

[cronokirby]

So, I think we've made enough progress to sketch out some actual tasks now, although I expected we'll be updating this tracking issue as needed. Also, the sketch here might change based on feedback from others in the team :).

The Snarky Ceremonies paper seems like a good base for us to build upon, and is quite similar to the kind of ceremony used in ZCash. (Main difference is a more refined security analysis, removing the need for a random beacon; we could still include one as a belt-and-suspenders approach, but not critical).

Without going into too much detail here, the basic idea is that for each circuit, we need to do two ceremonies, one after the other, each of which functions basically like a "Powers of Tau" kind of ceremony, and we can reuse the approaches that have been deployed for those. There would be a linking between the first phase and the second phase, requiring the actual constraints of a circuit at that point.

The basic idea here is that each person contributes one after the other, building upon the previous contribution. After each contribution, you have a valid output for that phase. You contribute by using the current output, generating some private randomness to produce a new output, and proofs attesting to some, but not all, aspects of your contribution being correct. Another person would then check this output, and build upon it themselves, and so forth.

You would also need an orchestration mechanism for figuring out which people are expected to contribute after the other, and to maintain a log of the contributions people have made.

Importantly, at the end of the ceremonies, people can check that the contributions they made were actually included in the log, and verify the log themselves, computing the proving and verification keys.

Splitting things up

One idea I like here is that we can try and isolate the "math" parts of the ceremony, e.g. calculating updates, verifying the log, etc. into a new crate, which would be stateless, and have minimal dependencies on the rest of the project. The idea is that this would potentially allow for independent implementations of this critical part of the ceremony logic. This crate would also be on the only part handling private data: the inputs and outputs here would be public.

Then, in pcli perhaps, we would add hooks to the orchestration logic, which could coordinate additions to the log and retrievals from it, without actually needing to care about what information the log contains.

To that effect, here are some preliminary tasks we might pull from this rough sketch (to be filled in with actual issues):

Mathy / Stateless Part

• Document the proposed math in isolation, as a template to follow.
  • Document the Setup Ceremony Math #2854
• Implement phase 1 contributions.
  • Setup Ceremony: Implement contributions for both phases #2869
• Implement phase 2 contributions.
• Implement validity checking for logs.
  • Setup Ceremony: Allow searching logs for next tip to build on #2870
• Implement the circuit-dependent connection between phase 1 and phase 2.
• Make and test the integration between the ceremony output here and the rest of the proving infrastructure.
  • Setup Ceremony: Implement phase connections and integrate with the rest of the codebase #2871
• Implement benchmarks so we can understand what the broader orchestration might be constrained by.
  • Setup Ceremony: Implement benchmarks for contributions, log verification, etc. #2877

Orchestration Part

I think we might want to progress on the math part to get some concrete numbers on how long operations take, and how resource intensive they are, which would inform how we decide to do the coordination aspects.

[hdevalence]

We closed out this issue, but we don't actually have a setup ceremony. Are we tracking the remaining work in another tracking issue?