ZeroKnowledgeVoting

ZeroKnowledgeVoting

ZeroKnowledgeVoting is a demo application that allows voters to cast votes anonymously while ensuring the integrity of the voting process. It also leverages zkVerify ZK-proof verification blockchain.

Created on 9th December 2024

ZeroKnowledgeVoting

ZeroKnowledgeVoting

ZeroKnowledgeVoting is a demo application that allows voters to cast votes anonymously while ensuring the integrity of the voting process. It also leverages zkVerify ZK-proof verification blockchain.

The problem ZeroKnowledgeVoting solves

The Problem This Project Solves
This project addresses critical challenges in secure, private, and decentralized voting systems, leveraging zero-knowledge proofs (ZKPs) and blockchain technology to enhance trust, transparency, and privacy in democratic processes. Traditional voting systems, whether online or in-person, often face the following issues:

  1. Privacy Concerns
    In conventional voting systems, ensuring voter anonymity while maintaining transparency is a significant challenge. Voters need assurance that:
  • Their vote cannot be linked to their identity.
  • Their participation remains confidential.
    This project uses ZKPs to allow voters to prove eligibility and cast votes without revealing their identity or the specific details of their vote, ensuring complete privacy.
  1. Security Risks
    Traditional electronic voting systems and centralized online voting platforms are vulnerable to:
  • Hacking and Manipulation: Centralized systems present single points of failure.
  • Fake or Invalid Votes: Verifying voter eligibility while preventing fraudulent activities is challenging.

The project enhances security by using blockchain to create a tamper-proof and decentralized ledger.
Implementing cryptographic methods (ZKPs and Merkle proofs) to validate voter eligibility without exposing sensitive data.

  1. High Costs of Proof Verification
    The computational and financial costs of verifying cryptographic proofs, especially in large-scale applications, can be prohibitive. Traditional ZKP systems often require significant resources for validation.

This project integrates zkVerify’s efficient Groth16 verifier to minimize the costs associated with proof validation and enable practical and affordable implementation of ZKP-based systems.

Challenges we ran into

  1. Compatibility Between Curves (BLS12-381 vs BN128)
    Challenge: Initially, we aimed to use the BLS12-381 curve due to its strong cryptographic properties. However, the Poseidon hash function implementation for Merkle proofs resulted in mismatched roots when using BLS12-381. Additionally, the proof generation failed outright with this curve.
    Solution:
    Switched to the BN128 (also known as BN254) curve, better supported by the zkVerify framework and compatible with the Poseidon hash implementation we were using.
    Confirmed that the circuit was optimized for the BN128 curve, ensuring all computations (proof generation and verification) aligned with this elliptic curve.

  2. Mismatch in Merkle Roots
    Challenge: The Merkle root calculated off-chain did not match the root generated on-chain in Solidity. This mismatch prevented successful proof verification.
    Root Cause: Discrepancies in public input encoding between the off-chain and on-chain environments.
    Solution:
    Endianness Adjustment: Ensured that all public inputs were properly converted to little-endian format on the EVM side, as zkVerify requires big-endian inputs while Solidity processes inputs in little-endian.

  3. Misalignment of Proof Generation and Verification
    Challenge: The proof generated using snarkjs off-chain failed validation when submitted to zkVerify due to input misalignment.
    Solution:
    Debugged the proof submission by logging all public signals, root values, and nullifiers, verifying their consistency across all stages of the process.
    Validated the trusted setup files (.zkey and .wasm) to ensure they matched the circuit and verification key (vkHash) deployed to zkVerify.
    Confirmed that the public.json file used for proof generation was hardcoded correctly in the Solidity contract.

Tracks Applied (2)

zkVerify Main Prize Pool Track

This project aligns seamlessly with the objectives of the zkVerify Main Prize Pool Track by leveraging zkVerify’s infras...Read More

Privacy Application Builders

This project fits seamlessly into the Horizen Labs: Privacy Application Builders track by addressing key aspects of thei...Read More

Horizen Labs

Discussion

Builders also viewed

See more projects on Devfolio