TL;DR: aMACI eliminates the need for trust in MACI's operator and enables anyone to become an operator for an aMACI round.
Although crypto communities use many tools common to internet hobby groups and social networks, they are fundamentally distinct. A crypto community is unified by a shared cryptocurrency and often engages in decision-making through decentralized governance. Both the currency and the governance mechanisms are secured and enforced by cryptography and code.
The principle of 'code-is-law' has enabled the formation of global decentralized communities. The transnational nature of crypto communities demands real and effective decentralized governance (dGov).
Decentralized governance necessitates a completely new tech stack to function effectively. Of all the required features, privacy is the most crucial yet often lacking. Privacy matters to dGov's scalability, as it ensures both censorship-free and collusion-free governance processes. This fosters trustlessness among members of a decentralized community who may never have met but need to collaborate on important decisions.
MACI and its adoption in open-source / hackathon communities
A simple but fundamental mechanism to achieve privacy in decentralized community governance is MACI. In a MACI round, there are two roles - the operator, and the users. After signing up, the users encrypt their votes with a public key posted by the operator, then they cast their votes on chain, to the MACI smart contract. While all votes are time-stamped on-chain, the content of the votes is only visible to the operator. After tallying the votes, the operator posts the results along with a zero-knowledge proof, which can be verified on the MACI smart contract. The correctness of the results is ensured by the zero-knowledge proof.
In the past three years, MACI's infrastructure and user experience have seen significant improvements, leading to its adoption by multiple communities.
Later, Dora Vota took one step further and developed a platform which allowed any community to start a MACI round. The Dora Vota MACI platform enabled general MACI use cases and greatly simplified the creation and management of MACI for operators.
Trust assumption of MACI's operator and anonymous MACI (aMACI)
In a community that adopts MACI, there is a need to trust the operator, who oversees all votes and provides results verified by zero-knowledge proof to the community.
Comment
Although an operator's ability to act maliciously is limited (for example, they cannot fake votes), there are still two potential actions the operator could take:
- The operator could do nothing
- The operator could collude
If, for some reason, the operator decides not to publish any results, the voting round becomes stalled. However, in such a case, it would be evident that the operator is not performing their duties, leading to their removal.
However, if the operator engages in collusion, the situation becomes more complex and obscure. The potential for operator collusion is a significant limitation for MACI. Therefore, addressing this issue would eliminate the most critical trust assumption in MACI and greatly broaden its applicability.
To eliminate the trust assumption in MACI, it's necessary to ensure that votes are also anonymous to the operator. One approach to achieving this anonymity is to allow users to deactivate their keys and set new ones, while preventing the operator from determining who controls the new keys.
The key deactivation operation was already a feature in the original MACI protocol. What makes aMACI different is to make sure that the operator is confused when multiple users deactivate and reset keys within the same period of time.
An original idea to add anonymity to MACI with MPC between the operator and users was first proposed from the Ethereum community. A Garbled Circuit based implementation was discussed within the DoraHacks community, but not actually employed in the current aMACI implementation because of its engineering complexity. An MPC-free alternative that uses ElGamal rerandomization function during the key set update was first described in Kobe Gurk's post, which was later adopted by DoraHacks team during the implementation of aMACI. An implementation note is available, providing more details and references for the current DoraHacks aMACI.
How aMACI work in real community voting events?
During the ETHVietnam 2024 event, 168 community members (mostly hackathon hackers) from the ETHVietnam 2024 hackathon participated in an aMACI community voting round. The goal of that voting round was to distribute $2000 to a selected group of projects from the ETHVietnam hackathon.
Among the 168 users who signed up to this aMACI round, many people deactivated their keys and registered new keys. The enthusiasm at the event was high, and it was the first time when many voters deactivated keys and reset keys at the same time. The operator's feedback was positive - indeed he's confused and couldn't tell who voted for which BUIDL during tally.
withdrawSet from time to time. The DoraHacks UI indicates how often that happens and what the next time it will be - users who deactivate their key have to reset a new key after the next key set update.
Third-party operator is possible with aMACI
By significantly reducing the need to trust the operator, aMACI can introduce exciting features that were not possible within the original MACI framework, including much enhanced privacy for voters and unconditional resistance to collusion.
Comment
But the most important capability aMACI will unlock is probably the fact that anyone could become an aMACI operator for any voting round, without the need for the voting community to trust this operator. With aMACI, The more key deactivation & reset operations are performed by the users, the harder their operator could know any details, therefore more difficult for the operator to collude. As a result, anyone can become an operator for any voting round.
This significantly lowers the entry barrier for a community to use aMACI. For communities that lack the capacity to manage the voting round and operate the necessary procedures, they can hire a third-party operator without worrying about vote leakage or collusion.
A lousy operator might still be able to wreck a voting round by doing nothing, leaving the voting round to fail. However, ultimately, a community has the freedom to choose any operator. The owner of the aMACI round could either invite someone they trust or hire a reputable third-party operator. Over time, competition combined with economic incentives and slashing mechanisms will ensure that communities and users have access to the best operators.
Conclusion
The crypto community demands dGov tech stacks, with privacy at the forefront of these demands.
MACI was a simple yet profound framework for collusion-free voting, but it relies on trust of the operator. Anonymous MACI significantly reduces this trust assumption. The aMACI framework built by DoraHacks demonstrates a minimal viable implementation of aMACI, and the recent ETHVietnam hackathon's adoption of aMACI shows that aMACI works as intended.
The most profound implication of aMACI is that the operator cannot collude, making third-party operators is possible. This greatly lowers the entry barrier for crypto and non-crypto communities to use this technology. Adoption of aMACI would benefit numerous communities around the world, and accelerate the development of decentralized governance.