Blockchain can be used beyond currency and financial transactions. One non-financial application is that blockchain can greatly improve the field of voting and governance. In this article, we explore the approach of building a special-purpose blockchain infrastructure designed to facilitate MACI-based voting activities. This infrastructure should include a lightweight blockchain that acts as a timestamp server and hosts the logic, as well as the tools required to reduce user costs/maximize user experience. As such, it should become a new foundational platform for a new generation of voting technology. Before diving into the details, let’s first review the history of voting technology and how voting has evolved within the blockchain community.

The evolution of voting technology Voting technology from the ancient Greek Kleroterion[1] to modern electronic voting machines.

Voting technology has a long history[2]. It is extremely important to human society, but has evolved very slowly. The UK still relied on hand-marked ballots during the 2019 general election[3], and other nation-states use closed-source electronic voting machines[4], which can easily lead to controversial governance outcomes[5].

The adoption of modern voting technology has improved efficiency but has not had much success in addressing transparency and verifiability.

It goes without saying that the integrity of voting is very important for the transfer of power, decision-making on important matters, or the allocation of resources. If people cannot agree on the voting results of governance decisions, they cannot cooperate with each other and friction will increase. Friction may cause problems, ranging from disputes to wars.

Although voting technology is slowly improving, transparency has not improved in a long time. From Kleroterion to paper ballots to electronic and optical scanning voting machines, verification still relies on trusted individuals and auditing organizations. Confirming and auditing voting results can be extremely costly[6]. Clearly there is room for improvement.

So what is the ideal voting technology? This is not a difficult question. We can easily create a wish list:

(1) Open source infrastructure;

(2) hosting open source programs for voting logic;

(3) maintain a permanent record of all votes cast in order;

(4) Ability to cryptographically verify the results;

(5) Anti-conspiracy;

(6) Protect privacy;

(7) Voting costs are low.

If we can build an open source system that can be continually improved, we will gradually achieve the above goals. Improvements in voting technology and reductions in costs can enable smaller organizations and communities to benefit from using technology that was previously unavailable to them, adding huge positive externalities.

Voting and governance within blockchain communities

Voting and governance are not unfamiliar in the blockchain community, as many blockchain communities are distributed and they must rely on governance to drive the development of affairs.

The blockchain itself can transparently record votes and verify voting results. These properties have been used by blockchain communities for governance, such as Snapshot token voting[7] and Cosmos governance proposal voting[8]. As a result, blockchain communities can vote on proposals and decide important governance matters without going through centralized agents or face-to-face meetings.

An ongoing proposal[10] by KlaytnSquare[9] calls for validators to vote on-chain. The proposal seeks approval for a quarterly treasury spending plan[11].

The previous examples used a simple and straightforward 1 token 1 vote rule - how much voting power you have depends on your stake in the network or protocol. Obviously, we can create other voting logics as long as it makes sense. The programmability of blockchains makes it easier and more practical to implement non-traditional voting logic.

One example is quadratic voting[12] (QV), a voting scheme that is becoming increasingly popular in the blockchain community. In a QV round, a user can express his/her preference by spending “voice credits” on a particular topic. But if a voter wants to cast more than one vote on the same topic, the cost of each vote increases. Therefore, the total cost of voting increases quadratically, discouraging extreme preferences from users with too much voting power.

The quadratic funding [13] round is voted on the Aptos blockchain. The voting results are recorded on the chain and the voting logic is verifiable.

There are many parameters to consider when choosing a specific voting method. For example, one trade-off is choosing on-chain or off-chain voting. On-chain voting logic may be more verifiable and transparent, but transaction fees may be a significant burden. Conversely, off-chain voting logic may be cheaper, but at the same time less transparent and verifiable. However, on-chain vs. off-chain voting is not an either-or relationship. We can easily design it as a hybrid system where part of the process is done on-chain and the rest is done off-chain.

In addition to the cost, there is also the issue of privacy. Privacy is important for two reasons. First, in many cases, if users can vote anonymously (privacy between users and organizers), they will have fewer concerns about voting. In addition, privacy between users can help prevent vote bribery and effectively achieve anti-collusion.

One way we can minimize on-chain computation while enforcing off-chain integrity is to use zero-knowledge proofs[14]. A simple idea is that if off-chain computation can be verified with zero-knowledge proofs, we can move most of the computation off-chain. If the messages are further encrypted, we can enhance privacy. MACI[15] is a minimal framework that achieves this goal.

The MACI voting round transfers the vote counting to the off-chain. Finally, the validity of the result is verified on-chain through zero-knowledge proof.

In a MACI voting round, votes are encapsulated in a message encrypted by a public key generated by a round administrator (operator) and submitted to the smart contract. Therefore, all messages are "timestamped" by the blockchain, creating a message chain of voting information.

When the voting round ends, the administrator downloads all messages, decrypts them, and counts the votes in reverse order. The results are then published along with a zero-knowledge proof that can be verified on a smart contract (or by anyone else), marking the validity of the published results and the correctness of the message processing.

