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.

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​

• easy-retro-rpgf
• clr.fund
• maci
• maci-platform
• EAS
• Semaphore
• Hats Protocol
• Zupass

Glad to have you here! It's again that time where we have a few MACI roadmap updates to share.

We’re going to take a moment to look at what we accomplished in Q3, but before we start, we would like to express our gratitude to all our collaborators and contributors to the MACI protocol.

MACI Platform ✅​

This quarter, the team continued to focus on building a comprehensive voting platform with MACI. The platform is now turning into an all-in-one solution for voting, quadratic funding, and RPGF rounds. We made the product much more stable by fixing several bugs, and plan on integrating many more features in the future.

In terms of current features, the platform supports these gating mechanisms:

• Semaphore
• Hats Protocol
• Free for all (ie, anyone can join)
• EAS
• Merkle proof
• Zupass

It now also possible to run quadratic and non quadratic voting rounds, as well as running sequential rounds on the same interface. Soon you will also be able to run multiple concurrent rounds.

With the MACI Platform, we were able to support three community rounds, EthMexico, EthTegucigalpa, and Cryptoversidad. All rounds completed successfully with nearly $30,000.00 distributed to several projects and individuals across the three communities. We also received a lot of great feedback that helped improve the platform overall. We couldn’t be happier to work with such wonderful collaborators and help them make a real world impact.

As always, if you're interested in running a round for your community, please get in touch

Coordinator Service ✅​

The Coordinator Service is the ultimate automation of MACI’s main pain-points. It now includes three new features for the frontend interface to provide a very neat experience to MACI operators.

Because we prioritise robust security features whenever possible, the service does not hold any wallet seed phrase to communicate with the various chains. Instead, we implemented a flow that uses ephemeral session keys for short lived approvals, greatly decreasing the impact of a key compromise. This is all possible thanks to account abstraction features such as session keys.

With the flow described above, we implemented a deployer service to easily deploy all needed MACI contracts, as well as an endpoint to merge the MACI state and message trees, an important step required to be able to tally the results.

Account Abstraction Exploration ✅​

Together with a fellow PSE team developer, John, the MACI team is working on a fork of the MACI platform that implements account abstraction features, such as smart wallets and paymasters.

This fork was used in PSE’s first internal hackathon, and allows PSE and EF team members to vote on their favourite hackathon project without spending a single cent from their wallet onchain.

This was a successful experiment that will prove fundamental in our future efforts to improve the MACI platform and make it even more accessible to a general “non crypto native” user base.

Stay tuned for a case study of this experiment!

MACI Protocol Improvements ✅​

The 3327 team successfully completed their Anonymous Poll Joining grant. This work enabled unconditional voter privacy, further strengthening user privacy in the protocol. For more details, please refer to their blog post.

With regard to implementing Vitalik’s latest MACI proposal Mostly Offchain Happy Path, we have not been able to start due to other priorities, however we have defined the tasks required and unblocked the epic by implementing the session keys flow on the coordinator service, so that it can be re-used for a secure relayer service.

In terms of developer experience, we always try to make it easier to onboard new developers to the protocol. As a result, we have been making improvements to the deployment tasks, documentation and smart contracts code. Now developers can more easily override deployment steps to integrate MACI's smart contracts into their own projects; and can extend smart contract functions to support custom logic.

Finally, our internal team has also been brainstorming features and improvements for MACI v3, however no plan is set in stone yet. Stay tuned for more.

Why poll joining?​

In the original version of the MACI protocol, one state tree stored information about all registered users, their public key, number of credits, and registration timestamp. Users could vote using encrypted messages and change keys to mitigate potential bribes. However, the coordinator could still decrypt messages and track key changes. Even if the key was changed and the bribed users could cancel their previous votes by voting with their new key, the coordinator could still trace back the key-changing messages and determine the true votes of the bribed users. To remove the link between the original public key and the new, changed public key, we've implemented El Gamal modification of the protocol. This modification worked, but it was expensive from the contract side and introduced a big overhead to the protocol in general.

Even if the El Gamal modification was not the most efficient one, it pointed in the right direction where each user should get a new key for each poll and hide the link with their original key using ZK proofs. That is why we decided to follow that path and improve the protocol further. We introduced a new concept of poll joining.

