Trusted Setup MPC Phase 2 UI - Design Spec

The suite of services will facilitate trusted setup ceremonies for SNARK circuits. Projects requiring an MPC will submit their circuits using the coordinator UI. The participant UI will register participants, allocate them a queue position, and manage their submissions.

Coordinators may monitor the progress of the ceremony. Minimal intervention will be required.

Participants will be register themselves with the particpant UI. The submission will be generated within the browser as a preference. That may not be feasible for larger circuits, so the option of a CLI for submission generation will be available.

Components:

• Coordinator UI
• Participant Browser UI
• Participant CLI
• Server
  • DB API
  • Coordinator setup
  • Participant registration service
  • Ceremony tracking service

Deployment

The code will packaged as a code repository. Projects will be expected to provide their own server to host the suite, including data storage. Installation scripts will be provided such that implementation requires minimal interaction. Projects will need to configure the network environment (proxy config, firewall, DNS, SSL certificates, etc).

Coordinator UI

Coordinators may create and edit using the UI, but will require authentication in the form of a signed message matching the configured admin Ethereum address.

A ceremony will only progress once these conditions are fulfilled:

• a compiled circuit file has been submitted
• the circuit file has been validated
• ceremony parameters have been provided
• preparation steps are complete
• the coordinator's nominated start time has elapsed

A coordinator will be able to edit the parameters of ceremonies they have created until the ceremony starts.
Once started, a coordinator may monitor its status and progress. A ceremony may be paused and restarted, but no further control is available or required.

A ceremony will be eligible for finalisation once these conditions are satisfied:

• the number of valid submissions > minParticipants
• Eth main-net block height > nominated minimum block number to be used for the beacon

At this point, any in-progress submission will be allowed to complete. The coordinator may then request finalisation. Back end processes will then process the finalisation of the ceremony. The validation keys will then be available for collection.

The ceremony will continue accepting submissions for as long as it remains active. Once the initial finalisation conditions have been satisfied, a coordinator may request finalisation at any point, and the validation keys will be processed based on the state of the ceremony at the time.

Monitoring UI

Coordinators and other interested parties will be able to view

• list of ceremonies
• ceremony status
• participant list
• status of each particpant
• timing details:
  • actual start/end times for completed submissions
  • expected start times for queued participants
• submission validation details

Participant UI

Participants will register themselves in a browser UI. Sign-on using GitHub OAuth will be required. Authorisation credentials will be stored in local storage so that subsequent visits to the page will not require a repeat of the sign-on step. The server will assign a unique ID to the user. This ID will not be revealed except to the user and server admins, and will serve to match contributions to their registered users.

Computations for smaller circuits can be conducted entirely in the browser. For larger circuits a CLI option will be offered.

Browser-based submission

Once signed on, the participant will be taken to a page showing the first available ceremony to which the participant has not already submitted. The browser will establish a websocket session with the server to register availablity. This will be used for a server process to track the user's liveness. On initial connection, the user will be allocated a position in the queue.

The user will be informed of their position in the queue, along with estimates of the time it will take to reach the top of the queue, and the time it will take to perform the submission. The browser will periodically communicate with the server to obtain updates to the status.

Entropy will be collected using mouse and keyboard motion. This will serve as the random input to the submission. If multiple ceremonies are ready, the collection of entropy will repeat for each one, and retained for use with that ceremony.

Once the user reaches the top of the queue, the transcript file will be downloaded and the computation will begin. When complete, the participant's file will be finalised and uploaded to the server. Progress milestones will be reported on the page, and also to the server.

Should the browser shut down or lose its connection to the server before the top of the queue is reached, the server will soon become aware. A short grace period (2 mins) will be allowed, after which the participant will lose their position in the queue. If the browser is restarted, a new position will be allocated.

Once the submission is under way, the browser should not be shut down. The server will allow time for the submission to complete, based on the expected computation time plus a 50% margin. If this time is exceeded before the server restores its connection with the client, the submission will be rejected and the turn will pass to the next participant in the queue.

If a server has more available ceremonies to which the particpant has not submitted, the process will begin again and repeat until the ceremony list is exhausted.

CLI submission

The user will register by visiting the participant UI page and registering.

Entropy will be collected as for the browser UI.

When opting for the CLI-based submission, the user will be provided with a script that will:

• run the docker command to start the CLI client
• inject parameters (server URL, github user name, user ID, entropy string)

From this point on, the browser need not remain open.

The user will start the process from the command line. The sequence will be as follows:

• Client will establish communication with the server and register its readiness to accept a task
• Server will assign the client a queue position
• When ready, server will advise client to begin
• Client will download the transcript file
• Client will compute the submission
• Client will upload the new transcript file
• Server will be sent status updates periodically during these processes.

In the event that server communications are lost while the computation is happening, the server will allow time for the submission to complete, based on the expected computation time plus a grace period. If communications are restored before this deadline, the computation will be allowed to complete and upload the transcript file as normal. If the server does not hear from the client before the deadline expires, the submission will be adandoned, and the next participant's turn will begin. In this case, if the client restores its connection, then the process will begin again with a newly allocated queue position.

Database

Use Firebase. Coordinator must have a Firebase account. Credentials will be configured as part of server setup.

DB initialisation scripts will be provided.

Ceremonies

Stores details on planned, in-progress and historical ceremonies.

• ceremony id
• name
• description
• status: PRESELECTION, SELECTED, PAUSED, RUNNING, COMPLETED
• time added
• time started
• coordinator id
• path to file storage

Participants

Details of all registered participants and their participation in ceremonies

• participant id
• GitHub user ID

Participation details:

• ceremony id
• participant id
• position in queue
• time started
• time completion
• submission status: WAITING, RUNNING, MISSED, COMPLETE
• path to transcript