2 posts tagged with "development"

Greetings anon, it’s been a while.

We’re excited to share with you what we're planning to build over 2025. Yes, we know it’s already March, so let’s start with a recap of what the team has been up to in the recent months, before moving to what’s up next.

MACI Coordinator service​

We are happy to announce that we completed the work on developing a service to automate MACI coordinator functionality. This includes:

• Contract deployment
• Subgraph deploying
• Proof generation
• Proof and results submission

This server exposes a REST API, as well as some Websocket endpoints (for proof generation only). We soon will publish a detailed guide on how to use, and how to integrate it via its SDK -stay tuned for a separate blog post.

For anyone interested in the code, you can find it here.

MACI Offchain voting support​

After Vitalik’s post original idea, the team worked on an implementation of offchain voting for MACI. This comes in the form of a relayer service, which can be run by the coordinator to support offchain vote submission, effectively reducing the cost for users to only the signup transaction.

In the future we plan to research how to extend support to signups too.

In a nutshell, the service exposes a REST API that allows voters to submit MACI messages, they only need to prove that they are signed up by posting a zk proof to avoid spam on the service. The coordinator will wait for batches of n messages to be collected, then post the hashes of the messages to the Poll smart contract, alongside an IPFS hash where these messages are stored. This allows to keep costs down for coordinators, as they would only need to post the message hashes compared to relaying message by message and hashing them on-chain. At the same time, users can vote for free, and if they do believe they have been censored, for instance they do not see their vote on the IPFS file, they can go directly on-chain and use MACI as normal.

It should be noted that at this time, using this feature might result in failure if either of the two are true:

• The coordinator calls relayMessagesBatch with invalid message hashes (there is no corresponding message on IPFS or local relayer storage)
• The coordinator posts message hashes on chain before they are stored on IPFS and local storage is lost

While both of these result in a liveness issue, MACI does not provide liveness guarantees either way, as in its current form the coordinator could choose to not complete a poll, and no one else would be able to process votes on their behalf. We will be looking to improve on this guarantees in out future work.

MACI v3​

We are very close to completing a new version of MACI - v3. This new version comes with features that have been requested in the past, such as polls being more customisable, in terms of voice credits assigned to voters, and gatekeeping mechanisms.

At a high level, the new features/improvements are:

1. Custom voice credits per poll
2. Custom gatekeeping per poll
3. Replacement of vote merkle trees for more efficient hash-chains

Up until now, MACI has not prioritised reusability of the smart contracts. More often than not, production votes using MACI relied on deploying new instances of the main MACI smart contract, resulting in users joining with a new set of keys every time. This by consequence results in these keys not holding more value than a single vote, thus enabling key selling. With this new version, we envision a single MACI smart contract to be the entry point for several polls, where voters are “forced” to signup to individual polls with the same key that they used to signup to the main smart contract. In production use cases, this could be follow this script:

1. The main MACI contract is set to gatekeep access using a very strong sybil mechanism, such as proof of passport
2. Users signup by proving they are human
3. For each poll that is created, voters can join with the same key if they wish to participate and if they can pass the specific poll gatekeeping requirements. For instance a specific poll might allow only Indian voters, thus use a Anon Adhaar policy to gate access

User research​

In order to inform MACI’s future roadmap and which use cases to tackle, we started to conduct user research. MACI has been historically used only in public goods funding, via protocols such as clr.fund, QFI, Gitcoin’s Allo stack, and MACI Platform. As we see a diminished interest and need for private voting in public goods funding, we decided to focus on a new use case which clearly has a larger demand for MACI - governance.

While still in the early discovery phase, we identified demand for MACI to be integrated into DAO governance protocol stacks like Aragon’s OSX in the form of a plugin. We are aiming to build a demo plugin and showcase it to Aragon in the coming months.

We hope to partner with several governance providers to enhance your voting offerings through modules/plugins.

2025 - What will we focus the rest of the year​

For this year, we plan to tackle a few different epics:

1. Release of MACI v3
2. Begin work to decentralize the coordinator using either homomorphic encryption or collaborative SNARKs
3. Integrate MACI into Aragon OSX’s stack
4. Continue with user research

MACI v3

We have just talked about MACI v3, so what is left to add is that we will be looking to complete the documentation updates, clean up the code and release it as soon as possible. Get ready for an even better version of MACI, and please reach out if you would like to integrate v3, we are here to support.

What about coordinator decentralisation?

That sounds interesting.. Let’s talk about that.

One of MACI long standing issues has been the privileges that the coordinator role has. They are able to see all of the votes in cleartext, which allows them to collude with bribers themselves, as well as voters. As we look to tackle use cases such as DAO governance where lot of money is involved in proposals, we need to ensure that collusion between the coordinator and voters/bribers is reduced. This can be accomplished in several ways:

• Use Multi Party Computation (MPC)
• Use Homomorphic Encryption (HE)
• Use a Trusted Execution Environment (TEE)

Without going into much details here (keep an eye out for a separate post), to actually decentralise the coordinator role we will need either MPC (in the forms of co-SNARKs) or HE. The team is researching the available technologies to come up with a proposal on how to tackle this problem. We are very excited to improve MACI’s security and bring an even better primitive to projects that want private and secure voting.

Integrating MACI into the Aragon OSX stack

After some discussion with Aragon, we decided to build a demo to showcase how MACI could be used in DAOs created using Aragon’s OSX stack.

The goal is to get a working demo in the coming months that allow to create new voting proposals where DAO token holders can vote Yes, No, or Abstain. At this time, we will be making a very simple integration, and in the future we plan to integrate some features into the MACI protocol which would make it more suited for DAO governance, such as:

• Have a custom type of polls where one can only vote with all of their voting power (currently there is no option to restrict this and voters can allocate their voting power as they prefer across several available options)
• Count the number of votes for each option (currently this is not possible, the coordinator would need to provide this information, without a way to prove its correctness)

Once the demo is out and some DAOs test it out, we look forward to preparing this to be production ready and target running some DAO voting, from a supportive perspective.

You can track progress of development on this repo.

Continue with user research

While we have identified a new use case to tackle, governance, we still want to continue speaking with different projects and individuals to learn even more where can provide value in the short, and long term.

We have identified some projects that we want to chat with, however are open to suggestion - know anyone that is interested in private and anti collusion voting? Introduce them to us to help us understand how we can help democracy thrive.

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

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.

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

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​

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.

MACI​

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

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.

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

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]

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.