naure / perpetualpowersoftau

Phase 1 of a multi-party trusted setup ceremony for zk-SNARKs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Perpetual Powers of Tau

中文

The Semaphore team is conducting phase 1 of a multi-party trusted setup ceremony based on the Zcash Powers of Tau ceremony. The goal is to securely generate zk-SNARK parameters for circuits of up to 2 ^ 28 (260+ million) constraints. This means that the process will generate twice as many minus one (530+ million) powers of tau.

As long as one party in the ceremony behaves honestly and is not comprimised, the entire setup is trustworthy.

Ceremony progress

Participant ID Identity GPG key Attestation
0001 Koh Wei Jie Keybase 0001_weijie_response
0002 Kobi Gurkan Keybase 0002_kobi_response
0003 Roman Semenov Keybase 0003_roman_response
0004 Paul Peregud Keybase 0004_paul_response
0005 Muhd Amrullah Keybase 0005_amrullah_response
0006 Zachary Williamson Keybase 0006_zac_response
0007 Youssef El Housni Keybase 0007_youssef_response
0008 Mike Lapinski Keybase 0008_mike_response
0009 Brecht Devos Keybase 0009_brecht_response
0010 Vano Narimanidze Keybase 0010_vano_response
0011 Zhiniang Peng Keybase 0011_zhiniang_response
0012 Daniel Wang Keybase 0012_danielw_response
0013 Kevin Lackner Keybase 0013_kevin_response
0014 Koh Wei Jie Keybase 0014_weijie_response
0015 Anonymous Cryptographer 0015_anon0_response

Transcript files

IPFS Filename
QmePmggNmSmzkJm3W1Kdz73FsUcdDpUGdvj466xTw9gjrg challenge_0002_kobi
QmSQXLTHVCNQQE2wF7q8n2vhNmLjzKpPXwsGSYkGboKefo challenge_0003
QmZ4qMYTRWKSWce2g2pose7v6maKGrrGG8HvtWPqxXyKxM challenge_0004
QmZfYvb1eeE1uXvBGQWFXq169Gh79qsdcho169MM2BJ3Z7 challenge_0005
QmeNukSckT7gkD354aQfzLh6T7ZGv51gPmQQEi18BmSpiC challenge_0006
QmQpAUqQ1jx8ABwmvw1kjUhFUcN8JM4D14BkE2roBrYtux challenge_0007
QmdRxyVimSRsAJ4HkD9AiMSCCM2qw5nrEAJVzUJXT4VpGT challenge_0008
QmQ1tzZi7PdHKE8VJczfHNgZbGSUp73viuytBoofcTnW1C challenge_0009
Qmd1gtTpWCy4LP1eskdF5jD8daGMvMz7oGVajMoKwHKsWA challenge_0010
Qmbf4UtTzdy3Cz56nXeom2fecB6ngYcryyitiVmYDTB4Za challenge_0011
QmYzPUEZ8BPjFMXXcPo1WA6zaHERthXLPGAMR8sPrGajA1 challenge_0012
QmY7MKhMN8heRK5Nwe5yhraepArWc5YZJCfarae7R9QuR4 challenge_0013
Qmepq4FrnagYp31cT7vKuagfF8vgT6RShnRvTr6zMQswkW challenge_0014
QmcXfTmYMqLF8iVmsD6phfXBke9DBiVecpbDh3TMfQphkG challenge_0015
Qmdq2k8TJcKmZbVStqfT95fPc9xc3hJFRd2szFMjYDj2ke challenge_0016
QmcdU9c71mTZGQnUGkkoXTrwtjyoTLPE2qp196VGCVgCuw response_0001_weijie
QmPE7QAVRAVdDMMMP9rMbNyhZ8jo9pkZUm5ycRgogsHVAD response_0002_kobi
QmUcPEstiXAFxYGKxCswXEgky69LvDrCLKamySrugW2Z4i response_0003_poma
QmeKL2woTQHoUHpZEu8MKLv6mPdqz9xAwGkdpAAurpAAzV response_0004_pepesha
QmQQZYBBbfgGmxLUjcq11bcuUPSQd1JCVkJ3rX8nqGVocU response_0005_amrullah
QmS3hMyQ9hworRi27Hkc85eTUXDx6ciw2QzZd8KcUNHb2x response_0006_zac
Qmc3yEq5QmckJwaQY8P1qEWSvfBYqCqMzB3q4mHYrZbZEk response_0007_youssef
QmQiu9W8nutk8Bkh5yg3aaiCCmYKjbCm48g6B8hWK2KjDw response_0008_mike
QmRrkQD44brXuaB9uw4gNvoJ5dHnkS3f2GrEhW9Jtz4Kff response_0009_brecht
QmU3Zj589iK67W5pYHMJEiVTzHVCsL9AeGqnBLhq6kU2Ww response_0010_vano
QmYtrvaTBn7ro9EBpiaDf4NWMxAKttKXDLww8rP2zbfesH response_0011_zhiniang
QmXBJ5d86CJfZzcqSeaqVMuJki8V4wsLsPR5bsSG23QmtC response_0012_daniel
QmYSGujwVYCUkQiktdadsC2Dr16EZGstXePhCzHBp6sqL2 response_0013_kevin
QmTQ2jJS2rDnZrXXNKM3XcHfWvfJPQy4tAnfKhLThT95YL response_0014_weijie
Qme4NoJyfmVqFgUUUounmxtk7C35iXhTCCjroJc4AxrL5V response_0015_anon0

