Exploring the Optimal Voting Technology Detailed Explanation of Vota, a Special Purpose Infrastructure for Decentralized Community Governance

Exploring Vota Optimal Voting Technology for Decentralized Community Governance

Blockchain can play a role beyond currency and financial transactions. One non-financial application is that blockchain can greatly improve voting and governance. In this article, we explore the method of building a special-purpose blockchain infrastructure that aims to facilitate voting activities based on MACI. This infrastructure should include a lightweight blockchain that serves as a timestamp server and hosts logic, as well as tools needed to reduce user costs/maximize user experience. Therefore, it should become the new underlying platform for the next generation of voting technology. Before delving into the details, let’s first review the history of voting technology and its development within the blockchain community.

The Evolution of Voting Technology

From the ancient Greek Kleroterion[1] to modern electronic voting machines.

Voting technology has a long history[2]. It is very important to human society, but its development has been slow. The UK still relies on handwritten ballots during the 2019 general election[3], while other nations use closed-source electronic voting machines[4], which can easily lead to disputes over governance outcomes[5].

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

Undoubtedly, the integrity of voting is crucial for the transfer of power, decision-making on important matters, or allocation of resources. If people cannot agree on the voting results of governance decisions, they cannot cooperate with each other and friction increases. Friction can lead to problems, from disputes to wars.

Although voting technology is slowly evolving, transparency has not improved for a long time. From Kleroterion to paper ballots, to electronic and optical scan voting machines, verification still relies on trusted individuals and auditing organizations. The cost of confirming and auditing voting results can be extremely high[6]. Clearly, there is room for improvement.

So what is the ideal voting technology? Actually, this is not a difficult question. We can easily create a “wish list”:

(1) Open-source infrastructure;

(2) Open-source program for hosting voting logic;

(3) Permanent records of all votes in chronological order;

(4) Ability to cryptographically verify results;

(5) Resistance to collusion;

(6) Privacy protection;

(7) Low voting costs.

If we can build an open-source system that can be continuously improved, we will gradually achieve the above goals. The improvement of voting technology and the reduction of costs can benefit smaller organizations and communities by giving them access to technologies they couldn’t previously obtain, which creates significant positive externalities.

Voting and Governance in the Blockchain Community

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

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] activities. Therefore, blockchain communities can vote on proposals without centralized proxies or face-to-face meetings and decide on important governance matters.

A proposal [10] currently underway at KlaytnSquare [9] calls for validators to vote on-chain. The proposal seeks approval for a quarterly financial spending plan [11].

The aforementioned examples adopt a simple and direct 1 token 1 vote rule – the voting power depends on the stake in the network or protocol. Obviously, as long as it makes sense, we can create other voting logics. The programmability of the blockchain makes it easier and practical to implement non-traditional voting logics.

One example is Quadratic Voting [12] (QV), which is a voting scheme that is becoming increasingly popular in the blockchain community. In QV rounds, users can express their preferences by spending “voting credit points” (Voice Credits) on specific topics. However, if a voter wants to cast more than one vote on the same topic, the voting credit cost for each vote will increase. Therefore, the total cost of voting increases quadratically, preventing extreme preferences of users with excessive voting power.

Quadratic Funding [13] rounds are voted on the Aptos blockchain. The voting results are recorded on-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 between on-chain voting and off-chain voting. On-chain voting logic may be more verifiable and transparent, but transaction fees may be a significant burden. On the other hand, off-chain voting logic may be cheaper, but with lower transparency and verifiability. However, on-chain and off-chain voting are not mutually exclusive. We can easily design it as a hybrid system, with some processes conducted on-chain and the rest completed off-chain.

In addition to costs, there are privacy issues. Privacy is important for two reasons. First, in many cases, if users can vote anonymously (privacy between users and organizers), their concerns about voting will decrease. Additionally, privacy between users can help prevent vote bribery and effectively achieve resistance to collusion.

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

MACI voting rounds will move vote counting off-chain. The validity of the on-chain verification results will be proven through zero-knowledge proofs.

In MACI voting rounds, votes are encapsulated in messages encrypted with 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 a voting round ends, the administrator downloads all the messages, decrypts them, and counts the votes in reverse order. Then, the results are published together with a zero-knowledge proof, which can be verified on the smart contract (or by anyone else), marking the validity of the published results and the correctness of message handling.

The entire process ensures the integrity of the published results while maintaining minimal on-chain computation. It also provides privacy and resistance to collusion among users.

How does MACI work in practice?

MACI is now being used by various hackathon communities on DoraHacks[16] to vote for their favorite hackathon projects. So let’s take DoraHacks MACI round as an example.

OpenSea and Replit hackathon using MACI for judge voting in 2022

After the hackathon projects (BUIDL) are submitted, the organizers select 12 BUIDL teams from all the submissions. 10 judges are invited to vote for these 12 BUIDL teams and distribute a $25,000 prize. The 10 judges are whitelisted and participate in the voting round by sending a total of 39 messages to the MACI smart contract deployed on Polygon.

After the voting is completed, the administrator (DoraHacks) tallies the votes and publishes the final results on a leaderboard, providing zero-knowledge proofs to verify the leaderboard.

Leaderboard of the voting results for OpenSea x Replit hackathon.

Zero-knowledge proofs of the results displayed on the leaderboard.

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

The benefits of using blockchain to improve voting technology are obvious, so why hasn’t the real world progressed forward? Even within the blockchain community, the advantages of MACI are clear, so why isn’t MACI widely adopted by decentralized communities?

