The State of Private Voting in Ethereum

This report delves into the critical and evolving landscape of private voting, particularly in digital surveillance, the erosion of civil liberties, and the emergence of centralization in the crypto space. We provide an overview of the significance of private voting, define key terms, outline points and criteria for evaluating voting methods, and discuss the feature set of various protocols. We also present a comparative analysis of private voting protocols in the Ethereum ecosystem, offering insights into their Privacy, censorship resistance, implementation complexity, and other essential attributes.

This report aims to enable developers who want to use private voting in their applications. By creating a simple analysis of the features of every protocol, they can quickly understand which protocol (or combination) covers their needs and dive quickly into the relevant documentation.

If you are the visual type, this report was also presented in Progcrypto 2023¹.

Why Private Voting is important

Star Wars Andor is a TV series set in Star Wars after the Republic’s fall and the Empire’s rise. We follow a band of rebels as they try to start the Rebellion.

One of the protagonists says:

The Empire has been choking us so slowly we are starting not to notice
- Luthen Rael

The global erosion of freedom is taking place gradually, resembling the Empire’s suffocating grip described by Luthen Rael. Digital surveillance is expanding, masquerading as a protective measure, yet it goes unnoticed by many.

In the aftermath of 9/11, the US pushed through the PATRIOT Act, a bill allowing unprecedented citizen surveillance. This surveillance only became apparent with Edward Snowden’s 2013 revelations².

Recently, the UK introduced legislation ³ requiring companies to scan their content for “child abuse content,” a task impossible with end-to-end encryption. It effectively outlaws encryption.

Civil and online liberties are being eroded under the guise of anti-terrorism, child protection, or convenience.

It’s not just in countries like Iran⁴ or China⁵. It’s also happening in Turkey⁶, Greece⁷, Russia⁸ and Hungary⁹.

Ideas that were once considered fringe and dystopian are now becoming mainstream.

Even in crypto, centralization is creeping in with the introduction of Central Bank Digital Currencies (CBDCs) ¹⁰. Stablecoins are currently leading in value settlement, ahead of Bitcoin. Cash, the ultimate privacy currency, is being phased out.

Privacy and, more specifically, private voting is emerging as one of our time’s most critical and consequential battlefields. We must have schemes where people can “signal” their preference for something digitally without fearing repercussions or punishment.

Definition

Glossary

• vote: A signal about ‘something’
• metadata: user-identifying information that is generated as a byproduct of voting (e.g. IP)
• vote weight: The number of votes a specific agent can cast
• tallying authority: The agent that is responsible for counting the votes and announcing the result of the vote
• relay: An agent that is responsible for receiving votes from users and re-broadcasting them in a specific manner
• trusted/untrusted setup: Whether the setup of parameters for the ZK protocol requires the existence of N honest agents
• briber: An agent that somehow signals their willingness to ‘pay’ other agents for them to signal something specific (e.g., cast a vote for X)
• data availability: The availability of data that are required for the vote, like the votes themselves

Points Criteria

We assign points to every method on a scale of 1-5 so that people can easily choose their preferred framework.

Features

We also note the features of the protocols from a distinct feature set we care about.

• Vote privacy: All votes are private to all but the tallying authority
• Metadata privacy: metadata is private
• Vote weight support: It supports vote weights
• Tallying Privacy: All votes are private while being tallied by the tallying authority
• Trusted setup: The ZK circuitry of the protocol requires a trusted setup
• Briber protection: The scheme protects against the existence of a briber
• Liveness assumption: The scheme assumes an agent is “live” throughout the process. If the agent is not, the process will halt.
• Derived membership: The scheme supports a dynamic membership that is derived from something else (e.g storage proof of an ethereum address) versus requiring users to “sign up”.

Private Voting on Ethereum

We start with an overview of protocols incubated in the Ethereum ecosystem. They might use Ethereum in different ways, from data availability to performing voting.