The entire process maintains minimal on-chain computation while ensuring the integrity of published results. It also provides privacy and anti-collusion capabilities between users.

How does MACI work in actual products?

MACI is currently used by hackathon communities on DoraHacks[16] to vote for their favorite hackathon projects. So we take the DoraHacks MACI round as an example.

OpenSea and Replit Hackathon to Use MACI for Judge Voting in 2022

After the hackathon project (BUIDL) was submitted, the organizers selected 12 BUIDL teams from all the submitted works. 10 judges were invited to vote for these 12 BUIDL teams and distribute $25,000 in prize money. 10 judges were whitelisted and signed up for the voting round, and they sent a total of 39 messages to the MACI smart contract deployed on Polygon.

After the voting is over, the administrator (DoraHacks) counts the votes and publishes the final results to the leaderboard, and then provides a zero-knowledge proof to verify the leaderboard.

Leaderboard of the OpenSea x Replit hackathon voting results. Zero-knowledge proof verifying the results shown on the leaderboard.

As a general framework, MACI can be used for voting use cases beyond hackathon judge voting and open source community voting. However, adoption of MACI for more voting use cases is surprisingly rare. More broadly, blockchain voting itself has yet to be adopted in the real world.

The benefits of using blockchain to improve voting technology are clear, but why is the real world not moving forward? Even within the blockchain community, the advantages of MACI are clear, so why is MACI not widely adopted by the decentralized community?

One of the main reasons for the slow adoption of advanced voting technology is not low demand, but the difficulty of using such technology. In other words, we need to improve technology, provide better UX/UI for modern voting products, and reduce the cost of use for users.

user experience

In addition to open source community governance, we also need to build more interfaces for users to use new voting technologies. DoraHacks provides funding for the Web3 ecosystem and hackathon community with the best products currently available in the entire industry. Although the interfaces on DoraHacks.io themselves have specific use cases, they can be simplified and then generalized to build more interfaces for more use cases.

The exact front-end strategy has yet to be determined. However, a good user experience is critical to the adoption of the technology, even within the blockchain community — and that’s important to Dora Factory developers.

Voting costs

General-purpose blockchains should be as decentralized as possible and provide a single infrastructure for all types of applications. These blockchains are not designed to be optimized for any specific type of application, especially non-monetary or non-financial applications. At the same time, transaction fees fluctuate when there are a large number of applications competing for the same set of computing resources. The unpredictability of costs can cause trouble for voting.

To this end, Dora Factory recently tested a new product called Vota[17]. The idea of ​​Vota is to experiment with special-purpose blockchains and use them to continuously optimize voting technology and user experience. Currently, Vota is still in its infancy. However, we can imagine several different forms of Vota.

Temporary Smart Contract

This is how voting rounds are currently supported on DoraHacks.io. Each voting round is deployed as a separate smart contract on a specific blockchain. Ethereum is generally not able to directly support most voting scenarios in most cases (this is why Snapshot is the default product used by the Ethereum community). Currently, Polygon and BNBChain are the popular choices for most grant organizers and hackathon organizers on DoraHacks.

A temporary smart contract on the L1 blockchain, all voting messages are sent to L1.

Using ad-hoc smart contracts isn’t entirely a bad thing. It’s flexible and can be deployed anywhere you want. It works fine for the users of DoraHacks right now, but it won’t work equally well for all voting needs.

L2 Vota

If we create a layer 2 infrastructure (L2) dedicated to voting, we can significantly reduce gas costs and may be able to implement low-cost voting on Ethereum. L2 contracts do not have to be deployed entirely on Ethereum, they can be cheaper and only need to submit L1 transactions from time to time to verify all L2 activities.

We can further optimize this model. General L2 must be submitted to Ethereum frequently. Vota only needs to submit one transaction to Ethereum per round, which means that each round only needs the gas cost of one transaction at most. If multiple rounds end at the same time, they can share a transaction to further reduce the gas cost, making voting L2 more realistic and feasible.

Messages are sent directly to the L2 contract. Only one transaction is sent to the L1 blockchain at the end of each round. L3 Vota (applicable to L(n)Vota, where n>=3)

L3 Vota is not completely meaningless. Through the established L2, L3 Vota can further reduce gas fees by an order of magnitude. Although L3 transactions are ultimately recorded and verified on Ethereum, the trade-off is trust in the chosen L2.

Of course, we can further extend this to L(n) Vota, because L(2)…L(n-1) will submit transactions to Ethereum (or other L1). But obviously the trust chain will complicate things. From the current situation, many well-known L2s still rely on a single sequencer; it may be too early to talk about L(4) now.

Application chain Vota

Dora Factory developers created a simple "Hack" that allows CosmWasm contracts to use [18] Bellman [19] to verify zero-knowledge proofs generated by SnarkJS. By incorporating Bellman into CosmWasm contracts, any Cosmos application chain can quickly support zk applications.