What is poll joining?​

Poll joining represents a protocol change where each poll contains its own poll state tree that stores the keys of users who want to vote on that poll. The users join the poll by providing a new key that they will use in that specific poll. But wait, then anyone can create as many keys as they like and vote many times so we lose everything? Not really. The users submit their new public key and ZK proof that they own some key in the original MACI state tree. That way, only registered users can join the polls without revealing the link between the old and the new key. To prevent multiple joins, the user also provides a nullifier - computed as a hash of their private key. The submitted ZK proof also verifies that the nullifier is correctly computed from the same private key associated with the public key in the original MACI state tree. On the smart contract side, the user is prevented from joining the poll with an already spent nullifier.

What if some users have a very specific number of credits so they reveal themselves by giving the same number of credits to a new key? We have a solution for that also. The users submit their new desired credit balance which has to be less than or equal to their credit balance associated with the original key in the MACI state tree. The submitted ZK proof also verifies that this condition is valid. Furthermore, a poll can be created so that it sets balances for all keys to a constant value, completely keeping anonymity.

How does poll joining affect the protocol?​

The poll joining does introduce one extra step for the user. Besides that, all functions and circuits on the coordinator's side remain intact. However, poll joining introduces new interesting features for the MACI as it enables putting various conditions on who can join the poll and how their credits are transformed in each poll. Some polls may require a minimum number of credits for joining, others may put a cap on the number of credits to be spent in a poll. The new dynamics open a new world of possibilities for future updates. But wait, there is more!

What else was improved?​

Besides poll joining we have introduced a new feature that drastically lowered the overall cost of the protocol. Before we reveal what was the upgrade, we should first recap how the protocol worked in the original version, specifically the message processing. In the original protocol, users submitted their messages to the Poll smart contract. Each message was stored in a smart contract Merkle tree, the accumulator queue to be precise. At the end of the voting period, the coordinator had to merge the message tree by sending multiple merging messages for data structure subtrees so the final message root could be computed. When the message route was computed, the coordinator used inclusion proofs in the message processing circuit to prove that each processed message was indeed found in the message tree. This sounds like a really expensive procedure - because it was. Let's analyze what could be improved.

First, all messages need to be processed in the same order that they were submitted to the poll contract. Using a tree structure and inclusion proofs does indeed prove that, but if there only was a data structure that maintains the order of items in a given immutable order? Yes, you guessed it, it is Blockchain. Each block in the chain stores an immutable reference to a previous block, keeping the order. It sounds like we have to make the message object even more complex and keep the reference to the previous message, but that is not the way. We can start with a random value, a hash of an initial string, and call it a chain hash. When there are no messages, the chain hash keeps the initial value. Once a new message comes to the poll, we can compute the message hash (already done for the message tree in the original protocol) and update the chain hash to a hash value of the current chain hash and newly received message hash. Formally, $chainHash_i = hash(chainHash_{i-1}, messageHash_i)$

Second, the coordinator collects all messages from the smart contract events, so why should we explicitly store messages in the smart contract? With the chain hash approach - we don't. When the coordinator is processing messages, the only important thing for making sure that the messages are properly ordered and all messages are included is to check that the chain hash is correctly computed. Starting with an initial chain hash value we can process messages and incrementally update the chain hash in the circuit ending up with a value that has to match the last chain hash value in the smart contract. To optimize this procedure for batch message processing, we explicitly store chain hashes for each batch in the smart contract and verify the batch processing by submitting the chain hash values before and after the message batch. We can dynamically set the size of the batch, thus the number of stored batch chain hashes, based on the coordinator's processing power.

How efficient is this?​

We removed the entire message accumulator data structure that had exponential space complexity in the number of messages and introduced batch chain hashes of a linear space complexity with a constant of less than one. That resulted in removing the entire message merging step, executed multiple times until the tree was merged. We kept the high level of user anonymity but without the large overhead of the El Gamal approach. We have maybe introduced one extra step for the user to join the poll, but we also removed many steps of message processing and drastically lowered the costs for the coordinator. Not bad.

