Confidential Voting
Last updated
Last updated
Confidential voting is a privacy-preserving voting system that can provide privacy on voting choices and other side information. In the world of decentralized governance, tools like Snapshot and Tally have become essential for managing proposals and voting. Snapshot offers off-chain voting with results stored on IPFS or Arweave, while Tally provides a fully on-chain solution utilizing ERC20 and ERC721 token contracts. By combining the strengths of both systems and incorporating the zkFHE technique, we can design a secure, decentralized voting system that offers both confidentiality and integrity.
Snapshot allows anyone to create a voting proposal by confirming the block height corresponding to the proposal. Users' voting power is calculated based on their token balance at that block height. They can vote (for, against, abstain) and the results are calculated once the voting period ends. Proposal and voting information can be stored on IPFS (or Arweave). Additionally, users can delegate or withdraw their voting power to/from other addresses within the domain.
Tally’s DAO voting system relies on token and governor contracts. The token contract (ERC20 or ERC721) is a prerequisite for the governor contract, which manages proposals and voting. Users submit proposals by sending transactions to the governor contract and vote on active proposals through on-chain transactions. Tally ensures all voting information is recorded on-chain, offering transparency and security. Similar to Snapshot, Tally allows delegation of voting power.
By leveraging zkFHE computation and integrating the features of Snapshot or Tally, we can create a confidential voting dApp CV
that combines on-chain or off-chain governance with enhanced security and confidentiality.
The dApp shall integrate with the zkFHE network with proper approaches initially. The key steps are creating a proposal, voting and tallying.
Proposal Creation: Any user can create a proposal through CV
, and publish it on-chain (Tally) or off-chain (Snapshot). The metadata of the proposal shall specify the voting strategy. The dApp CV
communicates with BAVO's contracts and requires a subset of zkFHE nodes to create a shared public key PK for that proposal.
User Voting: A user chooses a voting option m1
a the created proposal. Meanwhile, he uses PK to encrypt with the option m1
and sends the encrypted vote Enc(m1, PK)
.
Tally and Publish On receiving enough encrypted votes, the dApp shall tally up on that proposal. This can be achieved by performing a homomorphic computation on all the votes, i.e.,
Note the vote m1
can be a simple boolean value for a "yes" or "no" option, or it can be a weighted vote that can be linearly computed as m1=a1*b1
, where a1
is the token quantities and b1
is the vote option. Note we cannot hide the token quantities as the snapshot block height is public, and token balances can be queried from block data, exposing the voting power.
The ciphertext C
is an encryption of the voting result, which can be threshold decrypted to recover the plain result R
.
Integration with Existing Frameworks The proposed solution can integrate with both Tally and Snapshot, enabling both on-chain and off-chain governance with confidential voting. Delegation of voting power can also be enabled through standard application logic within the solution.
Enhanced Security and Decentralization: Compared to a traditional ZKP-based solution, the above approach eliminates the need for a central tallying authority, reducing centralization risks.