Summary

Please note that these tables are a simplification and do not capture all the nuances of each protocol. For a more detailed understanding, please refer to the individual sections for each protocol.

Features Summary

Points Summary

Composability

The protocols are composable. Private voting is not a monolith but a sequence of distinct activities, which can be implemented using different protocols and stacking them together.

In essence, a private voting scheme can be organized in the following stages:

1. Registration: In this initial phase, voters are authenticated and added to the voting group. This step ensures that each participant is eligible to vote and prevents double voting. At this stage, the protocol may implement some gatekeeping criteria (e.g all NFT holders).
2. Private Membership Proof: Before users can vote, they must prove they are part of the voting group. Private voting schemes enable users to prove that without revealing their true identity.
3. Voting: During the voting stage, voters cast their ballots. Votes may or may not be encrypted for the vote’s duration or even after.
4. Vote Aggregation: After all votes are cast, they must be collected and counted. This process can be facilitated by protocols that aggregate votes in a way that maintains voter privacy. Only valid votes are counted.
5. Result Publication: The vote results are published. It’s easy to prove the correctness of the aggregation if the votes are not encrypted. If they are, the tallying authority needs to generate some proof that the tally was correct.

The table below outlines various protocols and the specific stages of the process they address. It’s important to note that if a protocol does not encompass a particular stage, this does not imply a deficiency in the scheme. Instead, it indicates that the protocol specializes in a different aspect or component of the overall process.

Schemes can be layered to cover all the stages, for example, Semaphore (or Plume) and Cicada. With that combination, we have:

• Registration (Semaphore/Plume)
• Private membership proof (Semaphore/Plume)
• Voting encryption while the vote is active (Cicada)
• Vote aggregation (Cicada)
• Result publication and validation (Cicada)

Minimal Anti-Collusion Infrastructure (MACI)

MACI was first described¹¹ by Vitalik Buterin, with the primary goal of tackling collusion resistance while keeping Ethereum’s guarantees, such as provable correct execution and censorship resistance.

It employs zero-knowledge proofs to ensure the receipt-free voting process. This means that it can protect the secrecy of the vote while also providing a method to verify that the vote was counted without revealing the actual vote itself.

The infrastructure serves as a foundation that provides security against bribery and preserves the Privacy of digital voting. Its design ensures that nobody except a trusted coordinator can know the vote’s validity. This helps minimize the chances of bribery and collusion, especially in scenarios like public goods funding, where transparency and fairness are crucial.

How MACI works

1. Key Generation & Sign-up: users generate a private key pair and send a sign-up with it.
2. Vote Casting: When a user wants to vote, they generate a shared secret with the coordinator and encrypt a voting message. This encrypted message is sent to the smart contract on the blockchain. They may cast multiple votes for multiple vote options, so the total is within their voter credit limit.
3. Vote Processing: The encrypted messages are inserted into a Merkle tree and processed individually to update the state and ballot roots.
4. Command processing: A vote command can be invalidated if a) incorrectly signed, b) encrypted by someone who did not sign up in step 1, c) overridden by another vote with the same salt, and d) invalidated by a key change message. This prevents others from verifying how they voted, closing the door on coercion or bribery.
5. Tally Execution: Once the votes are processed and proof generated for the final state and ballot tree transitions, each voter ballot is tallied into the final vote count for each vote option using a zk-SNARK, which can be checked via a corresponding on-chain proof verifier.
6. Vote Privacy: Assuming a benevolent coordinator, the voter’s Privacy is protected throughout this process because the votes are never publicly decrypted. The zero-knowledge proof ensures that only valid votes are counted without showing their contents to anyone but the coordinator generating the proof.
7. Result Announcement: Finally, the results can be publicly announced without revealing individual vote choices, thus maintaining voter anonymity and preventing collusion or bribery.

MACI Points