What is next?​

We are not stopping here, more interesting protocol upgrades are on the way that would improve the security of the protocol even further and eliminate another significant concern. Be patient, and enjoy the privacy!

Who are we?​

Visit 3327.io and find out. Special kudos to our Mihailo Radojević and Boris Cvitak who did a lot of heavy lifting so these cool features could be here today!

We are pleased to announce the release of MACI v2.0.0!

This is our second big release of the year, after the MACI v1.2 release in February of this year. MACI v2.0 brings a more secure and efficient protocol, with improved developer experience, and clearer documentation for users looking to learn about and use MACI.

Background​

MACI - Minimal Anti-Collusion Infrastructure - is an application that provides privacy and collusion resistance for on-chain voting. If you're new to MACI, we first recommend reading our documentation for background information and technical details.

New Features and improvements​

More compact codebase​

We have removed some features that were never used in production, namely Topup and Subsidy. This allowed us to reduce the codebase size, making it cheaper to deploy, as well as reducing the complexity of the zk-SNARK circuits.

We highly thank Chao for his work on these two features over the past years, and look forward to integrating similar features in the future as we come up with new use cases and performance improvements.

On top of that, the merkle tree-like structure holding the signups has been swapped out for a more efficient incremental merkle tree (LazyIMT). This offers some savings for users signing up, as well as simplifies the steps required to finalise a poll, by merging all leaves together and removing the need to compute the subroots and root of the tree.

Improved contract tasks​

It is now possible to deploy contracts and finalise polls using the contracts tasks only. This makes the protocol much easier to use, as there is no need to use the maci-cli anymore, which often came with a large number of flags and options. You will just need to fill a json file with the correct parameters and run few simple commands.

Concurrent Polls​

It is now finally possible to run multiple polls concurrently from a single MACI instance. Users will no longer need to signup again to vote on proposals published by a single organiser. One thing to note is that each poll will have the same amount of voting power, and new users will need to pass the same gating process as existing users.

We believe this feature will work best when used for coordinating several polls for the participants of a single event where signup is gated by the conference ticket and there are multiple voting rounds, like at Devcon or Devconnect.

New Gatekeepers​

Custom Gatekeepers are a great way to guard MACI against Sybil attacks, and with this release we have integrated a number of new protocols, together with the help of our community:

• Hats Protocol
• Gitcoin Passport
• Zupass
• Semaphore

For instance, with Gitcoin Passport as the gatekeeper, the MACI round organiser can set a threshold score and only allow new users with a passport score greater or equal to that threshold. Additionally, with Zupass, we can now gate access to holders of specific event tickets.

We expect to continue to expand our gatekeeper capabilities and welcome the community to come up with new and innovative ways to grant access to MACI's rounds, helping make MACI more customizable and sybil-resilient.

Documentation​

You gave us the feedback that the MACI documentation was way too tough to digest, and we heard you! To make it easier to understand, we have grouped documentation entries under a more logical structure, with different sections for different audiences and objectives.

We continue to use our docs website as the definitive resource for all information related to MACI, including blog releases, documentation updates, and roadmap progress. As always, we welcome suggestions on how to make it better and encourage you to report any inconsistencies you may find.

Security Audit​

As usual before a major release, the protocol has been thoroughly audited by PSE's internal Audit team, and this time no significant issues were found. However, thanks to the auditors' hard work, we have been able to further optimise the protocol and clean up our technical documentation.

For more details on this recent audit, please refer to our audit docs or view the full report.

With more and more eyes on the protocol, we feel more and more confident about MACI's security posture.

Trusted Setup Ceremony​

We are preparing for a new ceremony to cover the changes in our v2.0.0 circuits. To accomplish this, we'll leverage the tooling of p0tion, which helps to streamline and automate Groth16 phase2 ceremonies.

We'll update this page after the ceremony completes to include the production-ready zkey artifacts. In the meantime, the artifacts for v.1.2 can be found on our website, and the artifacts can still be used in production for releases 1.2.0 up to 1.2.5.

Get Involved​

MACI is deeply committed to our community, through our open initiatives like public roadmaps, transparent repository management, and a public Discord channel for interaction with our team.

