You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several problems in anonymous voting flow that need to be addressed.
a. In ./server/contracts/OneVote.sol, there are several issues:
There are unused imports that should be removed for cleaner code.
The vote function does not check for any conditions before registering the vote from the user, which could lead to potential issues.
The function name addProposal is incorrect/irrelevant and should be renamed to addCandidate for clarity.
The use of an old semaphore contract is noted. It is recommended to replace this with @semaphore-protocol/contracts/ to ensure the use of the latest and audited contracts.
b. In server/contracts/VotingProcess.sol:
All function names containing proposal are incorrect/irrelevant and need to be updated for consistency and clarity.
c. On the client side, we can implement zk (zero-knowledge) voting using the packages provided by semaphore-protocol. It offers functions for generating proofs and adding user identity to the Merkle tree (ensuring they are eligible to vote). The package handles the heavy lifting, eliminating the need to manually store user identity commitments. Another important reason for using semaphore-protocol is its proven track record, having been tested and used by a community of developers in the zk space.
d. For the voting flow to be truly anonymous, it is not recommended to directly call the vote function from the client using the user's address. This is because, even though the vote call is not directly linked to users wallet address, when the vote function is executed and the number of votes for a certain candidate is incremented, it can be traced back to the caller's wallet and, hence, to the user. To address this, a middle layer like relayers or backend can be used to call the vote function on the smart contract. The user's wallet should only be used while generating proof, which will go from the backend to the smart contract to be verified. This approach ensures the user remains truly anonymous.
The text was updated successfully, but these errors were encountered:
There are several problems in anonymous voting flow that need to be addressed.
a. In
./server/contracts/OneVote.sol
, there are several issues:vote
function does not check for any conditions before registering the vote from the user, which could lead to potential issues.addProposal
is incorrect/irrelevant and should be renamed toaddCandidate
for clarity.@semaphore-protocol/contracts/
to ensure the use of the latest and audited contracts.b. In
server/contracts/VotingProcess.sol
:proposal
are incorrect/irrelevant and need to be updated for consistency and clarity.c. On the client side, we can implement zk (zero-knowledge) voting using the packages provided by
semaphore-protocol
. It offers functions for generating proofs and adding user identity to the Merkle tree (ensuring they are eligible to vote). The package handles the heavy lifting, eliminating the need to manually store user identity commitments. Another important reason for usingsemaphore-protocol
is its proven track record, having been tested and used by a community of developers in the zk space.d. For the voting flow to be truly anonymous, it is not recommended to directly call the
![IMG-20240214-WA0008](https://private-user-images.githubusercontent.com/93488388/314915396-4bc2335c-b723-4449-b4f4-66400c403a2c.jpg?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjYxNTQ5MDIsIm5iZiI6MTcyNjE1NDYwMiwicGF0aCI6Ii85MzQ4ODM4OC8zMTQ5MTUzOTYtNGJjMjMzNWMtYjcyMy00NDQ5LWI0ZjQtNjY0MDBjNDAzYTJjLmpwZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA5MTIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwOTEyVDE1MjMyMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE2MWQwYWM4ZTIzZTdlYzhjMmI4MTk3ZjlmNTg2ZmZjZjFjNzNjZDVmMjdhNWZhNDM0MTViN2EzMTc1NDRlYzUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.0vxdB_FEO2a2q47CMUbGcNmtjiwVPifLsac8AhBnzl4)
vote
function from the client using the user's address. This is because, even though the vote call is not directly linked to users wallet address, when thevote
function is executed and the number of votes for a certain candidate is incremented, it can be traced back to the caller's wallet and, hence, to the user. To address this, a middle layer like relayers or backend can be used to call thevote
function on the smart contract. The user's wallet should only be used while generating proof, which will go from the backend to the smart contract to be verified. This approach ensures the user remains truly anonymous.The text was updated successfully, but these errors were encountered: