MACI Coordinator Service

[ctrlc03]

What is MACI’s Coordinator Service?

MACI’s coordinator service is a backend service that aims to automate MACI-related operations, such as contracts deployment, proof generation and poll finalization.

Its ultimate goal is to reduce the complexity of running voting/funding rounds using MACI and applications built on top of MACI. An operator should eventually only need to setup this service on a hosting provider, configure it, then take the IP address/port and add it to a frontend with hooks to call the coordinator’s service API.

Tech Stack

• Nest.js
• TypeScript
• Docker for quick setup
• GH Actions for automation of deployment
• Jest for testing
• AWS EC2 for in-house usage and testing

Repo

https://github.com/privacy-scaling-explorations/maci/tree/dev/coordinator

Board

https://github.com/orgs/privacy-scaling-explorations/projects/40/views/19

Which features are available currently?

Currently, the coordinator service has the following features:

• Two interfaces for external interaction
  • REST API
  • Websockets - Support websockets for coordinator service maci#1616
• Secure communication over an unsafe channel
  • HTTPS
  • Data encryption using RSA
    • Service stores the RSA private
    • Client can send encrypted data using RSA public
  • Signature verification using ECDSA
    • Define admins in service config with Ethereum addresses
    • Only accept calls when sending a encrypted (RSA) and signed message with ECDSA key from a valid address
• Proof Generation Service
  • Generate proofs of message processing and tallying
  • Generation is parallelized - Proof generation parallelization maci#1615
  • Endpoint Accepts the encrypted coordinator private key to locally decrypt
• Swagger for API documentation

Which features will be added

These features are planned to be integrated into the coordinator service to make it MACI’s Swiss army knife

Deployment of MACI contracts

• requirements
  • Research how to send transactions without seed phrase sharing maci#1630 - solution to avoid storing a seed-phrase on it
• Reuse of already deployed and verified contracts
  • https://maci.pse.dev/docs/developers-references/smart-contracts/DeployedContracts
  • Operator can set their own list but by default we use the public one
• Minimal interface
  • Better security: the least inputs the smaller the attack surface
  • Accept a JSON file with contracts needed to deploy and params
• Storage of data related to round
  • Store contract addresses
  • Allow retrieval of contract details and timelines from contracts in a simple way

Minimal storage of deployed contracts and Tally.json per Poll

• JSON to disk (could work too) to start with
• move to IPFS for data retention
• GET /contracts/
  • return this data (from deployed-contracts.json to start with)
• no need for DB at this time (nor future in best scenario)
• GET /tally/poll/Id
  • used to fetch the tally.json data for results and verification
  • also store to IPFS for data retention

On chain proof submission

• requirements
  • Research how to send transactions without seed phrase sharing maci#1630 - solution to avoid storing a seed-phrase on it
• As proofs are generated these are submitted on chain (ProveOnChain)
• Ensure retry and storage of batches to avoid commitment mismatch errors in case of intermediate failures

Subgraph Deployment - privacy-ethereum/maci#1629

• Requirements:
  • someone needs to setup a account on subgraph studio (or other providers)
    • they need key(s)
    • endpoint
  • Contracts must be deployed first (MACI contract)
    • addresses
    • network
    • version
    • start block
• Several MACI instances can have separate subgraphs to separate networks

Automation

• Poll deployment scheduling automation
  • Once application period ends deploy automatically
  • Set a date to deploy and let the service do it
• Automation of proof generation/submission
  • Requirements
    • Coordinator key must be on the service → risk of data loss and breach
    • Coordinator key can be generated directly on the server and never leave
    • TEE research MACI Coordinator in a TEE maci#1385
• Automation for proof generation/submission
  • Requirements as above (key storage)
• Automate all the things given a round timeline

Additional Interfaces (nice to have)

• GraphQL - Coordinator graphql #277
• gRPC

Relayer for OffChain MACI

• Future work
  • https://github.com/orgs/privacy-scaling-explorations/projects/40/views/21

Deployment of the service

WHERE

• platform is up to the organizer
• AWS/DigitalOcean/GCP etc.

HOW

• Docker
  • Configure .env
  • Configure third party services