Skip to main content

2 posts tagged with "community"

View All Tags

Getting Started with MACI

· 7 min read
Crisgarner
MACI team contributor

Hey folks! We’re thrilled to kick off a series of tutorials covering everything you need to know about MACI. This guide will focus on installing MACI and deploying the contracts to a testnet. Let’s get started!

Understanding Roles

MACI protocol has two main roles, User (Voter) and Coordinator. A simplified version would be to say that the coordinator is in charge of deploying the MACI smart contracts, initiating the polls, tallying the final results of a vote, and finalizing polls by publishing the final results on-chain. Usually the contract deployer is the coordinator, but this can be a separate entity.

Requirements

Let's install the required tools first:

  • Node.js: use a JS toolchain manager like nvm or volta to install Node.js. We recommend using Node 20 or above.
  • pnpm: Fast, disk space efficient package manager.

Installation

Now you can run the following commands to install MACI locally:

git clone https://github.com/privacy-scaling-explorations/maci.git && \
cd maci && \
git checkout v2.5.0 && \
pnpm i && \
pnpm run build
note

Unless you are looking to contribute to the MACI codebase, we suggest you use the latest released version. You can check all the releases here.

Download the zero knowledge artifacts

MACI has two main zk-SNARK circuits, and each of them is parameterized. There should be one .zkey file for each circuit and set of parameters.

Unless you wish to generate a fresh set of .zkey files, you should obtain them from someone who has performed a multi-party trusted setup for said circuits. For more details on which artifacts have undergone a trusted setup, please refer to the Trusted Setup page.

important

Note the locations of the .zkey files cause you will need it when deploying contracts. (put in the deploy-config.json)

Download test artifacts

For all but production use cases, we suggest using the test artifacts, with the latest dev code, you can download them by running:

pnpm download-zkeys:test

Download ceremony artifacts

For production you need to use the ceremony artifacts which have undergone a trusted setup, you can download them with the command:

pnpm download-zkeys:ceremony
info

Currently, the ceremony artifacts work with MACI version up to 2.x

Deploy Contracts

Before deploying the contracts we need to do some final configurations to our repository.

Set the environment variables

Head to the packages/contracts folder and copy the .env.example file.

cd packages/contracts && \
cp .env.example .env

Make sure to include a mnemonic and RPC url (make sure to replace NETWORK with the network you want to use).

MNEMONIC = "your ethereum secret key";
NETWORK_RPC_URL = "the eth provider url";
NETWORK_ETHERSCAN_API_KEY = "etherscan api key";

Generate Coordinator Keys

In order to run MACI polls, a coordinator is required to publish their MACI public key. You will need to generate a MACI keypair, and treat the private key just as your ethereum private keys. Please store them in a safe place as you won't be able to finish a round if you lose access, or if compromised a bad actor could decrypt the vote and publish them online. You can generate a new key pair using maci-cli by running the following commands:

cd packages/cli && \
node build/ts/index.js genMaciKeyPair

Set the configuration file

note