The main reason why advanced voting technology is slow to adopt is not because of low demand, but rather the difficulty of using this technology. In other words, we need to improve the technology to provide better UX/UI for modern voting products and reduce the user’s usage costs.

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 the best product in the industry for the Web3 ecosystem and the hackathon community to provide funding. Although the interfaces on DoraHacks.io have specific use cases, they can be simplified and generalized to build more interfaces for more use cases.

Specific frontend strategies have not yet been determined. However, good user experience is crucial for the adoption of this technology, even in the blockchain community – this is important for Dora Factory developers.

Voting Costs

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

To address this, Dora Factory recently tested a new product called Vota[17]. The idea of Vota is to try out purpose-built blockchains and leverage 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 Contracts

This is currently the way voting rounds are supported on DoraHacks.io. Each voting round is deployed as a separate smart contract on a specific blockchain. In most cases, Ethereum usually cannot directly support most voting scenarios (which is why Snapshot is the default product used by the Ethereum community). Currently, Polygon and BNBChain are the popular choices for most organizers and hackathon organizers on DoraHacks.

Temporary smart contracts on L1 blockchain, all voting messages sent to L1.

Using temporary smart contracts is not entirely a bad thing. It is flexible and can be deployed anywhere as needed. For DoraHacks users, it currently works well but cannot equally meet all voting needs.

L2 Vota

If we create a second-layer infrastructure (L2) specifically for voting, we can significantly reduce gas cost and may be able to achieve low-cost voting on Ethereum. L2 contracts do not have to be fully deployed on Ethereum, they can be cheaper and only occasionally submit L1 transactions to verify all L2 activities.

We can further optimize this model. The general L2 must be submitted to Ethereum frequently. Vota only needs to submit one transaction to Ethereum per round, at most one transaction’s gas cost per round. If multiple rounds end at the same time, they can share one transaction to further reduce gas costs, making voting on L2 more 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 the gas fee by an order of magnitude. Although L3 transactions are ultimately recorded and verified on Ethereum, the trade-off is to trust the chosen L2.

Of course, we can further extend this to L(n) Vota, as L(2)…L(n-1) will submit transactions to Ethereum (or other L1). But obviously, trust chains will make things complicated. 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

The developers of Dora Factory 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 typically support around 100 validators. By carefully selecting validators with conflicting interests, independent blockchains can be secure and neutral enough.

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

Application chain Vota has fewer validators, but carefully selected validators can provide reliable infrastructure.

It is worth noting that these solutions are not exclusive. As Vota evolves, different solutions may intersect. For example, if we have an independent 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 L1.

Better Anonymity

Ongoing research is aimed at making MACI more trustless. The initial MACI made an important trust assumption that the administrator would not be corrupt. This is not universal. To improve this, there are MPC-based [20] solutions and non-MPC-based [21] solutions. Currently, DoraHacks has built an anonymous version of MACI based on ElGamal verifiable random functions, which was originally proposed by Kobe Guikan. [22] It has been tested in a small ETH research grant round [23] on DoraHacks.io.

Currently, it may be a bit premature to promote the use of anonymous MACI before MACI itself is widely adopted. However, it is important to continue research to reduce the trust assumptions of general voting mechanisms.

By adding operations that allow users to disable and change their secret keys, anonymity can be added to MACI, and the administrator cannot know who added which new key.

GAS Payment

It is important not to assume that users have cryptocurrencies. If each user needs to pay gas fees for every transaction, the number of blockchain users will be limited to a small number of people. To solve this problem, MACI operators can deposit a refundable token in advance and pay the users’ fees. This mechanism can be implemented through a gas station.

The gas station itself is a smart contract residing on Vota. Before each round starts, the operator can choose to use it or not. By using the gas station, the operator can deposit DORA in the smart contract in advance and pay transaction fees related to 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 as needed.

The gas payment contract is a ledger of gas balances for each voting round.

Conclusion

Special-purpose blockchains may be suitable for a wide range of specific use cases, especially non-financial use cases. Voting is one of the most important issues that blockchain and zero-knowledge cryptography can significantly improve. Improving voting transparency and efficiency can reduce governance frictions within human society and blockchain communities, and in the long run, improve productivity. Protocols like MACI create a concise framework for voting applications on the blockchain, but there is still much work to be done to improve voting technology. Specifically, we need a user-friendly infrastructure as the foundation for long-term improvement of voting technology, and this article provides a detailed overview of future work.

References

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

The Long History of Voting Technology: https://electionlab.mit.edu/research/voting-technology

UK 2019 General Election: https://en.wikipedia.org/wiki/2019_United_Kingdom_general_election

Electronic Voting Machines: https://en.wikipedia.org/wiki/Dominion_Voting_Systems

Election Result Controversies: https://www.reuters.com/legal/dominions-defamation-case-against-fox-poised-trial-after-delay-2023-04-18

The Cost of Verifying and Auditing Voting 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

Financial expenditure plan: https://govforum.klaytn.foundation/c/proposal/5

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

Quadratic financing: 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 “hacker” that allows CosmWasm contracts to use: 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 solution: https://ethresear.ch/t/maci-anonymization-using-rerandomizable-encryption/7054

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

ETH research funding round: https://dorahacks.io/grant/ethre3/maci

We will continue to update Blocking; if you have any questions or suggestions, please contact us!

COSMOSDAOETHOpenSea

Was this article helpful?

93 out of 132 found this helpful