It is challenging for naive voting systems, particularly those integrated into smart contract platforms, to prevent collusion. 

MACI (Minimal Anti-Collusion Infrastructure) is a collection of smart contracts, ZK circuits, and its packages that we can use to build programs on top. 

The initial idea related to the MACI project came from Vitalik Buterin, the co-founder of Ethereum. (Minimal anti-collusion infrastructure and On Collusion). 

MACI reduces bribery and disables censored voting. This means that no one can vote on behalf of another while making it impossible for someone to falsify the outcome and the number of votes.

So how exactly does MACI work? Who can see how voters voted? Is it possible to cancel the vote (if, for example, the voter was blackmailed)?

The users vote on the blockchain via MACI smart contracts. MACI allows only a voter who owns a private key 🔑 can vote by having that vote tied to his public key 🔐 . A voter (if, for example, he is blackmailed into voting in a certain way) can vote once more and, in that way, can cancel the previous vote. Only the coordinator can decrypt all the votes (which is good if the coordinator is honest, but what if he is not 👿?!). The coordinator tallies up the votes and releases the final voting results when the voting is over. No one, not even the coordinator, has the opportunity to censor the vote and influence the number of votes and their outcome.

Practically speaking, MACI provides three subsystems in different programming languages:

• Smart contracts - written in Solidity. This contract enables developers tools to integrate MACI into Ethereum smart contracts.
• Circuits for zero-knowledge proofs - written in Circom. For example, to hide how each person voted, MACI uses ZK proofs, and coordinators use ZK proofs to prove that the final result is valid without revealing the voters' votes.
• Business logic - written in Typescript. This code is in charge of handling the circuits and the smart contracts.

Let's explore how MACI works!

At MACI, we can distinguish between voters and voting coordinators. Users vote on the blockchain via MACI smart contracts. It is necessary for voters to sign up first by sending the public key they wish to vote for a MACI smart contract. Their public key plays a role in their identity. They can vote from a specific address, but their message must contain a signature from that public key. 

When voting, voters send together several pieces of information, their public key, vote, amount, and others. The aggregated information represents a “command”. They sign that command with the public key they use when signing up. The voter then encrypts (to derive a shared key) the signature and the command together, which is the "message". MACI uses an Elliptic-curve Diffie–Hellman shared key.

As seen from the picture, it is essential because it prevents the influence of a third party from influencing the voting; there is the possibility for the voter to cancel his vote as long as the command is signed with the previous public key. Namely, a voter can change the public key (and in that way, vote again and annul the previous vote), but for a vote to be valid, it must be signed with the previous public key.

When the voting is over, the coordinator enters the scene 🎦. First, he needs to prove that he has decrypted all the votes correctly and that the state tree has been updated correctly. After verifying the proof, the coordinator collects all the votes (for which he has previously proved that he has successfully decrypted) and creates ZK proof for the outcome and number of votes. After that, the verification is performed again. Although voters cannot see how voters voted, they can be sure that the votes have been adequately processed and counted correctly 🤝. 

Also, it is essential to note that the coordinator can't censor the vote because, in that case, he would not be able to give valid proof.

The disadvantage is that the coordinator can see how someone voted, so if he is dishonest, he can pass on information. The good side is that the coordinator can't add an extra vote or change someone's vote.

Our recommendations for articles on this topic are:

• Release Announcement: MACI 1.0
• Minimum Anti-Collusion Infrastructure
• A Technical Introduction to MACI 1.0

Is it possible to achieve voting without collusion while protecting voter privacy?

Fairness of voting without the possibility of collusion is extremely important, especially if the voting is related to some significant funding 💰. MACI represents a big step forward in preventing collusion from voting on the chain. It does not currently completely suppress collusion, which is clearly seen if the coordinator is not honest. Therefore, it is essential to achieve that the coordinator can't know how which voter voted, i.e., to preserve the secrecy of the voting fully. 

What seems to be perhaps the most significant contribution to improving the MACI is that the coordinator can't know how the voters voted. Naturally, whether it is possible to achieve this and how you can find out in our next blog related to this topic!💡

Conclusion 

In this blog, we examine how MACI works. We covered two main directions of research:

• Analysis of the MACI project;
• The main obstacle to the total destruction of collusion.

We hope you liked our short blog about MACI and that we tickled your imagination about our next blog, "Anonymity in MACI". 🚀

For more blockchain-related topics, join our Discord, and share your thoughts with us!