Trusted Setup UI Update

TL;DR: if you want to run a user friendly phase 2 ceremony, consider using our UI with new features

What is this project about?

The goal of a trusted setup is to securely generate zk-SNARK parameters. As long as one party in the ceremony behaves honestly and is not compromised, the entire setup is trustworthy. The computation can be split up into two phases. In the first phase (see Perpetual Powers of Tau) participants generate powers of a secret (tau) on an ongoing basis. In the second phase, participants take the output of phase one and apply it to a specific circuit. Projects that want to conduct a trusted setup can reduce their work as only the (circuit specific) second phase needs to be performed.

Our goal is to make it easy for projects to run a user friendly public phase 2 trusted setup without having to develop their own infrastructure. We successfully performed a ceremony for zkopru with a first version of the UI and applied learnings from this process. If you want to learn more check out the repo and join our telegram channel.

New Features

Some improvements to the Trusted Setup UI have been released. The key new features are:

• Much faster contributions
• Segregated ceremony spaces with a common back end.
• Automatic public archive site generation
• GitHub authorisation options

Faster Contributions

The trusted setup is based on the snarkjs library . We updated to the most recent version snarkjs, which has some changes that significantly speed up contributions. Our tests indicate that a typical user will now see an almost 8-fold improvement in contribution speed. Some other benefits came along with this. The back-end processes that validate contributions are also faster, so the overall ceremony is more streamlined and less prone to queue hold-ups.

Snarkjs tends to be optimised for command-line operation. Some changes were implemented to make a little friendlier in the browser environment, such as a callback to report progress.

These speed improvements mean that the UI can now feasibly support larger circuits. Circuit sizes of over 1 million constraints would have previously been unviable, but now they can be considered.

Project-Specific Ceremonies

Setting up a trusted setup ceremony entails a certain amount of effort, and this is even more so in our case, where we have automated queue management. It involves setting up a database, servers to store data, back-end services to validate the contributions, and a front-end site to provide the UI. Many ZK projects would prefer to be putting their efforts towards getting their product to release rather than setting up the infrastructure for a MPC.

To that end, a feature we now have is the ability to have a common back end servicing multiple separate ceremonies. A project can prepare its circuits and add them to the ceremony, recruit contributors, and run the ceremony independently of other projects running on the common infrastructure.

This feature also makes it possible for us to run a generic pool of circuits, such that a project could simply add circuits to the pool, and the ceremony would run any circuits in the pool, which may include circuits for other projects.

Archive Site

It is useful to make ceremony data available to the public so that contributors can validate their own contributions and ensure they’re contained in the finalised ceremony files, and interested observers can verify and track progress. This has previously been provided with a site built after the ceremony has finalised.

The ceremony will now automatically build as it progresses. Contributions will be visible a short time — within a minute or so — after the contribution is submitted. The files available from the site will include the zkey file (The snarkjs contribution file) and a log of the server’s verification. Instructions will be provided to enable an independent verification of the contribution.

Attestation Options

Public attestation of contribution hashes helps ensure that the contributions are not being falsified or censored. The UI encourages the creation of a gist that includes the hashes for each of the user’s contributions. The gist is created under the user’s GitHub profile, providing a defence against falsification or substitution of the contribution.

The UI previously requested access to the contributor’s GitHub profile, sufficient to automatically create the gist. GitHub’s authorisation mechanism is not particularly fine-grained, and the permission required to write to a gist also included permission to read gists, even private ones. The new option available to users allows them to opt out of automatic gist creation. We ask contributors to continue to create the gist in this case, and the UI will make it easy — paste from the clipboard, then another couple of clicks. This way, it is done under the contributor’s own GitHub login, and doesn’t require giving the UI app permission for gists.

We also encourage tweeting a link to the gist. In the case of automatically created gists, the UI will have a link to the gist, and can populate a tweet using a standard template. In the case of manually created gists, users should copy the URL to the gist and create the tweet themselves.

To opt out of automatic gists, before logging in, click the hamburger menu, the Options, then check the option.