• Censorship Resistance: 5/5
• Implementation Complexity: 4/5
• Reference Implementation: 4/5
• Ease of Use: 3/5
• Ease of Integration: 3/5
• Hardware Requirements: 5/5
• Anonymity Set: 3/5

MACI Features

• Vote Privacy: Only Trusted Coordinator can decrypt votes ✅
• Voter Privacy: Only Trusted Coordinator can link votes ✅
• Metadata Privacy: Relayer is out-of-scope ❌
• Tallying Privacy: Trusted Authority can read votes while being cast ❌
• No Trusted Setup: Groth16 ❌
• Briber Protection: Users can’t prove vote ✅
• Liveness Assumptions: Trusted Coordinator can halt the vote ❌
• Derived Membership: Users need to sign-up to be added to the member set ❌

How to Integrate MACI

• Understand the MACI smart contracts
• Read the integration guide and integrate MACI into your own smart contracts
• Use the MACI CLI to deploy and interact with the MACI contracts
• Provide instructions to your users on how to use the MACI cli or integrate the MACI typescript libraries into your CLI

MACI Useful Links

• MACI Github repository
• Original Ethereum Research post

Semaphore

Semaphore is a zero-knowledge protocol that enables users to cast a signal, like a vote or an endorsement, as a group member without revealing their identity. This protocol is handy for maintaining Privacy in private voting and whistleblowing activities and within anonymous, decentralized autonomous organizations (DAOs) and mixers. It prevents double-signaling and utilizes zero-knowledge proofs to verify a user’s group membership and the uniqueness of their signal.

Semaphore has two components:

1. on-chain Solidity contracts for group management and proof verification,
2. off-chain JavaScript libraries for creating identities, managing groups, and generating proofs

How Semaphore works

1. A user creates a Semaphore identity.
2. This identity is added to a group, structured as a Merkle tree, and can exist either on-chain or off-chain.
3. When users want to send an anonymous signal (such as a vote), they generate a zero-knowledge proof.
4. This proof confirms that the user belongs to the group and hasn’t previously sent a signal with their unique nullifier, a cryptographic term for a value that ensures signals cannot be linked to their sender after being cast.
5. The signal is broadcasted, and on-chain Solidity contracts verify the zero-knowledge proof.
6. Off-chain JavaScript libraries are used for tasks like creating identities and managing groups, while on-chain contracts manage group membership and validate proofs.

Semaphore Points

• Censorship Resistance: 5/5
• Implementation Complexity: 5/5
• Reference Implementation: 5/5
• Ease of Use: 5/5
• Ease of Integration: 5/5
• Hardware Requirements: 5/5
• Anonymity Set: 3/5

Semaphore Features

• Vote Privacy: Votes are not encrypted ❌
• Voter Privacy: Voter ID is encrypted ✅
• Metadata Privacy: Relayer is out-of-scope ❌
• Tallying Privacy: Votes are not encrypted ❌
• No Trusted Setup: Groth16 ❌
• Briber Protection: Users can prove vote ❌
• Liveness Assumptions: Vote can’t be halted ✅
• Derived Membership: Users need to sign-up to be added to the member set ❌

How to integrate Semaphore

• Take a look at the Guides to understand the fundamental concepts
  • Identities: A specific user.
  • Groups: A group of users.
  • Proofs: Proof that a user (Identity) belongs to a specific Group, without revealing who the user is.
• Look at the deployed contracts to see if the chain you want to use is already there. If not, you will need to deploy these contracts yourself.
• Consider whether you want to use on-chain or off-chain groups. For example, an on-chain group would be the holder of some NFT.
• Follow the integration guide in the docs

Semaphore Useful Links

• Semaphore implementation for Zuzalu:
  • Groups are created and managed by a back-end server, which gates the sign-ups using a ticketing platform
  • On-chain Oracle updated the group’s Merkle root in a smart contract, enabling users to build smart contracts where they can anonymously prove their participation in the group. For example, mint an NFT only if you are part of Zuzalu

