Snark parameter size limitations

[whyrusleeping]

Preface: I am not an expert, i'm just trying to help source requirements here.

Currently, our circuits are looking like they will be very very large. Large circuits implies not only long proving times, but also large public parameters, and a more difficult trusted setup MPC ceremony.

During this ceremony, there will be two phases (at least, for the groth paramgen ceremony). In the first phase, a big piece of data will need to be downloaded, processed, and uploaded by a large number of people (ideally, north of 100, but at least 50, the zcash ceremony involved 87 people for this phase). If i remember correctly, the zcash parameters were under a gigabyte. That ceremony was difficult enough to coordinate, and participate in. If the resource expenditure required for each participant were significantly greater, the coordination cost of running this with enough participants would be much higher.

The second phase (which I admittedly don't fully understand) requires a number of participants to have very secure setups (minimizing the probabilities of their hardware being compromised) and stay connected for the duration of the MPC. The runtime of the MPC scales with the number of participants and the size of the parameters being operated on. The longer the ceremony runs, the more time an attacker has to potentially compromise each participant.

The above should inform a maximum allowable size for the parameters involved. At some point, the ceremony simply becomes too expensive and difficult to run to be feasible, we need to stay under that number.

cc @nicola @porcuquine

[porcuquine]

@sanchopansa When your report which will help inform this decision on maximum circuit size is available, would you please link it here?

[sanchopansa]

Here is the report summarizing our findings on the trusted setup ceremony (and it also includes some data points about performance of Sonic and proof malleability in Groth16).

Trusted Setup & Sonic Performance Report.pdf

[sanchopansa]

@whyrusleeping -- I also would like to address one of the things you put in the comment above, namely:

The second phase (which I admittedly don't fully understand) requires a number of participants to have very secure setups (minimizing the probabilities of their hardware being compromised) and stay connected for the duration of the MPC. The runtime of the MPC scales with the number of participants and the size of the parameters being operated on. The longer the ceremony runs, the more time an attacker has to potentially compromise each participant.

To the best of my knowledge, this is not the case with the Powers of Tau. The Powers of Tau ceremony consists of two parts: one which generates re-usable parameters for all circuits up to a given size and a second part, which generates circuit-specific parameters for a given application. Both of those are run as an MPC, but the MPC runs sequentially, i.e. one participant makes their contribution and can subsequently go offline, with the next participant taking the output produced by the previous one and adding their contribution to the randomness. This repeats until there are no more participants. Finally, a random beacon is applied to the parameters to avoid adaptive adversary attacks from the last participant.

The above is one of the main differences (and advantages) of the Powers of Tau protocol, which was used for the generation of the Sapling parameters in Zcash, compared to the earlier MPC protocol used for the generation of the Sprout parameters. In the Sprout version, it was indeed the case that all participants had to be online throughout the entire duration of the ceremony, which both severely limited the amount of people that could participate, while at the same time potentially compromising its security (if it went on for too long), as you pointed out.

In the report linked above, we also shortly discuss this topic.