[zapps-wg] Powers of Tau Ceremony Proposal

[Andrew Miller]

Thanks Sean!

My idea is to use an ad hoc and publicly visible process. "Get in
contact with [sean]" could be as simple as posting in public to this
thread. Unless we're overrun by trolls, a public mailing list can be
an informal way to agree on who goes next. Whoever posts and says "Me,
me! I'd like to go next", should, by convention, go next. Any
aberrations (parties taking too long or dropping out, posting invalid
data, etc., can be dealt with as needed).

I believe it's also the case that
a) The "response" file from each person is roughly the same as the
"challenge" file for the next participant, and
b) The response/challenge files are safe to be published at any time,
not private at all.
So, by convention, we should post the hashes of those files here right
away, and make a best effort to mirror them publicly (each one is like
a gigabyte, I think).

What does the initial challenge file consist of? Could you post the
hash of it here?

Cheers,

On Wed, Nov 8, 2017 at 3:04 PM, Sean Bowe via zapps-wg
<zapps-wg at lists.z.cash.foundation> wrote:
> Ariel Gabizon, Ian Miers and I have just published a new paper detailing a
> multi-party computation (MPC) protocol for constructing zk-SNARK public
> parameters.
>
> https://eprint.iacr.org/2017/1050
>
> The highlights are:
>
> * It allows for a single, gigantic ceremony to take place for all possible
> zk-SNARK circuits within a given size bound. The results of this ceremony
> are partial zk-SNARK parameters for the entire community. We call this
> communal ceremony the Powers of Tau.
> * If you want to use zk-SNARKs in your protocols, you still have to do an
> MPC for your circuit. But because of the Powers of Tau ceremony, your
> ceremony is much cheaper to perform and the costs per-participant scale
> linearly with respect to the circuit complexity.
> * The best part is that the Powers of Tau and these circuit-specific MPCs
> can scale to hundreds/thousands of participants. As the number of
> participants grows, it becomes unrealistic that all of them could be
> compromised.
>
> So, let's do the Powers of Tau ceremony! The Zcash Foundation is excited to
> participate in the process. The Zcash Company is particularly excited in
> starting soon because we want to leverage it for our next MPC for the
> Sapling upgrade of Zcash.
>
> The MPC protocol for this ceremony only requires that one participant
> successfully destroy the secret randomness they sample during their part. We
> intend to give participants total flexibility in deciding how to
> participate; we don't mind what software, hardware or OS you use.
>
> I have written some Rust software for participants to run:
>
> https://github.com/ebfull/powersoftau
>
> In order to simplify auditing, I won't be making any more changes to the
> code unless absolutely necessary. You don't have to use this software, but
> there are no alternative implementations at this time. I think it should be
> feasible to write a C version of the code using the RELIC toolkit, which has
> implemented BLS12-381. I am very confident in the Rust code, though, and I
> believe in its stability/correctness.
>
> I have some opinions about the ceremony:
>
> 1. I disagree with processes that don't improve security of the ceremony.
> Having a small surface area of code and process increases the chance that
> bugs will be discovered by auditors because there are fewer things that can
> go wrong. Remember that there is already quite a bit for the public to
> check: the transcript correctness, the code correctness, the randomness
> beacon, the cryptographic proof, code dependencies, etc.
> 2. It needs to start soon so that it can be useful for the Sapling MPC.
> 3. It needs to have lots of reputable participants by the time we start the
> Sapling MPC.
>
> Given the above, I would like to suggest that we start the ceremony now
> using my existing code, which supports circuits up to 2^21 gates. This means
> people would just get in contact with me if they want to participate and
> I'll schedule them in. I'll try to prioritize reputable people, but I'll
> allow pretty much anyone I have time to. Everything that I do is publicly
> verifiable (there is a transcript at the end of the ceremony which people
> can check).
>
> Andrew Miller has a few interesting ideas for a more distributed process for
> scheduling "who goes next" but there are some disadvantages and risks
> involved IMO. In any case, the process can be changed later without
> affecting anything, so I don't see a purpose in delaying the start of the
> ceremony on such things.
>
> I'd like to hear from others about this plan so we can begin soon!
>
> Sean Bowe
> Zcash Company



-- 
Andrew Miller
University of Illinois at Urbana-Champaign