Cicada

Cicada is an innovative approach to on-chain voting that emphasizes tallying Privacy and transparency, aiming to overcome the drawbacks of existing on-chain voting protocols. Cicada has implemented an open-source Solidity library that utilizes time-lock puzzles and zero-knowledge proofs to achieve private on-chain voting. These cryptographic tools ensure that voters can cast their ballots in secrecy, safeguarding against manipulation and preserving the integrity of the voting process.

The time-lock puzzles used in Cicada ensure that ballots are kept secret during the voting period and are only revealed afterward, allowing for private tallying without relying on authorities or trusted parties. To maintain this Privacy and prevent attacks, Cicada incorporates zero-knowledge proofs that validate each ballot’s authenticity without revealing the voter’s choice, ensuring efficient and secure participation.

Cicada is not meant to be used on it’s own, but rather to be combined with a membership-set proof (e.g Semaphore). The result is a vote where all voters are Private, and there is Tallying Privacy.

How Cicada works

1. Voter Prepares Ballot: The voter decides on their vote (yes or no) and prepares a time-lock puzzle containing this vote. The puzzle is designed not to be solved until after the voting period ends.
2. Creating Zero-Knowledge Proof: The voter generates zero-knowledge proof. This proof demonstrates that their time-lock puzzle contains a valid vote (e.g., a “1” for yes or a “0” for no) without revealing what the vote isv
3. Submitting the Vote: The voter submits the time-lock puzzle and the zero-knowledge proof to the blockchain. This transaction is visible, but the vote contents are not due to the time-lock puzzle.
4. Waiting Period: The vote remains encrypted and hidden throughout the voting period. No one can see how anyone else voted during this time.
5. Puzzle Solving: The time-lock puzzle can be solved after the voting period ends. This process requires performing specific computational work that cannot be expedited or parallelized, enforcing a fair and consistent reveal time.
6. Vote Tallying: Once the puzzles are solved, the votes are revealed and can be tallied to determine the outcome of the vote.

Cicada Points

• Censorship Resistance: 5/5
• Implementation Complexity: 3/5
• Reference Implementation: 3/5
• Ease of Use: 4/5
• Ease of Integration: 4/5
• Hardware Requirements: 5/5
• Anonymity Set: 1/5

Cicada Features

• Vote Privacy: Votes are not encrypted ❌
• Voter Privacy: Voter ID is not encrypted ❌
• Metadata Privacy: Relayer is out-of-scope ❌
• Tallying Privacy: Votes can’t be decrypted while the vote is active ✅
• No Trusted Setup: RSA modulus ✅
• Briber Protection: Users can prove vote ❌
• Liveness Assumptions: Vote can’t be halted ✅
• Derived Membership: Users need to sign-up to be added to the member set ❌

How to Integrate

Cicada is an exciting scheme because it can be layered on top of other protocols, such as Semaphore, to give them the unique property of Tallying Privacy.

A16z provides this example repository, which combines Cicada with Semaphore. Semaphore handles the group management part of the voting protocol, while votes are encrypted through time-lock puzzled in the Cicada smart contract.

Let’s dive into this a bit more:

• CicadaVote.sol is the base contract and implements the functionality that has to do with vote creation and ballot encryption. It’s meant to be inherited by the user’s contracts.
• SemaphorCicada.sol inherits CicadaVote.sol and implements the group management functionality. Most notably, it verifies that a voter hasn’t voted before in this particular vote and that they provide a valid group membership proof.

Obviously, Semaphore can be substituted for any other protocol, like Plume or RLN or even something non private, like simply verifying the ownership of an NFT.

Plume

Plume is a system designed to enable unique pseudonymity on Ethereum, allowing for the creation of anonymous sybil-resistant applications like private voting. Plume enables the creation of “burner accounts” tied to some Ethereum address. Users can prove that the burner accounts were generated from the given set and then use these accounts to vote. Finally, the nullifier makes it impossible for a user to signal something more times than it should (e.g., 1 vote per address).