Procedure

There is a coordinator and multiple participants. The ceremony occurs in sequential rounds. Each participant performs one or more rounds at a time. The coordinator decides the order in which the participants act. There can be an indefinite number of rounds.

The ceremony starts with the coordinator generating an initial challenge file, and publishing it in a publicly accessible repository.

The first participant downloads challenge, runs a computation to produce a response file, and sends it to the coordinator.

The coordinator will then produce a new_challenge file, and publish it along with the response. The next selected participant will then download new_challenge and produce a response, and the process repeats indefinitely.

Whenever a new zk-SNARK project needs to perform a trusted setup, they can pick the latest response, verify the entire chain of challenges and responses up to the selected response, and finally apply a random beacon to it. Next, they can move on to phase 2 of the trusted setup which is circuit-specific and out of scope of phase 1.

To illustrate this process, consider a Coordinator, two participants (Alice and Bob), and a zk-SNARK project author Charlie:

  1. Coordinator generates challenge_0 and publishes it.
  2. Alice generates response_1 and publishes it.
  3. Coordinator generates challenge_1 and publishes it.
  4. Bob generates response_2 and and publishes it.
  5. Coordinator generates challenge_2 and publishes it.
  6. Charlie applies the random beacon to challenge_2 to finalise the setup.

The resulting public transcript should contain:

  1. challenge_0
  2. response_1
  3. challenge_1
  4. response_2
  5. challenge_2
  6. The random beacon
  7. The final parameters

The random beacon

Zcash announced on their ceremony mailing list that they would use the hash of a specific Bitcoin block. They made this announcement before the block was mined. See:

https://github.com/ZcashFoundation/powersoftau-attestations/tree/master/0088

A similar process can be used for this ceremony. Note that mining difficulty has grown since 2018, so there is now slightly less entropy per Bitcoin block hash.

The transcript

The transcript can be fully verified as long as it is public and that there are no bugs in the code used to generate challenges and responses.

Participants can choose to be anonymous. If they choose to be publicly known, they should own a GPG keypair whose public key is known to be associated with their real-world identity, socially or via any other means.

Given the above, the transcript should contain all the challenge and response files, and the Blake2b hash of each file.

It should also contain an attestation for each response. This is a text file with:

  • Blake2b hashes of the challenge received and the response generated
  • A detailed description of the hardware and software that the participant used to generate the response.
  • A detailed description of any security and anti-surveillance measures that the partcipant has used.