With the ability to run zk applications, independent blockchains can use software architectures like Tendermint to build a chain. The consensus of these blockchains is similar to BFT, or simpler, and they can usually support up to 100 or so validators. By carefully selecting validators with inconsistent interests, independent blockchains can be secure and neutral enough.

As DoraHacks welcomes more Cosmos application chains to join, an obvious use case for application chain-based Vota is to vote for hackathon results. In addition to DoraHacks, the role of Cosmos application chain-based Vota goes far beyond voting for hackathon judges.

The number of validators on the application chain Vota is small, but carefully selected validators can provide a reliable infrastructure.

It is worth noting that these solutions are not exclusive. As Vota develops, different solutions may intersect. For example, if we have a separate application chain version of Vota as the main infrastructure, for use cases that require transaction verification on a specific L1, the application chain can send additional transactions to the L1.

Better anonymity

There is ongoing research work aimed at making MACI more trustless. The original MACI made an important trust assumption that the administrator cannot be corrupt. This is not universally true. There are MPC-based[20] and non-MPC-based[21] solutions to improve this. Currently, DoraHacks has built an anonymous version of MACI based on ElGamal re-randomizable cryptography, originally proposed by Kobe Guikan.[22] It has been tested in a small ETH research grant round[23] on DoraHacks.io.

At this point, it may be a bit premature to push for adoption of anonymous MACI before MACI itself is widely adopted. However, it is also important to continue research to reduce the trust assumptions of general voting mechanisms.

Add anonymity to MACI by adding operations that allow users to deactivate and change their secret keys, without the administrator being able to know who added which new key. GAS payment

It is important not to assume that users own cryptocurrency. If every user had to pay a gas fee for every transaction, the blockchain would be limited to a small group of people. To address this, MACI operators could pre-deposit a refundable token and pay the user. This mechanism could be implemented through gas stations.

The Gas Station itself is a smart contract that resides on Vota. Before each round begins, operators can choose to use it or not. By using the Gas Station, operators pre-deposit DORA into the smart contract and can pay transaction fees associated with a specific round through the Gas Station.

Most likely, Vota will deploy a default gas station, and people can deploy their own gas stations with different payment logic on demand.

The Gas Payment Contract is a ledger of the Gas balance for each voting round.

Special-purpose blockchains are potentially applicable to a wide range of application-specific use cases, especially non-financial ones. Voting is one of the most important problems that blockchain and zero-knowledge cryptography can help significantly improve. Improving voting transparency and efficiency can reduce governance friction within human society and blockchain communities, which can increase productivity in the long run. Protocols like MACI create a concise framework for voting applications on blockchains, but there is still much work to be done to improve voting technology. Specifically, we need a user-friendly infrastructure as a foundation to improve voting technology in the long term, and this article details future work.

Reference

Cleroterion:https://en.wikipedia.org/wiki/Cleroterion

The long history of voting technology: https://electionlab.mit.edu/research/voting-technology

UK 2019 Brexit general election: https://en.wikipedia.org/wiki/2019_United_Kingdom_general_election

Electronic voting machines: https://en.wikipedia.org/wiki/Dominion_Voting_Systems

Dispute over election results: https://www.reuters.com/legal/dominions-defamation-case-against-fox-poised-trial-after-delay-2023-04-18

The costs of confirming and auditing ballot results can be extremely high: https://azsos.gov/elections/voters/voting-elections/ballot-processing/2022-general-elections-recount-information

Snapshot token voting: https://snapshot.org/

Cosmos governance proposal voting: https://www.mintscan.io/cosmos/proposals

KlaytnSquare:https://square.klaytn.foundation/GC

A proposal from KlaytnSquare: https://square.klaytn.foundation/Proposal/Detail?id=4

Fiscal spending plan: https://govforum.klaytn.foundation/c/proposal/5

Quadratic voting: https://en.wikipedia.org/wiki/Quadratic_voting

Quadratic Funding: https://research.dorahacks.io/2022/07/11/quadratic-governance

Zero-knowledge proof: https://en.wikipedia.org/wiki/Zero-knowledge_proof

MACI:https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413

DoraHacks: https://dorahacks.io/grant/ethdenver22/buidl

Vota:https://vota.dorafactory.org/

A simple "hack" to allow CosmWasm contracts to be used: https://github.com/DoraFactory/snarkjs-bellman-adapter/tree/main/prove

Bellman:https://github.com/zkcrypto/bellman

MPC-based solution: https://research.dorahacks.io/2023/03/30/mpc-maci-anonymization

Non-MPC based solutions: https://ethresear.ch/t/maci-anonymization-using-rerandomizable-encryption/7054

Anonymous MACI version, proposed by KobeGuikan: https://github.com/dorahacksglobal/anonymous-maci

ETH Research Grant Round: https://dorahacks.io/grant/ethre3/maci