The infrastructure for Plume includes:

• Deterministic signature calculations.
• Circom circuits for hashing to elliptic curves.
• Integrations with wallets like Metamask and Ledger.

The specifications of Plume are formalized in ERC-7524, aiming to be used for private voting applications and other systems that require unique pseudonymity.

Plume does not handle set management and is expected to be combined with another protocol that creates the set.

How Plume works

1. Eligible Address List: An entity, such as an airdropper, publishes a list of eligible addresses for a specific activity, like voting.
2. Burner Accounts: If you control an eligible address, you create a burner account to perform the activity, such as casting a vote.
3. Proof of Control: You anonymously prove that you control an eligible address not already used for the activity.
4. Gas Fees and Anonymity: For on-chain applications that require gas, if the burner account doesn’t have funds, you can send your proofs to relayers who front the gas and post the proof on-chain, maintaining anonymity.

Plume Points

• Censorship Resistance: 5/5
• Implementation Complexity: 4/5
• Reference Implementation: 3/5
• Ease of Use: 3/5
• Ease of Integration: 1/5
• Hardware Requirements: 5/5
• Anonymity Set: 4/5

Plume Features

• Vote Privacy: Votes are not encrypted ❌
• Voter Privacy: Voter ID is encrypted ✅
• Metadata Privacy: Relayer is out-of-scope ❌
• Tallying Privacy: Votes can be decrypted while the vote is active ❌
• No Trusted Setup: Groth16 ❌
• Briber Protection: Users can prove vote ❌
• Liveness Assumptions: Vote can’t be halted ✅
• Derived Membership: Users can be derived from any ethereum address ✅

How to Integrate Plume

1. Understand the Specification: Review the ERC-7524 spec, which formalizes Plume, to understand the requirements and how it functions.
2. Take a look at the demo
3. Take a look at the Metamask Snap which the users will use to generate the required nullifiers
4. Consider what technology you will use to create the initial set of users. One catch is that you need to combine the PLUME proof and the set membership proof so that your protocol is specific that the set membership proof and burner account proof concern the same address.

Although Semaphore seems like an easy choice for set membership proof, it defeats the point of PLUME since it’s opt-in. On the other hand, storage proofs are a much better fit since they work without the user opting in. This is an important point and arguably one of the most essential features of PLUME.

For example, if you want to allow private voting for all the holders of some NFT with Semaphore, you will have to update the group constantly on every transfer. Either you shoulder the gas cost of continually updating the group’s route or integrate it into the NFT transfer method, which increases the gas cost for the users.

On the other hand, when users want to vote with PLUME, they have to generate, at that moment, the storage proof that their address belongs to the mapping of NFT holders and then create the burner address and the PLUME proof. Packaged nicely in a Metamask Snap, this flow makes PLUME a very appealing choice for its cryptographic features and the UX.

Unfortunately, it’s still being developed, and the user must do much more work to integrate it. For example, their demo uses Semaphore. A user wishing to do it via storage proofs must create a new circuit and add it to the existing PLUME circuit or use something like Axiom to integrate it with Plume.

Aragon/Aztec Private Voting Project

The NounsDAO private voting project¹² aimed to address challenges with public voting in DAOs by ensuring anonymity, vote confidentiality, and outcome confidentiality. Two teams, Aztec Labs and Aragon ZK Research (AZKR)¹³, collaborated on this, with Aztec focusing on implementing storage proofs in Noir and AZKR designing the voting solution powered by these proofs. The voting system allows users to anonymously prove their membership (as a “Noun”) and vote in the DAO.

The project has shared its findings and continued with zk-POPVOTE (zk Proof-based On-chain Private Voting) as per their roadmap.

How the Private Voting Works