With every issue, PR, feature and roadmap iteration, we welcome feedback to ensure that the continued development of MACI reflects your and the community's needs. Keep an eye on our documentation, GitHub discussions and our official Twitter/X account for updates.

For those looking to contribute directly, report bugs, or offer feedback, our GitHub repository is open for issues and discussions. We're eager to assist with your projects or contributions.

For practical implementation insights, review our docs as well as the clr.fund, Allo Stack with MACI, and maci-platform repositories as reference implementations. The first two integrations are quadratic funding implementations, a mechanism which otherwise is highly susceptible to collusion and bribery.

For any other questions or feedback, please reach out to us via PSE's Discord, in our #🗳️-maci channel. We're excited to connect and collaborate with you!

References​

• MACI GitHub repository
• MACI documentation
• A technical introduction to MACI 1.0 - Kyle Charbonnet
• Minimal anti-collusion infrastructure - Vitalik
• PSE Discord server
• Allo Stack with MACI
• maci-platform
• clr.fund

Release​

Here's the link to the new release code in GitHub: v2.0.0 Release.

Greetings anon,

We’re excited to share with you what we're building over the next few months. You'll see some of the same themes as our Q2 roadmap as we strive to make MACI and MACI-RPGF more user-friendly and accessible.

If you haven’t read the Q2 in review yet to learn what we’ve been up to the last three months you can check that out here.

MACI Platform​

The team is doubling down efforts to build a comprehensive voting platform with MACI powering it all. Initially called maci-rpgf, the project is soon turning into an all-in-one solution for hosting voting, quadratic funding, and rpgf rounds. We plan to work on improving the product with the following high-level initiatives:

• Complete the integration of the PSE's design team’s new design
• Bootstrap an e2e testing framework to ensure the code is more robust and reliable
• Support quadratic voting
• Support the use of different signup mechanisms
• Move application's data storage from Vercel to IPFS
• Support contributing/voting to multiple rounds on the same deployment

Our efforts will include supporting community organisers who want to fork and operate MACI Platform rounds in production. If you're interested in running a round for your community, please get in touch!

Coordinator Service​

After successfully implementing a proof generation service as part of our effort of reducing the burden on round organisers, we have plans to continue automating all MACI related operations. This includes contract deployment, proof generation and submission, contract details storage, automatic upload of final tally results to IPFS and more.

We see the “Coordinator Service” as the ultimate automation of MACI’s main pain-points, and look forward to building a secure and efficient service that will abstract away all the operational burdens of using MACI. For more information on the full feature list that this service will include, please refer to this GitHub issue.

Explore Account Abstraction​

It is clear that mass adoption of blockchain applications will be difficult if users, especially first time users, must pay to interact with dapps. Furthermore, having a crypto wallet installed and configured to work on a specific chain might also not be straightforward for an average user.

To support this thesis, the MACI team will start a collaboration with other PSE teams involved in researching and implementing account abstraction (AA) solutions. We look forward to bringing some proof of concepts (PoC) for MACI Paymasters and more, which will help remove friction when it comes to web3 UX.

MACI Protocol Improvements​

As always, we plan to improve the MACI protocol both in terms of making it cheaper and easier to use, as well as making it more secure.

As part of this effort, we are currently working with the 3327 team to integrate their Anonymous Poll Joining grant work into a new MACI version. The effort can be tracked in this public GitHub board. This work enables unconditional voter privacy, further strengthening user privacy in the protocol. For more details, please refer to this blog post.

On top of this, the team will begin the ground work to implement Vitalik’s latest MACI proposal Mostly Offchain Happy Path - in a nutshell, the proposal seeks to completely remove transaction costs for users by moving certain operations offchain. For maximum privacy and trustlessness, voters will still be able to go directly on-chain and submit their own signup/vote actions.

How does that sound?​

Questions? Concerns? Ideas? We’d love to hear from you!

If there is a feature you think we should work on, or an initiative you'd like to collaborate with us on, please let us know! We welcome input from anyone in the community. The best ways to get in touch are to hop in our Discord (#🗳️-maci channel), tag us on X, or create an issue on GitHub.

Onward and upward 🚀

