The problem FHE Voting solves

Decentralized private voting is vital in digital democracies, ensuring vote privacy and integrity without trusted third parties, which risk tampering and coercion. Cryptographic techniques like ZK and FHE address these challenges, enabling secure, private, and trustless voting systems.

Methods using ZK rely on custom circuits and multi-step protocols, which can be complex to implement and verify. Additionally, some ZK solutions introduce extra steps or require a trusted coordinator. While it's challenging to generalize all the potential ZK solutions for private voting, it's fair to say that the FHE approach is conceptually simpler and opens up new possibilities for voting applications that can utilize a shared encrypted state.

FHE Voting does not require custom circuits (from an application perspective) that would need a complete redesign when adding extra functionality. This makes the FHE approach more adaptable and flexible.

Our app ensures secure and private voting. Votes remain confidential and are only revealed once the election is finalized, enhancing security and trust. The voting process is transparent and simple for users, requiring only one action: voting.
The steps mirror real-world processes but with enhanced privacy, integrity, and anti-collusion properties.

For example, the MACI protocol developed by the Ethereum Foundation's PSE requires a trusted coordinator who can decrypt the votes or halt the voting. In contrast, our FHE Voting approach does not require a trusted coordinator, ensuring that votes are truly private and the election is conducted according to the rules specified in the smart contract. This is a significant improvement over previous solutions to the private voting problem.

Challenges we ran into

Since FHE is a relatively new and cutting-edge technology, implementing it in a voting system posed several challenges.

Fhenix did a good job of making FHE compatible with EVM, however, many of the standard tools and function in solidity development were not available. It is possible to use either Hardhat or Remix which is quite limited and no-longer industry standard.

Integrating FHE with other technologies like Solidity for smart contracts, Hardhat for development and testing, and modern frontend frameworks like React and Next.js required overcoming compatibility and efficiency limitations, and a ton of boilerplate code. In addition, performance could be an issue when scaling.

Despite these challenges, the project demonstrates feasibility but more importantly the potential of FHE in creating secure and private voting systems.

Here is a list of some (of the many) the non supported standard functionalities we encountered:

• In hardhat, many commands used to manipulate the local node are not available, for example: evm_increaseTime, etc. This makes it hard to test any voting locally since it is time-based.
• Only 8, 16 and 32 Bit Integer Bit Sizes are supported
• In react, client side rendering is not supported by the Fhenix Wasm implementation. Also, wagmi is not supported but we managed to make most multi-wallet functionalities work.
• Fhenix testnet is at the moment on early release and somewhat unstable which makes testing on it quite a challenge.