Additionally, it should contain each participant's GPG signature of their attestation, so as to assure the public that it was generated by the person who had claimed to have done so.

Logistics

Each challenge file is about 97G in size and each response file is about 49G. An Azure compute VM (Standard F4s with 4 vcpus and 8GB memory) takes about 24 hours to generate.

The coordinator is using Microsoft Azure compute VMs to generate new_challenge files, and Blob Storage to host challenges and responses.

Each participant can transfer their response to the coordinator via sftp. This process is semi-interactive as it this requires either the participant to provide their SSH public key in advance, or the coordinator to send them a private key. Alternatively, they can use any of the following interactive methods:

  • BitTorrent
  • IPFS
  • Third-party large-file transfer services like MASV

Coordination

A mailing list has been set up to coordinate the ceremony:

https://groups.google.com/a/ethereum.org/forum/?hl=en#!forum/perpetual-powers-of-tau-ceremony-group

Instructions for each participant

First, set up a Linux machine and install Rust and Cargo following instructions here.

Download and compile the required source code:

git clone https://github.com/kobigurk/phase2-bn254.git --branch ppot_ceremony && \
cd phase2-bn254/powersoftau && \
cargo build --release

Download the challenge_nnnn file from the coordinator. The filename might be something like challenge_0004. Rename it to challenge:

mv challenge_nnnn challenge

Run the computation with challenge in your working directory:

/path/to/phase2-bn254/powersoftau/target/release/compute_constrained

You will see this prompt:

Will contribute to accumulator for 2^28 powers of tau
In total will generate up to 536870912 powers
Type some random text and press [ENTER] to provide additional entropy...

Make sure that it says 2^28 powers of tau, and then enter random text as prompted. You should try to provide as much entropy as possible from sources which are truly hard to replicate. See below for examples derived from Zcash's own ceremony.

The compuation will run for about 24 hours on a fast machine. Please try your best to avoid electronic surveillance or tampering during this time.

When it is done, you will see something like this:

Finihsing writing your contribution to `./response`...
Done!

Your contribution has been written to `./response`

The BLAKE2b hash of `./response` is:
        12345678 90123456 78901234 56789012 
        12345678 90123456 78901234 56789012 
        0b5337cd bb05970d 4045a88e 55fe5b1d 
        507f5f0e 5c87d756 85b487ed 89a6fb50 
Thank you for your participation, much appreciated! :)

Upload the response file to the coordinator's server using SFTP or rsync. We will provide you with options and guidance on how to do this.

Finally, document the process you used, following the template here: https://github.com/weijiekoh/perpetualpowersoftau/tree/master/0001_weijie_response

Sign it with your GPG key and post it to the mailing list.

Signing an attestation with an Ethereum account instead of GPG

If you wish to sign your attestation using an Ethereum account instead of GPG, please SHA256 hash your attestation and use an account publicly associated with your identity and store it in this Notary contract using the register(bytes32 _hash) function. Send the transaction hash to the coordinator, who will include it in the transcript.

This Notary contract is simply:

pragma solidity 0.5.11;

contract Notary {
    mapping (bytes32 => bool) public hashes ;
    
    function register(bytes32 _hash) public {
        hashes[_hash] = true;
    }
    
    function check(bytes32 _hash) public view returns (bool) {
        return hashes[_hash];
    }
}

Examples of entropy sources

  1. /dev/urandom from one or more devices
  2. The most recent Bitcoin block hash
  3. Randomly mashing keys on the keyboard
  4. Asking random people on the street for numbers
  5. Geiger readings of radioactive material. e.g. a radioactive object, which can be anything from a banana to a Chernobyl fragment.
  6. Environmental data (e.g. the weather, seismic activity, or readings from the sun)

About

Phase 1 of a multi-party trusted setup ceremony for zk-SNARKs

License:GNU General Public License v3.0


Languages

Language:Standard ML 100.0%