Greetings anon,

Glad to have you here! It's that time of the year where we have a few MACI roadmap updates to share. We’re going to take a moment to look at what we accomplished in Q2, as the most active project in the entire PSE GitHub org.

Before we start, we would like to express our gratitude to all our collaborators and contributors to the MACI protocol.

Q2 in review​

In our q2 roadmap, we aimed at a few major Q2 goals that all tied together:

✅ MACI-RPGF​

A lot has happened with MACI-RPGF this last quarter. Much time has been spent improving the product in order to provide a more functional and stable product with a better overall user experience.

PSE's design team came up with a beautiful design that will soon be merged into the stable version of the code. We are looking forward to implementing this major update and are excited for you to try it!

On the outreach and support side, we also engaged with several communities to run a round using MACI-RPGF. There are three rounds ongoing with EthMexico, ETH Tegucigalpa and Cryptoversidad. Our developers have been working closely with their development teams to deploy and run MACI-RPGF. We look forward to supporting them throughout their rounds and helping facilitate the distribution of funds directly into community members building amazing things in the Ethereum ecosystem.

✅ MACI Coordinator Service​

The use of a Coordinator Service would greatly simplify the operation requirements when running MACI. To better support communities running MACI polls, whether as a QF round or a simple voting application, the team has prioritised the development of a Coordinator Service that can be used by any Round Operator.

In the last three months we successfully completed the first iteration of a proof generation service, which can be used to more easily finalise MACI polls. Additionally, work on a frontend dashboard has started. This dashboard can be used to more easily deploy contracts in a customisable way via an intuitive user interface.

✅ MACI Core Protocol Improvements​

To achieve our Q2 goal of “Unconditional Privacy" we worked with the 3327 team (responsible for the ElGamal on MACI implementation) to come up with an effective solution and a better user experience that we could have hoped for. More on this can be found in our blog, but we have now started this grant work and are looking forward to seeing this in action in the coming months.

We have also been busy working on some new features and improvements to the codebase. It is now easier than ever to deploy MACI instances, as well as re-use certain smart contracts that have already been deployed and will not need changing.

Furthermore, we have managed to slightly reduce the costs for users by removing unused features, as well as using different and more optimised data structures. This brought several improvements, such as allowing for concurrent polls to be run from one MACI instance (finally!).

Finally, we worked with the community to integrate a number of different gatekeepers:

• Semaphore
• Gitcoin Passport
• Zupass - thanks gasperpre for the implementation

You can now use these (plus more) to gatekeep signups to MACI and shoot down those sybil attacks!!.

Stay tuned for an upcoming MACI release where all these efforts can be seen in action.

✅ Support Gitcoin Allo protocol integration​

Throughout May and June, Gitcoin and Nick Lionis in particular worked hard to integrate MACI in the Allo Stack. You can find the code on their GitHub. The stack will soon be used in production by Gitcoin to support running grant rounds privately.

We are excited to see rounds being run with this integration, and look forward to continue to collaborate with the Allo team to improve MACI and integrate new versions into their stack.

✅ Support ETHDam hackathon QV round​

In April, we successfully supported the ETHDam team to run a private quadratic voting (QV) round for the ETHDam hackathon, powered by MACI. Conference attendees used clr.fund to vote on their favourite hackathon projects in order to allocate $10,000 to projects building novel privacy and security solutions in the ecosystem.

✅ MACI starter kit​

