Blockchains can serve functions beyond monetary and financial transactions.
One type of non-financial application that blockchains can greatly improve is voting. In this article, we explore ways to build a special-purpose infrastructure that serves to facilitate MACI based voting activities. The infrastructure should consist of a light-weight blockchain acting as a time stamping server and hosting logics, and necessary tools to reduce costs of users / maximize user experience. As a result, it should evolve into a new foundation platform for new generations of voting technology.
Before we dive into the details, let’s first review the history of voting technology and how voting evolved within the blockchain communities.
The evolution of voting technology
Voting technology has a long history. It’s something very important for human societies but evolves very slowly. The UK still relied on hand-written ballots during the 2019 Brexit General Election, other nation states use closed-source electronic voting machines that could easily create room for disputes over election results.
The adoption of modern voting technology improved efficiency, but has not been as much successful to address transparency and verifiability.
Needless to say, voting integrity is very important in transfer of power, decision on important issues, or resource distribution. If people cannot agree on voting results over governance decisions, they cannot work with each other, and friction will increase. The friction can cause problems, from disputes to wars.
Although voting technology is slowly evolving, transparency has not been improved much over time. From Kleroterion to paper ballots, then to electronic and optical scan voting machines, verification still depends on trusted individuals and auditing organizations. Confirming and auditing voting results can be extremely costly. There is definitely room for improvement.
So what is the ideal voting technology? Actually this is not a difficult question. We can easily create a “wishlist”:
(1) The infrastructure is open source;
(2) Host open source programs for voting logics;
(3) Permanent records of all votes in order;
(4) Ability to cryptographically verify results;
(5) Collusion resistant;
(6) Preserve privacy;
(7) Low cost to vote.
If we can build an open source system which can be continuously improved, we will gradually achieve the above goals. The improvement of voting technology and the reduction of cost can benefit smaller organizations and communities to use technology they didn’t have access to before, which adds great positive externality.
Voting and governance within blockchain communities
Voting and governance are no stranger in the blockchain communities, because many blockchain communities are distributed, and they have to rely on governance to keep things moving.
Blockchains themselves can transparently record votes, and verify voting results. These properties have been used by blockchain communities for governance, such as snapshot token voting and cosmos governance proposal voting activities. As a result, blockchain communities can vote for proposals and decide on important governance issues without going through centralized agents or meeting in-person.
The aforementioned examples adopt a straightforward 1-token-1-vote rule - how much voting power you have depends on the stake you have in a network or a protocol. Obviously, we can invent other voting logics as long as they make sense. The programmability of blockchains makes it much easier and more practical to implement non-conventional voting logics.
One example is quadratic voting (QV), a voting scheme with growing popularity within blockchain communities. In a QV round, a voter can express his/her preference by spending “voice credits” on particular subjects. But if a voter wants to cast more than one vote on the same subject, the cost of voice credits per vote increases. Therefore, the total cost of votes increases quadratically, discouraging extreme preferences from voters who have excessive voting power.
There are many parameters to consider when choosing a particular way to vote. For example, one tradeoff is the choice between on-chain voting and off-chain voting. An on-chain voting logic can be more verifiable and transparent, but gas cost can be a significant burden. In contrast, an off-chain voting logic can be cheap, but at the same time much less transparent and verifiable. Though on-chain vs. off-chain voting is not binary. You can easily imagine hybrid systems in which part of the process goes on-chain and the rest is done off-chain.
Beyond cost, there is also the concern of privacy. Privacy is important because of two reasons. First, in many cases, if voters can vote anonymously (privacy between users and the authorities), they will have less concerns to vote. Furthermore, privacy between users can help prevent vote bribery, effectively achieving collusion resistance.
One way we can minimize computation on-chain while enforcing integrity off-chain is to use zero-knowledge proof. 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 messages are further encrypted, we can enhance privacy. MACI is a minimal framework to achieve this goal.
In a MACI voting round, votes are wrapped in a message encrypted by a public key generated by a round admin (operator) and submitted to a smart contract. As a result, all messages are “time stamped” by the blockchain, creating a chain of voter messages.
When the voting round ends, the operator downloads all messages, decrypts them, and tallies the votes in a reversed order. Then she publishes the results together with a zero-knowledge proof, which can be verified on the smart contract (or by anyone else), signaling the validity of the published results as well as the correctness of message processing.
The whole process maintains minimal on-chain computation while guaranteeing integrity of the published results. It also provides privacy and collusion resistance between users.
How does MACI work in a real product?
MACI is now used by various hackathon communities on DoraHacks to vote for their favorite hackathon projects. So we take DoraHacks MACI product as an example.
After the hackathon submission, 12 BUIDL teams were selected from all submissions by the organizers. 10 judges were invited to vote for these 12 BUIDL teams and distribute a $25,000 prize pool. The 10 judges were whitelisted to sign up for the voting round, and they casted 39 messages in total to a MACI smart contract which was deployed on Polygon.
After voting finished, the operator (DoraHacks) tallies the votes and posted the final results to the leaderboard, then provides a zero-knowledge proof to validate the leaderboard.
As a general framework, MACI can work for voting use cases beyond hackathon judge voting and open source community voting. However, it’s surprisingly rare to see MACI being adopted in more voting use cases. And more broadly, blockchain voting itself is very much unadopted in the real world.
With the obvious benefits of using blockchain to improve voting technology, why is the real world not moving along? Even within the blockchain community, with obvious benefits of MACI, why isn't a decentralized community adopting MACI in general?
One major reason for slow adoption of advanced voting technology is not because of low demand, but the difficulties to use such technology. In other words, we need to improve the technology with much better UX/UI for modern voting products, and much lower costs for users to use.
User experience
Other than open source community governance, we need to build more interfaces for users to use new voting technology. DoraHacks has provided a promising interface for Web3 ecosystems and hackathon communities to fund projects. Although the interface itself on DoraHacks.io has specific use cases, it can be simplified then generalized to build more interfaces for more use cases.
The specific frontend strategy is yet to be determined. However, a good UX is critical for the technology to adopt even within the blockchain community - something important for Dora Factory developers to work on.
Cost to vote
General-purpose blockchains are supposed to be as decentralized 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 fees will fluctuate. The unpredictability of cost is going to be troublesome for voting.
For this reason, Dora Factory recently tested a new product called Vota. The idea of Vota is to experiment with special purpose blockchains and use them to continuously optimize voting technology and user experience. For now, Vota is in its infant stage. However, we can imagine a few different forms of Vota.
Ad-hoc smart contracts
The current way of supporting voting rounds on DoraHacks.io. Every voting round is deployed as a separate smart contract, on a specific blockchain. Most of the time, Ethereum is unable to support any voting round directly unless the stake is really high (this is why Snapshot is the by-default product to use for Ethereum communities). Polygon and BNB Chain are popular choices for most grant organizers and hackathon organizers on DoraHacks for now.
It is not entirely bad to use ad-hoc smart contracts. It’s flexible, you can deploy it anywhere based on the needs. It so far works well for DoraHacks users, but it cannot work equally well to satisfy all voting demands.
L2 Vota
If we create a special-purpose L2 just for voting, we can significantly lower gas fee costs and we might be able to make low-cost voting on Ethereum. Instead of deploying all logics on Ethereum, L2 contracts can be much cheaper, and it only needs to submit L1 transactions from time to time to validate all L2 activities.
We can further optimize this model. General-purpose L2s have to submit to Ethereum frequently. Vota can submit one transaction to Ethereum per round, i.e. only up to one transaction’s gas fee cost is necessary for each round. If multiple rounds end around the same time, they can share one transaction to further reduce gas cost, making a voting L2 more realistic.
L3 Vota (Applies to L(n) Vota where n>=3)
An L3 Vota is not totally pointless. Through an established L2, an L3 Vota can further reduce gas fees by potentially one magnitude. Although L3 transactions are eventually recorded and validated on Ethereum, the tradeoff is to trust the chosen L2.
Naturally, we can further extend it to L(n) Vota, given that L(2) … L(n-1) will submit transactions to Ethereum (or other L1s). But obviously a chain of trust will complicate things. Based on the current situation, many prominent L2s still rely on solo sequencers; it might be too early to talk about L(4).
Appchain Vota
The Dora Factory developers have created a simple “hack” that allows a CosmWasm contract to verify SnarkJS generated zero-knowledge proofs with Bellman. By incorporating Bellman into a CosmWasm contract, any Cosmos appchain can quickly support zk applications.
With the capability of running zk applications, an independent blockchain can use software architectures like Tendermint to build a chain. The consensus of these blockchains are BFT-like, therefore they can normally support up to 100-ish validators. By carefully selecting validators who are not interest aligned, a standalone blockchain can be sufficiently secure and neutral.
It’s important to note that these solutions are not exclusive. As Vota develops, different solutions might intersect. For example, if we have an independent appchain version of Vota as the main infrastructure, for use cases that need transaction verification on specific L1s, the appchain can send an extra transaction to the L1.
Better Anonymity
There are ongoing research and engineering efforts to make MACI more trustless. The original MACI makes an important trust assumption that the operator is not going to corrupt. This is not universal. To improve on this point, there are MPC based solutions and non-MPC based solutions. Currently, DoraHacks has already built a version of anonymous MACI based on ElGamal Rerandomizable Encryption, originally proposed by Kobe Guikan. It has been tested during a small ETH Research Grant round on DoraHacks.io.
It might be an overkill at this moment to push adoption for anonymous MACI before MACI itself is widely adopted. However, it is also important to continue the research to reduce trust assumptions of voting mechanisms in general.
Gas Payment
It is important to not assume users have cryptocurrencies. If every user is required to pay gas fees for every transaction, the blockchain’s users will be limited to a small group of people. To solve this problem, MACI operators can pre-deposit a refundable sum of tokens and pay for voters’ costs. The mechanism can be achieved with a gas station.
The gas station itself is a smart contract that resides on Vota. Before each round starts, the operator can either use it or not use it. By using the gas station, the operator pre-deposits DORA tokens into the smart contract, and transaction cost associated with a particular round can be paid via the gas station.
Most likely, Vota will deploy a default gas station, and people can deploy their own gas station with different payment logics on-demand.
Conclusion
Special purpose blockchains can potentially work for a wide range of application specific use cases, especially non-financial use cases. Voting is one of the most important problems that blockchain and zero-knowledge cryptography can help improve significantly. Improving voting transparency and efficiency can reduce frictions in governance among human societies and all types of communities, and increase productivity in the long term. Protocols like MACI create concise frameworks for voting applications on blockchain, but much needs to be done for voting technology to improve. Specifically, we need a user-friendly infrastructure as a foundation to continuously improve voting technology, and this article detailed the work ahead.