@maci-protocol/website 0.0.0-ci.b4e6be4 → 0.0.0-ci.ec84efe
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/blog/2024-12-01-maci-getting-started.md +1 -1
- package/blog/2025-03-21-roadmap-2025.md +1 -1
- package/package.json +4 -4
- package/static/img/relayer-diagram.png +0 -0
- package/versioned_docs/version-v3.x/core-concepts/coordinator-service.md +16 -0
- package/versioned_docs/version-v3.x/core-concepts/offchain-voting.md +14 -0
- package/versioned_docs/version-v3.x/core-concepts/spec.md +1 -1
- package/versioned_docs/version-v3.x/core-concepts/workflow.md +7 -1
- package/versioned_docs/version-v3.x/technical-references/coordinator-service/_category_.json +8 -0
- package/versioned_docs/version-v3.x/technical-references/coordinator-service/index.md +10 -0
- package/versioned_docs/version-v3.x/technical-references/coordinator-service/installation.md +43 -0
- package/versioned_docs/version-v3.x/technical-references/offchain-relayer/_category_.json +8 -0
- package/versioned_docs/version-v3.x/technical-references/offchain-relayer/index.md +51 -0
- package/versioned_docs/version-v3.x/technical-references/offchain-relayer/installation.md +109 -0
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@maci-protocol/website",
|
|
3
|
-
"version": "0.0.0-ci.
|
|
3
|
+
"version": "0.0.0-ci.ec84efe",
|
|
4
4
|
"private": false,
|
|
5
5
|
"publishConfig": {
|
|
6
6
|
"access": "public"
|
|
@@ -41,8 +41,8 @@
|
|
|
41
41
|
"@docusaurus/module-type-aliases": "^3.7.0",
|
|
42
42
|
"@docusaurus/tsconfig": "^3.7.0",
|
|
43
43
|
"@docusaurus/types": "^3.7.0",
|
|
44
|
-
"@types/node": "^22.
|
|
45
|
-
"@types/react": "^19.0
|
|
44
|
+
"@types/node": "^22.14.0",
|
|
45
|
+
"@types/react": "^19.1.0",
|
|
46
46
|
"ts-node": "^10.9.2",
|
|
47
47
|
"typescript": "^5.8.2"
|
|
48
48
|
},
|
|
@@ -61,5 +61,5 @@
|
|
|
61
61
|
"engines": {
|
|
62
62
|
"node": ">=18.0"
|
|
63
63
|
},
|
|
64
|
-
"gitHead": "
|
|
64
|
+
"gitHead": "b27e334527501011f6e95b16c78d5141c3d3c66d"
|
|
65
65
|
}
|
|
Binary file
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Coordinator Service
|
|
3
|
+
description: The Coordinator Service is a service that allows to automate MACI coordinator tasks.
|
|
4
|
+
sidebar_label: Coordinator Service
|
|
5
|
+
sidebar_position: 10
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Coordinator Service
|
|
9
|
+
|
|
10
|
+
MACI’s coordinator service is a backend service that aims to automate MACI-related operations, such as contracts deployment, proof generation and poll finalisation.
|
|
11
|
+
|
|
12
|
+
Up until now, users of MACI have had to manually deploy the smart contracts using some scripts, which while pretty straightforward, they require the manual step of running them from a command line. The same goes for the finalisation of polls, which requires coordinators to check when a poll ends, and then run a number of scripts to process votes and tally them, as well as sending the results on chain. This prevents (or at a minimum makes it very difficult) non technical users from being coordinators of MACI.
|
|
13
|
+
|
|
14
|
+
With the coordinator service, a number of REST endpoints are exposed that allow client applications to perform the above tasks. For instance, now we can have frontend applications with intuitive interfaces to deploy and configure smart contracts. For poll finalisation, this can either be automated with a cron job, or triggered by a client application request.
|
|
15
|
+
|
|
16
|
+
For more details on how to use and integrate the coordinator service into your application, please refer to this [guide](/docs/technical-references/coordinator-service).
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Offchain Voting
|
|
3
|
+
description: The Offchain Voting is a service that allows users to vote on MACI polls free of charge.
|
|
4
|
+
sidebar_label: Offchain Voting
|
|
5
|
+
sidebar_position: 11
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Coordinator Service
|
|
9
|
+
|
|
10
|
+
MACI’s offchain voting service is a backend service that allows users to vote on MACI polls free of charge. This originated from [Vitalik's post](https://ethresear.ch/t/maci-with-mostly-off-chain-happy-path/19527).
|
|
11
|
+
|
|
12
|
+
In order to improve inclusivity of MACI polls, a coordinator can spin up the offchain relayer service to allow voters to submit their choices off-chain, saving on gas costs. Voters can check whether their vote has been submitted successfully by using relayer SDK, and if they believe they have been censored, can directly submit their vote on chain, using MACI in its normal form.
|
|
13
|
+
|
|
14
|
+
For more details on how to use and integrate the offchain relayer service into your application, please refer to this [guide](/docs/technical-references/offchain-relayer).
|
|
@@ -103,9 +103,15 @@ Before a user can cast a vote, they must sign up by generating a MACI keypair an
|
|
|
103
103
|
This registration process is necessary to fortify MACI against Sybil attacks. The particular criteria used to allow user signups is customizable, and can be configured using any [SignUpPolicy contract](https://github.com/privacy-scaling-explorations/excubiae/tree/main/packages/contracts/contracts/extensions). This contracts dictate the criteria a user must pass in order to participate in a poll. For example, a user might need to prove ownership of a certain NFT, or that they've received some attestation on EAS, or prove that they have passed some sort of proof-of-personhood verification. Note that MACI presumes an identity system where each legitimate member
|
|
104
104
|
controls a unique private key - MACI does not specifically solve for this, but allows for customization on how this is configured.
|
|
105
105
|
|
|
106
|
+
#### Poll Joining
|
|
107
|
+
|
|
108
|
+
Once a user has signed up with MACI, they can join open polls by passing any poll specific gatekeeping requirements, as well as providing a zero knowledge proof that they know the private key to their previously signed up MACI public key.
|
|
109
|
+
|
|
110
|
+
This step must be repeated for each poll that the user wishes to vote on, and will allow them to receive voting power specific to that poll.
|
|
111
|
+
|
|
106
112
|
#### Vote
|
|
107
113
|
|
|
108
|
-
|
|
114
|
+
After joining a poll, a user can cast a vote by sending a message to the Poll contract.
|
|
109
115
|
|
|
110
116
|
To cast a vote, a user will bundle a few variables — including a public key, their vote option, their vote amount, and a few others — into what is called a "command". Then, the user signs the command with the private key they originally used to sign up. After that, the user encrypts the signature and command together so that it is now considered a "message". If the command is properly signed by the user’s MACI public key, then the message is considered valid will be counted in the final tally. Therefore, the MACI public key can be thought of as the user’s voting username, and the signature is the voting password. If they provide the correct signature, they can submit a vote.
|
|
111
117
|
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
{
|
|
2
|
+
"label": "Coordinator Service",
|
|
3
|
+
"position": 1,
|
|
4
|
+
"link": {
|
|
5
|
+
"type": "generated-index",
|
|
6
|
+
"description": "The Coordinator Service is a backend service that aims to automate MACI-related operations, such as contracts deployment, proof generation and poll finalisation."
|
|
7
|
+
}
|
|
8
|
+
}
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Introduction
|
|
3
|
+
description: The Coordinator Service is a service that allows to automate MACI coordinator tasks.
|
|
4
|
+
sidebar_label: Introduction
|
|
5
|
+
sidebar_position: 1
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Coordinator Service
|
|
9
|
+
|
|
10
|
+
Welcome to the Coordinator Service technical reference. Here you will find the technical details of the Coordinator Service, including the API endpoints and code examples.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Installation and setup
|
|
3
|
+
description: Learn how to install and setup the Coordinator Service.
|
|
4
|
+
sidebar_label: Installation
|
|
5
|
+
sidebar_position: 2
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
1. Add `.env` file (see `.env.example`).
|
|
9
|
+
2. Generate RSA key pair with `pnpm run generate-keypair`.
|
|
10
|
+
3. Download zkey files using `pnpm run download-zkeys:{type}` (only test type is available for now).
|
|
11
|
+
4. Make sure you copied RSA public key to your application. This will be needed for encrypting `Authorization` header and coordinator private key for proof generation. Also it can be accessed through API method `GET v1/proof/publicKey`.
|
|
12
|
+
5. Run `pnpm run start` to run the service.
|
|
13
|
+
6. All API calls must be called with `Authorization` header, where the value is encrypted with RSA public key you generated before. Header value contains message signature and message digest created by `COORDINATOR_ADDRESSES`. The format is `publicEncrypt({signature}:{digest})`.
|
|
14
|
+
Make sure you set `COORDINATOR_ADDRESSES` env variable and sign any message with the addresses from your application (see [AccountSignatureGuard](./ts/auth/AccountSignatureGuard.service.ts)).
|
|
15
|
+
7. Proofs can be generated with `POST v1/proof/generate` API method or with Websockets (see [dto spec](./ts/proof/dto.ts), [controller](./ts/app.controller.ts) and [wsgateway](./ts/events/events.gateway.ts)).
|
|
16
|
+
|
|
17
|
+
## Subgraph deployment
|
|
18
|
+
|
|
19
|
+
It is possible to deploy subgraph using coordinator service.
|
|
20
|
+
|
|
21
|
+
First, you need to setup subgraph and create a project. [Subgraph dashboard](https://thegraph.com/studio/).
|
|
22
|
+
|
|
23
|
+
Then, set env variables:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
# Subgraph name
|
|
27
|
+
SUBGRAPH_NAME="maci-subgraph"
|
|
28
|
+
|
|
29
|
+
# Subgraph provider url
|
|
30
|
+
SUBGRAPH_PROVIDER_URL=https://api.studio.thegraph.com/deploy/
|
|
31
|
+
|
|
32
|
+
# Subgraph deploy key
|
|
33
|
+
SUBGRAPH_DEPLOY_KEY=*******
|
|
34
|
+
|
|
35
|
+
# Subgraph project folder
|
|
36
|
+
SUBGRAPH_FOLDER=../subgraph
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
After deployment, subgraph url will be available in studio dashboard and you can use this type of url to get latest deployed version in your application:
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
https://api.studio.thegraph.com/.../{SUBGRAPH_NAME}/version/latest
|
|
43
|
+
```
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Introduction
|
|
3
|
+
description: The Offchain Relayer is a service that allows users to vote on MACI polls free of charge.
|
|
4
|
+
sidebar_label: Introduction
|
|
5
|
+
sidebar_position: 1
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Coordinator Service
|
|
9
|
+
|
|
10
|
+
Welcome to the Offchain Relayer technical reference. Here you will find the technical details of the Offchain Relayer: how to set it up and and how to use it.
|
|
11
|
+
|
|
12
|
+
## Flow Diagram
|
|
13
|
+
|
|
14
|
+
Below is a high-level diagram illustrating the flow of the Relayer Service:
|
|
15
|
+
|
|
16
|
+

|
|
17
|
+
|
|
18
|
+
## High-Level Overview of the Relayer:
|
|
19
|
+
|
|
20
|
+
### Functionality
|
|
21
|
+
|
|
22
|
+
The Relayer serves as an intermediary between users and the MACI system. It performs the following tasks:
|
|
23
|
+
|
|
24
|
+
- Allows users to send messages without having to pay gas fees by processing these messages off-chain.
|
|
25
|
+
- Receives user messages.
|
|
26
|
+
- Prepare messages batches and upload it to IPFS
|
|
27
|
+
- Submits the message hashes to the Poll contract with IPFS hash of the batch.
|
|
28
|
+
|
|
29
|
+
This process ensures that user actions are recorded on-chain without compromising their privacy.
|
|
30
|
+
|
|
31
|
+
### Privacy Preservation
|
|
32
|
+
|
|
33
|
+
By verifying the zero-knowledge proofs, the Relayer ensures that only authorized users can send messages.
|
|
34
|
+
Users must know the pre-image to a state leaf in the poll state tree.
|
|
35
|
+
|
|
36
|
+
### Decentralization and Trust
|
|
37
|
+
|
|
38
|
+
It's recommended that the coordinator only runs this service for now. That is because if the service malfunctions and batch hashes are pushed on chain without the messages actually being stored on ipfs, then polls can't be finalized.
|
|
39
|
+
|
|
40
|
+
### Integration with MACI Components
|
|
41
|
+
|
|
42
|
+
The Relayer interacts with other components of the MACI system, such as the **Coordinator** and the on-chain smart contracts:
|
|
43
|
+
|
|
44
|
+
- The **Coordinator** fetches all the messages stored in IPFS and uses them as regular on-chain messages.
|
|
45
|
+
- This ensures that user messages are properly processed and recorded, contributing to the overall functionality and security of the voting protocol.
|
|
46
|
+
|
|
47
|
+
### Additional Information
|
|
48
|
+
|
|
49
|
+
For more details, you can read the following post on EthResearch:
|
|
50
|
+
|
|
51
|
+
[MACI with Mostly Off-Chain Happy Path](https://ethresear.ch/t/maci-with-mostly-off-chain-happy-path/19527)
|
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Installation and setup
|
|
3
|
+
description: Learn how to install and setup the Offchain Relayer service.
|
|
4
|
+
sidebar_label: Setup
|
|
5
|
+
sidebar_position: 2
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Prerequisites
|
|
9
|
+
|
|
10
|
+
Make sure you have the following tools installed on your system:
|
|
11
|
+
|
|
12
|
+
- **Docker**: [Install Docker](https://www.docker.com/products/docker-desktop)
|
|
13
|
+
- **Docker Compose**: [Install Docker Compose](https://docs.docker.com/compose/install/)
|
|
14
|
+
|
|
15
|
+
## Getting Started
|
|
16
|
+
|
|
17
|
+
Follow these steps to run the MACI Relayer service using Docker.
|
|
18
|
+
|
|
19
|
+
### 1. Clone the Repository
|
|
20
|
+
|
|
21
|
+
First, clone the repository to your local machine.
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
git clone https://github.com/privacy-scaling-explorations/maci
|
|
25
|
+
cd maci
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
## 2. Configure Environment Variables
|
|
29
|
+
|
|
30
|
+
The `.env` file contains sensitive configuration values that will be injected into the Docker containers at runtime. To set them up:
|
|
31
|
+
|
|
32
|
+
1. Copy the `.env.example` file to `.env`.
|
|
33
|
+
|
|
34
|
+
```bash
|
|
35
|
+
cp .env.example .env
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
2. Edit the `.env` file and configure the variables.
|
|
39
|
+
|
|
40
|
+
## 3. Build and Run the Docker Containers
|
|
41
|
+
|
|
42
|
+
Now that your environment is set up, it's time to build and run the Docker containers.
|
|
43
|
+
|
|
44
|
+
Run the following command from the root directory of your project:
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
docker-compose up --build
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
This command does the following:
|
|
51
|
+
|
|
52
|
+
- Builds the Docker images based on the Dockerfile and `docker-compose.yml` files.
|
|
53
|
+
- Starts the service container (the MACI relayer application) and the mongodb container.
|
|
54
|
+
|
|
55
|
+
The MACI Relayer service will be available on port 3000 by default (you can modify this in the `.env` file).
|
|
56
|
+
|
|
57
|
+
## 4. Access the Service
|
|
58
|
+
|
|
59
|
+
Once the containers are up and running, you can access the relayer service at:
|
|
60
|
+
|
|
61
|
+
```
|
|
62
|
+
http://localhost:3000
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
Additionally, the Swagger UI documentation for the Relayer service API can be accessed at:
|
|
66
|
+
|
|
67
|
+
```
|
|
68
|
+
http://localhost:3000/api
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
You can interact with the API through the Swagger interface, which provides a convenient way to test endpoints and view the API methods.
|
|
72
|
+
|
|
73
|
+
## 5. Check Logs
|
|
74
|
+
|
|
75
|
+
To view the logs from the containers and troubleshoot any issues, run:
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
docker-compose logs
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
This will display logs from both the service (relayer) and mongodb containers.
|
|
82
|
+
|
|
83
|
+
## 6. Stop the Services
|
|
84
|
+
|
|
85
|
+
To stop the containers and remove the containers (but keep the volumes), use the following command:
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
docker-compose down
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
This will stop and remove the containers but retain the volumes (like MongoDB data). To also remove the volumes, run:
|
|
92
|
+
|
|
93
|
+
```bash
|
|
94
|
+
docker-compose down --volumes
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
## 7. MongoDB Persistence
|
|
98
|
+
|
|
99
|
+
MongoDB data is persisted using Docker volumes (`mongodb-data`). Even if you remove and recreate the MongoDB container, the data will persist.
|
|
100
|
+
|
|
101
|
+
This ensures that any data stored in the MongoDB database is not lost even if the container is restarted or removed.
|
|
102
|
+
|
|
103
|
+
If you'd like to remove the persisted data as well, you can remove the volume by running:
|
|
104
|
+
|
|
105
|
+
```bash
|
|
106
|
+
docker volume rm your-repo_mongodb-data
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
This will delete the volume, along with all the data stored in MongoDB.
|