This proposal focusses on making the trusted setup ceremony faster and better streamlined. Incremental improvements in functionality are also proposed.
The key items proposed are:
The current version runs the contribution in-browser using the Rust-based phase2 code derived via Kobi et al. This approach has several advantages for optimal user experience, but requires a server-side conversion - a slow process - to return to the snarkjs format needed for verification. Switching to snarkjs contributions will remove that step, and remove the server as a potential bottleneck for the ceremony. The snarkjs phase 2 code is optimised for CLI contributions. Some changes will be required to improve its browser-friendliness, e.g. progress callbacks. We anticipate that the multi-threading improvements will mitigate any loss of speed.
In-browser contributions currently run in a single worker thread, with circuits running sequentially. We have a couple of possible improvements to this mode:
Some investigation will be required to settle on the optimal method. Corresponding changes to the UI will be included in the work.
Participants are currently asked to allow the app to read private gists from the user's Github account. That level of access is not required (write access is required), but Github's authorisation process is not sufficiently fine-grained to make this distinction. Anecdotal feedback from the zkopru ceremony suggests some users find this off-putting.
We propose adding an option such that participants may choose to create their attestation with some manual steps, avoiding the need for intrusive permissions.
Project mode would operate just as the zkopru ceremony did, with a link from the project's web site, and a group of circuits required for that project.
With a few modifications, we can support an alternative that may suit some projects, where circuits are added from time to time to a common pool. Contributions are accepted perpetually, separate from project-specific groups. Circuits can be paused or stopped when they are ready for finalisation, but the ceremony will continue as long as active circuits remain.
A public web site allowing participants and observers to download and verify contributions promotes transparency. We propose that this web site be updated automatically soon after verified contributions are received.
I have paid invoices for server expenses incurred over March and April for running the ZKOPRU trusted setup ceremony. The suppliers were: Google, for DB, site and data storage; Scaleway for backend servers, and Hetzner for a server used in the latter part of the ceremony.
Date | Supplier | Transaction description | Paid cost ($A) |
---|---|---|---|
06/04/2021 | ZKOPRU MPC Firebase - March | 73.02 | |
06/04/2021 | Hetzner | Hetzner cloud server - ZKOPRU MPC | 264.15 |
07/04/2021 | Scaleway | server/IP/storage fees: ZKOPRU MPC, Mar | 140.04 |
01/05/2021 | Scaleway | Scaleway server/IP/storage for ZKOPRU MPC | 435.84 |
04/05/2021 | Google Firebase Cloud services - APR 21 | 88.15 | |
Total | 1,001.20AUD | ||
USD/AUD per messari.io 7 May 21 = 0.772 | 772.93USD |
This schedule proposes the milestones for deliverables, and the payment claim at each milestone.
Task | Time Estimate (hours) | Delivery Estimate | Claim |
---|---|---|---|
Direct expenses for zkopru trusted setup mpc | - | - | USD772.93 |
snarkjs | 60 | 28-May-21 | USD3000 |
Multi-threading | 80 | 11-Jun-21 | USD4000 |
OAuth enhancements / Ceremony modes / Public archive | 52 | 25-Jun-21 | USD2600 |
All code delivered will be public domain, with a suitable open source license.
I will support the code against defects for a minimum of 3 months from delivery.
I submit this proposal on behalf of Stonebell Consulting Pty Ltd, registered in Australia: ACN 631653328
Sincerely,
Geoff Lamperd
Director
Stonebell Consulting Pty Ltd