There are already some deployed contracts that could be reused. More information can be found in the (incremental documentation page)[docs/getting-started#deploy-maci-contracts].

Head back to the contracts folder and copy the config example and update the fields as necessary:

cd ../contracts && \
cp deploy-config-example.json deploy-config.json

ConstantInitialVoiceCreditProxy

Defines how many credits will get each voter.

Gatekeeper

MACI uses a "gatekeeper" contract to configure and enforce the eligibility criteria of voters who can participate in MACI polls. In other words, it is a way to allowlist signups to the system to protect against sybil attacks. Please refer to the gatekeeper page in the documentation for more information on the supported Gatekeepers.

important

For testing we suggest using the FreeForAllGatekeeper as it allows anyone to signup on MACI.

MACI

This property defines which Gatekeeper and stateTreeDepth MACI is going to use. The stateTreeDepth defines how many users the system supports.

important

The stateTreeDepth value for test artifacts is: 10. For ceremony keys: 14.

VkRegistry

The VkRegistry hold the verifying keys used to verify the proofs, on the zkeys field we define the path to the zero knowledge artifacts we downloaded in the previous steps.

important

The values for test keys are: 10-1-2-2-1. For ceremony keys: 14-5-9-3-2.

Poll

Configures the poll duration in seconds, determines whether quadratic voting is enabled, and sets the public key of the Coordinator.

Deploy MACI Contracts

To deploy the MACI contracts to a specific network you can append :network to the deployment commands, e.g. pnpm deploy:sepolia - please refer to the supported networks documentation page to see all available networks.

pnpm deploy:NETWORK

Deploy Poll

Before deploying a Poll, make sure you have set the coordinator MACI public key to which you own the private key. To deploy your first Poll you can run the following command:

pnpm deploy-poll:NETWORK
important

Starting another poll doesn't require deploying MACI contracts again, you can run pnpm deploy-poll:NETWORK command and then use the new poll-id.

Poll Finalization

As a coordinator, first you need to merge signups and messages (votes). Messages are stored in a queue so when the poll is over, the coordinator needs to create the merkle tree from the queue (AccQueue). This optimization is needed to reduce gas cost for voters. Then the coordinator generates proofs for the message processing, and tally calculations. This allows to publish the poll results on-chain and then everyone can verify the results when the poll is over. You run a merge with:

pnpm merge:[network] --poll [poll-id]

Then you need to generate the proofs with the following command:

pnpm run prove:[network] --poll [poll-id] \
--coordinator-private-key [coordinator-maci-private-key] \
--tally-file ../proofs/tally.json \
--output-dir ../proofs/proofs/ \
--start-block [block-number] \
--blocks-per-batch [number-of-blocks]
important

You can reduce the time of the proving by including more blocks per batch, you can try with 500.

Submit On-chain

Now it's time to submit the poll results on-chain so that everyone can verify the results:

pnpm submitOnChain:[network] --poll [poll-id] \
--output-dir proofs/ \
--tally-file proofs/tally.json

Tally

Once the proofs are generated, and results tallied, the results (Tally) are written to a file. Let's take a look at one:

{
"maci": "0xd54b47F8e6A1b97F3A84f63c867286272b273b7C",
"pollId": "0",
"network": "localhost",
"chainId": "31337",
"isQuadratic": true,
"tallyAddress": "0xD4fbAF1dFe100d07f8Ef73d8c92e93d0Bcf7b45D",
"newTallyCommitment": "0x2f55cc85f7f141098ba791a9f6a646f8773b9bb4f5852ccc33b5a28e7b0756e5",
"results": {
"tally": [
"9",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0"
],
"salt": "0x2e9cd240b86cf456fa4deced8e7420c45e3c16941d2dcec308f8b6d48264dda3",
"commitment": "0x296eac2a7289974f23497bebd39e86599d0b7032796fb84dcc1f6bbda38262ca"
},
"totalSpentVoiceCredits": {
"spent": "81",
"salt": "0x24f57b75c227987727c13d1e83409d70478b42bdc12a4a4df8129c72fbaf5aaf",
"commitment": "0xb4ebe68b0da828c0b978ddee86ba934b8e215499ac766491f236ad85fd606de"
},
"perVOSpentVoiceCredits": {
"tally": [
"81",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0",
"0"
],
"salt": "0x2590434ea2d600f7bd2396ba7fa454ad4c975c29424ee481561d9786538a5e48",
"commitment": "0x54ec996599886da21c4b07c25d1de544292a8b7c38b79726995c869c9e95db"
}
}

We observe an array named results, which holds the aggregated votes for each option. Each option corresponds to an index in the array. In the example above, the first option (index 0) received a total of 9 votes, while all other options received no votes

The totalSpentVoiceCredits object contains the total amount of voice credits spent in the poll. This is the sum of all voice credits spent by all voters, and in quadratic voting, is the sum of the squares of all votes.

The perVOSpentVoiceCredits will contain the amount of voice credits spent per vote option. In this case, the first option received 81 voice credits, and every other option received 0 voice credits. This is because there was only one valid vote casted, with a weight of 9. Given the quadratic voting formula, the total amount of voice credits spent is 81.


That should be all for this tutorial, feel free to join our discord for any questions or recommendations, and feel free to read our documentation for more in depth resources.

The birth of MACI Platform

· 6 min read
ctrlc03, Doris, Hodlon
MACI team members

MACI Platform - an exciting evolution for MACI

Hey folks, welcome to another update from the MACI team! Today we are excited to officially announce MACI Platform, a comprehensive platform that enables secure voting for all kinds of use cases and communities.

MACI Platform began as a fork of easy-retro-rpgf with the MACI protocol integrated. We called it “MACI-RPGF”, and it provided a base product that could run retroactive public goods funding with privacy and anti-collusion properties.

Moving forward, the plan is to add even more features over time to fulfill a vision of the ultimate platform for super secure voting and funding that communities can easily deploy.

Overview

The platform is composed of three components:

  • A web interface for both voters and round organizers to interact with the contracts.
  • The MACI Platform smart contracts, an extended set of the MACI smart contracts that include registries for projects and fund disbursement features.
  • The Coordinator service allows for the complete automation of MACI.

MACI Platform Audience

MACI Platform is designed for a wide range of use cases: public goods funding, hackathon judging, grant making, community governance, and even state elections, to name a few. At its core, the product consists of three types of users: the Round Operator (the host of a voting round), the Applicant (those wishing to submit an application for inclusion in the round), and a subset of members that are allowed to participate in that voting round, or the Voters.

Having worked with the MACI protocol for years, we understand the ins-and-outs of its implementation and usage, and believe it is a powerful tool for creating a more democratic approach to building consensus within groups of people. However, we also understand that the user experience of MACI in its current implementation is far from accessible to many people. For this reason, MACI Platform is being built to be as easy and intuitive as possible for anyone to use.

The Vision

The vision for MACI Platform is to provide a clean and simple interface for communities to run different types of secure, anti-collusion voting and funding rounds.

While the current implementation of the platform is only built for the public goods funding use case, there are plans to focus on governance and local elections in the coming year.

From the operator’s perspective, our goal is to allow the creation of a round in less than 10 minutes. This includes setting up MACI contracts and creating a voting or funding round. All the information required to customize the round will be input through the frontend, and by passing it to the backend (the MACI coordinator service), all the necessary contracts will be deployed.

Projects applying to be part of a round can submit the required information via a form, which will be customizable by the round operator to include all required and relevant information for that specific round. Approvals of those projects will be at the discretion of the operators.

Finally, users/voters will be able to access the voting rounds only if they pass the gatekeeping requirements. Currently, it is possible to gate voting rounds using different strategies:

  • allowing anyone to participate
  • accepting only users with a certain EAS attestation
  • accepting only users part of a Semaphore group
  • accepting only users with a certain Hat
  • accepting only users with a certain Zupass credential

...and many more to come. Please refer to MACI’s gatekeeper page

Roadmap

What have we built so far? As of now, we have just released a version 1. This release focuses on voter and applicant project experience, enabling them to interact smoothly with the platform by signing up, submitting applications, and voting. Finally, users can also see results once the votes have been tallied by the coordinator.

V2 on the other hand, will focus on the round organizer experience. At a high level, the core devs are focusing on implementing the following features:

  • Dashboard for contract deployment and round configuration
  • Allowing multiple rounds to live within one MACI Platform instance
  • Payout disbursement via the interface by either the voters, applicants, or operators
  • Full integration with MACI’s coordinator service to allow finalization of rounds within the interface
  • Continued integration with different gatekeepers like Gitcoin Passport

Furthermore, we plan to experiment with AA (account abstraction) to enable smooth experiences for both users and organisers. For users, we have implemented an end-to-end flow using an embedded wallet and paymaster as part of PSE’s internal hackathon, as well as for the Devcon round. For organizers we will be using a smart account and session keys to safely interact with the coordinator service and interact with MACI contracts.

Ecosystem Harmony

Projects like Gitcoin, Dorahacks, Snapshot, Devfolio, and Jokerace all seem to offer very similar voting, polling, and quadratic funding solutions. So what makes MACI different?

At MACI, our goal isn’t to compete, but to help push the ecosystem toward using safer, more private, and collusion-resistant voting mechanisms. We're actively working with many of the above projects to integrate the MACI protocol, ensuring that the benefits of secure voting can be used where they’re needed most. MACI Platform presents itself as just one more quadratic funding platform for communities to choose from.

It's important to note that while the anti-collusion properties of MACI provide higher security guarantees, they do come with tradeoffs— particularly in terms of user experience (UX), cost, and simplicity. The MACI team is continuously working to address these tradeoffs, but for certain use cases, these tradeoffs may not be worthwhile. For example, the encryption of votes at the end of a round may not actually be desirable or aligned with the spirit or values of any specific community. MACI Platform aims to provide privacy solutions where they’re needed the most, and to augment and support existing voting platforms.

How to get involved

If you are a community event organizer and want to run a voting or funding round using MACI Platform, please reach out to us using this form. If you are a developer and want to contribute to the code then head over to our GitHub repo and take a look at the “good first issues” tags, or open a new one that you think it’s beneficial and you would like to work on.

Also, stay tuned for recurring voting rounds on demo.maci.vote and our participation in hackathon as sponsors.

References