1. Wallet Registration: Wallets must be registered to participate, generating a public-private key pair. They develop an anonymous “burner” private-public key pair uniquely tied to their address.
2. Voting Process Setup: A voting process is created with details like the proposal link and voting period.
3. Vote Generation: Registered wallets generate a ballot and corresponding storage proof that they are owners of a Noun NFT. Although the proof is generated for the user’s address, they use their burner addresses to submit the votes.
4. Submission: Votes are submitted to the Nouns voting smart contract.
5. Tally: The tallying proof is generated and submitted, concluding the vote.

The system’s achievements include:

• The use of Ethereum storage proofs for a trustless census.
• Leveraging Aztec’s Noir language for zk-SNARKs.
• The creation of an efficient cryptographic time-lock protocol.

Despite its progress, the system faces limitations like performance bottlenecks and reliance on CLI, which future updates aim to address.

Aragon/Aztec Private Voting Points

• Censorship Resistance: 5/5
• Implementation Complexity: 3/5
• Reference Implementation: 3/5
• Ease of Use: 3/5
• Ease of Integration: 2/5
• Hardware Requirements: 2/5
• Anonymity Set: 4/5

Aragon/Aztec Private Voting Features

• Vote Privacy: Votes are encrypted ✅
• Voter Privacy: Voter ID is encrypted ✅
• Metadata Privacy: Relayer is in-scope ✅
• Tallying Privacy: Votes are encrypted to the tallying authority ✅
• No Trusted Setup: UltraPLONK ❌
• Briber Protection: Users can prove vote ❌
• Liveness Assumptions: Vote can’t be halted ✅
• Derived Membership: Users can be derived from any ethereum address ✅

How to integrate the Aragon/Aztec Private Voting Project

This project results from a design sprint, and it’s not meant to be a generic solution for people to adopt and integrate.

That being said, the ZKregistry, the component responsible for creating the “burner” addresses, is generic and can be used for any process. The component that one would need to modify to use this stack is the one used to generate the storage proofs for the Noun NFT smart contract.

It’s cleaner to modify the storage proof, so let’s see that in greater detail:

The system is set to generate storage proofs for the owners of Nouns, which are managed by the Nouns Token smart contract. By reading the code on GitHub, we can see where the specific storage slot is defined:

• Generate proof
• Verify proof

By changing the offset, according to how Solidity constructs the storage layout, we can create proofs for other slots and contracts. This is the first step to integrating this protocol into ours.

The next step is for the developer to inspect the CLI and make any required changes to that, based on the fact that they use different intelligent contracts from the ones referenced in the CLI.

Aragon/Aztec Private Voting Useful Links

• Github repository
• Technical Report

Rate-Limiting Nullifier (RLN)

Rate-Limiting Nullifier (RLN) is a zero-knowledge gadget designed for spam prevention in settings where users are anonymous. Anonymity can often lead to spam, which RLN addresses by allowing the identification and removal of spammers without compromising user privacy.

How RLN works

1. Registration: A user generates a secret key and, from it, an identity commitment using the Poseidon hash function. They register with the application by providing a stake and this identity commitment, which is then stored in a membership Merkle tree.
2. Interaction: For actions within the application, the user creates a zero-knowledge proof to confirm that their identity commitment is part of the membership Merkle tree. This process includes rules like limiting interactions per epoch (e.g., X votes per Election), enforced by the application’s verifier.
3. Withdrawal/Slashing: If a user exceeds the interaction limit, their secret key can be reconstructed, removing them from the membership tree and losing their stake. This punitive measure makes spamming economically unfeasible.

This three-part process ensures that users can engage with applications anonymously while maintaining accountability for actions like voting or messaging.

RLN Points

• Censorship Resistance: 5/5
• Implementation Complexity: 4/5
• Reference Implementation: 3/5
• Ease of Use: 3/5
• Ease of Integration: 3/5
• Hardware Requirements: 5/5
• Anonymity Set: 3/5

