Grant Application for Developing a Decentralized Secure Voting System Using FHEVM

[Maniveer007]

Bounty Name: Developing a Decentralized Secure Voting System Using FHEVM

Bounty Type: Major Bounty

Category: Application

Library Targeted: FHEVM

Reward: 2500 €

Problem Statement:

Traditional voting systems are often plagued by concerns regarding security, transparency, and integrity. Issues such as voter fraud, tampering with ballots, and hacking of electronic voting machines continue to undermine the credibility of election outcomes. Moreover, centralized control over voting processes raises questions about fairness and accountability.

Overview:

Our proposal seeks to address these challenges by developing a decentralized voting system that utilizes FHEVM for secure data processing on the blockchain. By integrating advanced encryption techniques, we aim to achieve end-to-end verifiability, ensuring that votes remain confidential while also enabling transparent auditability of election results.

Deliverables:

Design and Implementation of FHEVM-based Smart Contracts:

Develop smart contracts on the blockchain to facilitate the voting process, ensuring privacy, security, and transparency. Implement Fully Homomorphic Encryption (FHE) to enable secure computation of encrypted votes while preserving voter privacy.

Decentralized Voting Application:

Build a user-friendly application that allows voters to securely cast their encrypted ballots using FHE encryption techniques. Provide features for voter authentication, ballot casting, and verification of vote integrity.

Documentation and Education:

Create comprehensive documentation, tutorials, and educational resources to promote understanding and adoption of the decentralized voting system.

Timeline:

Phase 1: Smart Contract Development (Estimated Duration: 4-6 Days) Phase 2: Application Development (Estimated Duration: 6-8 Days) Phase 3: Documentation and Education (Estimated Duration: 2-4 Days)

Total Estimated Timeline: 12-18 Days

Budget:

We are requesting funding in the range of 2500 € to support the development, testing, and deployment of the decentralized voting system. The budget will cover expenses related to software development, research, project management, and outreach activities.

Conclusion:

Our team is passionate about leveraging cutting-edge technology to enhance the democratic process and promote trust in elections. With your support, we believe that we can develop a decentralized voting system that sets a new standard for security, transparency, and integrity in electoral processes.

Thank you for considering our grant proposal. We look forward to the opportunity to collaborate with you on this important endeavor.

Warm regards,

Maniveer007

[zama-bot]

Hello Maniveer007,

Thank you for your Grant application! Our team will review and add comments in your issue! In the meantime:

1. Join the FHE.org discord server for any questions (pick the Zama library channel you will use).
2. Ask questions privately: bounty@zama.ai.

[aquint-zama]

Grant accepted, Let's build 🚀

[Maniveer007]

Here is the GitHub link to project: https://github.com/Maniveer007/VotingDapp.git

[aquint-zama]

Hello @Maniveer007,

We just finished the review of your first submission. We have several concerns about the technical choices you made in your smart contract, that are not following best practices for fhEVM:

In VoteRegistry: 1/ No need to encrypt CountryCode in the VoterDetails struct, this information is leaked anyway when registrar calls addVoter because of the copy of registrar's country in newIdentity, or allow registrar to chose custom country when adding voter. No interest in doing both 2/ avoid use of any decrypt if possible, for eg in onlyRegistrarOf this is not needed.

In VotingDapp: 3/ No need to use an encrypted id for the Candidate structure. 4/ Don't use decrypt in CastVote: this can be replaced by a CMUX. 5/ Add a time limit for voting instead of letting election officer to call calculate_Results at any time. 6/ Election could not be finished in case of tie. 7/ requestvoters could have been a mapping instead of an array. Also not sure about how useful it is to do the request onchain, but why not… notice that the array could contain duplicates in this case, wasting storage. 8/ in giveVoteRight dont use an encrypted type for _acceptance, since it is directly decrypted anyways, use bool instead.

In the current status of the submission, it requires a lot of rework, and on our side it has already took a lot of time to review. We could bring some help but not do the code by review iterations.

This submission is not accepted as a solution and we are closing this grant topic.