We've teamed up with Buidl Guild and the Scaffold-ETH team to build a MACI starter kit: a web app that integrates MACI in order to run polls. Thanks to Yash's efforts we now have a ready-to-use MACI starter kit. This has already been used in two hackathons (as an example here's an Eth Berlin project) to quickly prototype projects using MACI. We thank Yash for all his effort with this and are looking forward to see what the community will build with it.

That was a lot, and there’s more to come! Be sure to keep an eye out here for our next post where we look forward to what is coming for MACI in Q3, 2024.

What are Public Goods?​

Public goods are services or products that are available for everyone to consume, regardless of whether they contribute to their creation. Examples include clean air, public parks, and open-source software. These goods are essential for community welfare but often face funding challenges due to their non-excludable and non-rivalrous nature. This is where blockchain technology steps in, offering a decentralised approach to funding these vital initiatives. Through blockchain, transparency and community participation in funding decisions are greatly enhanced.

What is MACI and how does it help fund Public Goods?​

At its core, MACI is a tool that ensures privacy and prevents collusion in voting and decision-making processes. This function is crucial in public goods funding scenarios, as it ensures that the allocation of funds is fair and uninfluenced by external factors.

Current state​

MACI can be used in different forms of decision making and voting.

Quadratic funding is one of the ways in which we could utilise MACI for public goods funding. Quadratic funding is a democratic mechanism for crowdfunding that seeks to promote equitable, inclusive funding for public goods such as open-source software, scientific research, and public art initiatives. By incorporating MACI, these platforms guarantee that votes on how funds are distributed are not swayed by bribery or external pressures. This approach ensures a democratic and equitable distribution of funds, leading to more effective and genuinely representative support for public goods.

Another way in which MACI is utilised is for communities to be able to vote in Retroactive Public Goods Funding (RetroPGF) rounds. For example, Optimism runs RetroPGF rounds which involve allocating funds to projects based on past contributions to the ecosystem, incentivising and rewarding valuable contributions retrospectively. We’ve incorporated MACI to the RPGF stack and thus communities would be able to independently run future rounds in a private and secure manner using maci-rpgf!

The Future looks bright​

As we look to the future, the potential of MACI in reshaping public goods funding is significant. MACI could be used for larger and more diverse funding initiatives, expanding its impact, potentially influencing even governmental approaches to public goods funding. The role of MACI in fostering a transparent, fair, and democratic process for funding public goods is set to be a game-changer. Learn more about MACI by reading through our documentation. Join us in our mission, connect with our team on Discord today!

Welcome to the intriguing world of blockchain! This guide delves into Minimal Anti-Collusion Infrastructure (MACI), essential for those exploring secure, private voting on the blockchain.

Understanding MACI’s Strengths​

MACI stands as a lighthouse of private, secure voting in blockchain voting. Key features include:

• Collusion Resistance: MACI combats collusion, a significant issue in blockchain voting, by making it impossible for voters to verify their choices to others.
• Privacy: A cornerstone of MACI, ensuring vote secrecy.
• Receipt-Freeness: Ensuring voters can’t prove beyond any reasonable doubt their vote to others.
• Hinders bribery: As anyone looking to bribe voters can’t confirm how voters placed their votes, this potentially discourages bribery.

These strengths make MACI vital in enhancing trustworthiness, especially for newcomers.

Use Cases for MACI​

Some potential use cases for MACI are as follows

• DAO Voting: For Decentralized Autonomous Organizations (DAOs), MACI secures votes for crucial decisions, maintaining democracy in these organizations.
• Public Goods Funding: On platforms like clr.fund , MACI ensures fair funding decisions, free from external influences via Quadratic Funding.
• Elections: MACI could also be used in governmental elections for people to cast secure votes for the leaders of their state!

These use cases demonstrate MACI's transformative role in making voting more accessible and trustworthy.

Where MACI May Not Be Ideal​

MACI's powerful features may not suit every scenario. For example:

• Transparent Governance: Where individual vote transparency is key, MACI’s privacy might not be the best option
• Simple Polling: In basic, non-sensitive blockchain polling, MACI's complexity might not be needed.

Recognising the context of the situation helps in choosing the right tool for blockchain voting needs.

Conclusion​

MACI is a significant advancement for secure, private voting. Understanding its strengths and appropriate applications is key to leveraging this technology. As the blockchain landscape evolves, tools like MACI will play an increasingly vital role. Dive deeper into MACI and its application via our documentation and by joining our team’s discussion via our Discord channel!

Hey Anon!

In this blog post, we’ll give a high-level, beginner friendly introduction of what Minimal Anti-Collusion Infrastructure (MACI) is, and how it could be used in a real-world context. We’ll take you through the essentials of MACI, making complex concepts accessible regardless of your background in the blockchain space.

What is MACI?​

MACI is a cutting-edge solution that ensures private, reliable voting on the blockchain.

Blockchain Voting Challenges for Beginners​

On-chain voting is a method of casting votes directly on the blockchain, leveraging its decentralized and transparent nature. While this provides us with censorship resistance and guarantees correct execution, the transparency of blockchains can be a double-edged sword. Given all transaction data is public by default, it means everyone can see how anyone voted. This ensures all votes are correctly counted but the visibility could lead to undue influence on voters' decisions, and potentially opens doors for unethical practices like voter bribery. The challenge, therefore, lies in preserving the privacy of each vote while maintaining the core principles of blockchain: transparency, process integrity, and security.

How MACI Offers a Solution​

Minimal Anti-Collusion Infrastructure, or MACI, steps in as an elegant solution to these challenges. Despite operating on-chain, it protects the privacy of voters and votes, thereby significantly reducing the chances of vote manipulation through bribery. How does it achieve this? By employing advanced cryptographic techniques like zero-knowledge proofs (zk-SNARKs), MACI ensures that while the outcome of the vote is public and transparent, individual voting choices remain private. For instance, let's say you vote in an election using MACI, you could claim to everyone that you voted for a particular candidate, but in reality, you might have voted for someone else. There's no way for anyone to verify your claim, making bribery less appealing.

Key Features of MACI​

MACI isn't just a tool; it's a fortress safeguarding the integrity of on-chain voting. Let's break down its key features:

• Collusion Resistance: MACI makes it virtually impossible for voters to be swayed by bribes, as they can't prove how they voted.
• Privacy: Your vote is your secret. Only you know where your support lies, thanks to the encryption technology MACI employs.
• Uncensorability: Every vote counts and cannot be blocked, edited or removed, ensuring a fair voting process.
• Unforgeability: Your vote is tied to your unique digital identity, preventing anyone else from casting a vote in your place.
• Non-repudiation: Once cast, your vote is set in stone. You can change your mind and vote again, but you can't erase your previous vote.
• Correct Execution: The final tally is accurate and tamper-proof, ensuring that the true voice of the voting population is heard.

These features come together to create a voting environment where your voice is heard, loud and clear, without fear of external influence or manipulation.

Technical Overview Simplified​

At its heart, MACI is built on Ethereum, a blockchain platform. This foundation provides a high level of security and trust. The real magic, however, lies in something called zk-SNARKs. Think of zk-SNARKs as a cloak of invisibility for your vote; they hide your voting choices while still guaranteeing the overall vote count to be tallied accurately. This blend of Ethereum's robust framework and the innovative use of zk-SNARKs makes MACI a reliable and secure choice for on-chain voting, ensuring that your vote is both private and counted.

If you’re interested in more of the technical details, check out the MACI documentation.

Real-World Applications and Limitations​

Imagine a world where funding for public goods, like community projects or open-source software, is decided through fair and transparent voting. This is where MACI shows its true potential. Quadratic funding is already harnessing MACI's capabilities to enhance user privacy and discourage any form of collusion in funding decisions.

However, like any system, MACI isn't perfect. Its effectiveness hinges on the honesty of the coordinator – the entity or person overseeing the voting process and tallying the results. A dishonest coordinator could pose risks, but thankfully, MACI is designed to minimise even this possibility, maintaining a high level of integrity in the voting process.

Conclusion​

As we've explored, Minimal Anti-Collusion Infrastructure (MACI) stands as a testament to the innovative solutions being developed in the blockchain space, especially for those new to this technology. It addresses the critical need for privacy and fairness in on-chain voting, ensuring that your vote remains your own, free from external pressures and manipulation.

Blockchain technology is continually evolving, and with tools like MACI, it's becoming more accessible and trustworthy. Whether you're a blockchain enthusiast, a developer, or someone just starting to explore this exciting field, MACI represents a significant step forward in creating a more democratic and transparent digital world.

We encourage you to delve deeper into MACI and the broader world of blockchain by reading through our documentation and installing MACI. Join us too on our Discord to report any bugs or to chat with our team. Your involvement can help shape a future where digital voting is not just secure, but also truly representative of the people's voice.

Together, let's embrace these advancements and contribute to a fairer, more transparent digital voting landscape.