RLN Features

• Vote Privacy: Votes are not encrypted ❌
• Voter Privacy: Voter ID is encrypted ✅
• Metadata Privacy: Relayer is out-of-scope ❌
• Tallying Privacy: Votes are not encrypted ❌
• No Trusted Setup: Groth16 ❌
• Briber Protection: Users can prove vote ❌
• Liveness Assumptions: Vote can’t be halted ✅
• Derived Membership: Users need to sign-up to be added to the member set ❌

How to Integrate RLN

• Inspect the Foundry Template for the registry smart contract. This is used to manage the group.
• Create a contract that handles the logic of the vote.
• Use the Javascript/Typescript libraries to interact with the smart contracts and generate the required RLNs

Secondary Tools

Although these tools are not purpose-built for private voting, they offer exciting properties that could interest builders.

Axiom

Axiom is a zk co-processor for Ethereum. That means that it uses ZK proofs to enable smart contracts on Ethereum to trustlessly access the historical state of the chain. By providing the state with proof that the state is correct, a smart contract can trust the input without trusting the person who inserts that input.

Although Axiom doesn’t support private-oriented queries, it could be used to generate storage proofs for privacy schemes.

Axiom Interesting Links

• Nouns Props House Proposal
• Documentation

Risc0

Risc0 is a zero-knowledge verifiable computing platform that leverages zk-STARKs and the RISC-V microarchitecture to enable the execution and verification of arbitrary code with strong privacy guarantees. It includes a Zero-Knowledge Virtual Machine (zkVM) capable of running code written in Rust and C++, producing cryptographic proofs that validate the correct execution of that code without revealing any sensitive data.

Bonsai, an integral part of the Risc0 ecosystem, is a decentralized proving engine and a set of smart contracts on Ethereum that facilitates the integration of Zero-Knowledge proofs into applications, enhancing their security and Privacy. This combination allows developers to create applications that can perform complex computations and verifications while maintaining the confidentiality of the underlying data.

Risc0 is a platform where one could create a private voting scheme, although it would be much less efficient than the purpose-built constructs described above.

Risc0 makes some tradeoffs regarding proving speed and cost in exchange for its generalisability.

Risc0 Interesting Links

• Bonsai Foundry Template
• Documentation

Future Research

FHE in EVM

Full Homoformic encryption is an actively researched space in EVMs. However, although there are significant strides, like Zama, it still needs to mature enough to be used by applications, as the gas cost makes it impractical. Zama currently relies on external validators to verify the correctness of the FHE computation and attest to it.

FHE in EVM Interesting Links

• Zama

Aleo L1

Aleo is still in testnet, but the protocol would easily support a private voting scheme. Aleo incentivizes developers to build on top of it, which could be an exciting opportunity. There are better choices for developers who wish to integrate private voting into their system than Aleo.

Aleo Interesting Links

• Website
• Documentation

DarkFi L1

DarkFi is a Layer 1 blockchain specifically designed to prioritize anonymity. It utilizes advanced zero-knowledge cryptography to allow developers to create applications that operate with a high degree of Privacy. The platform offers flexible primitives for Privacy, enabling the creation of a wide range of applications while ensuring user anonymity. DarkFi aims to democratize anonymous engineering, making it easy and accessible for developers to build applications that preserve user privacy without compromising functionality.

DarkFi is currently in testing and will launch the mainnet sometime in the future. When found, it will ship with several smart contracts essential to its vision, including one to perform staple DAO activities, such as private voting.

DarkFi Interesting Links

• Website
• Documentation

Acknowledgements

This report is financially supported by MolochDAO¹⁴. I couldn’t have made it without the support of all the creators of these protocols, who were eager to answer any question I had.

A special thank you to Aayush Gupta¹⁵, one of the creators of Plume, who helped me understand the nuisance of the required cryptography.

References