Awesome

Perpetual Powers of Tau

中文

The Privacy & Scaling Explorations 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 compromised, the entire setup is trustworthy.

To take part, please get in touch with EF's PSE team via the #ppot Discord channel (Join PSE's Discord server here).

Contents:

Contribution List

Notes on Procedure

Participating

Phase 2 Files

Ceremony progress

Transcript files

Note: as each challenge file can be deterministically generated from a prior response file, we have only backed up 34 challenge files on an IPFS node, and if we need to free up space on its storage device, we will delete some challenge files (except, of course, challenge_initial).

Prepared Phase 2 Files

Files have been prepared, ready for use in Phase 2 operations, from contribution 0080. The response file from 0080 was converted to snarkjs .ptau format, had a beacon applied, then prepared for phase 2. Files for each lower power of 2 were extracted from the result. These files are available at the links below.

The complete file with $2^{28}$ powers of tau, in .ptau format, can be found here

Beacon

Randomness for the beacon used the randao_reveal value from slot 7,325,000 of the Ethereum beacon chain. The choice of slot number was announced in advance, as recorded in this transaction

Randao_reveal value: 0xaf941599f6d640b5b4b6116d3ded861b3362a964c390edc270aef45ba17b67148fb3d7ab901a68b1528c9bb3e16721cc000dda5d8466f4aa4a1c8ca9eb57d05e6c2d2e780d6a793df90a1ebd076bb3dd9b7d4075e3e68b36b86c1fb7c4feeded, as per the block summary.

31 iterations were used in calculating the beacon hash.

The beacon file has been saved here

Prepared and Truncated Files

A phase-2-ready .ptau file is available for each power of 2 up to 28. When choosing a file, the best choice is generally the smallest file with a number of points > the number of constraints in the circuit.

Contribution 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 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 participant 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.

Archiving

The transcript files will generally be saved in an archival storage, i.e. not available for immediate access, but can be made available by request. Such requests will entail a delay while the file is retrieved, and the file will be available for a limited number of days before it returns to archival status.

To raise a retrieval request, please raise an issue in this repo with the names of the files required.

Preserving the Data

We have a network sharing the data via torrents, as an alternative to the S3 bucket. Volunteers to help with this are welcome to participate. See here

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 AWS Cloud VMs to generate new_challenge files, and S3 Storage to host challenges and responses.

Each participant can transfer their response to the coordinator via sftp. This process is semi-interactive as it 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
• SFTP: You will be provided details on request

Instructions for each participant

There are two implementations of the software which you can use to generate a contribution: phase2-bn254 and snarkjs.

You should use snarkjs if you do not mind running the software for 2-3 days. If you have no preference, please decide at random.

To use phase2-bn254, follow the instructions below. To use snarkjs, read this document instead.

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

Ensure you have the necessary build prerequisites:

sudo apt update && sudo apt install build-essential

Download and compile the required source code:

git clone https://github.com/kobigurk/phase2-bn254.git --branch master && \
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

Also check with the coordinator (or this repository) for the expected Blake2b hash of challenge.

Run the computation with challenge in your working directory:

/path/to/phase2-bn254/powersoftau/target/release/compute_constrained challenge response 28 2097152

You will see this prompt:

Will contribute to accumulator for 2^28 powers of tau
In total will generate up to 536870911 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 computation 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:

Finishing 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.

Your attestation

Finally, document the process you used, following the example here: https://github.com/weijiekoh/perpetualpowersoftau/blob/master/0027_alex_response/alex_attestation.md

We recommend that in your attestation, you include the git commit hash of the phase2-bn254 repository from which you built the binaries.

Sign your attestation with your Keybase account or GPG key and post it to the mailing list. We highly recommend using Keybase instead of GPG as it is easy to make time-consuming mistakes when attempting to publicise and/or share GPG keys.

Signing an attestation with an Ethereum account

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)

Note on Chain Fork

The chain of contributions now has two forks, branching after contribution number 0058. This choice has been made for the reasons outlined below.

Contributions from 0001 to 0077 form the first branch. Contribution 0078 chains from 0058, and this second branch is the one to be continued for future contributions.

We have a complete set of data available for the second branch. This is not the case for the first branch. Data, including public keys, for some of the contributions (0059 to 0071) are no longer available.

The discontinued fork remains valid. Contribution 0077 has the longest chain of contributions, and may be used in phase 2 setups. The chain of hashes can be confirmed by referring to the contribution details stored in this repository. However, a stronger cryptographic verification requires a continuous and complete chain of public keys in addition to the contribution hashes. Such data is embedded in .ptau files, as used by snarkjs. A snarkjs powersoftau verify command will cryptographically validate the full chain of public keys. Thus, it is not possible for us to generate fully-compatible .ptau files from 0077 or its immediate predecessors.

We have a complete history of public keys up to 0058, and for the branch continuing from there with 0078. We will, from time to time, publish .ptau files from this branch.

Note also that links referred to files in ppot.blob.core.windows.net bucket are no longer working. Some of these files are available on either IPFS or S3 high-availability, or S3 Glacier (available only by request).

Contribution details for the discontinued fork are recorded here