Is a Hash Function really useful in a Smart Contract Election?

by antoniopgs   Last Updated June 29, 2020 22:28 PM

Noob here. Was reading this: https://karl.tech/learning-solidity-part-2-voting/

From my basic understanding, a hash function:

  • Receives an input (like x) and spits some result (like y)

  • y is calculated upon the contents of x (so the same x will always hash to the same y)

  • It's non reversible (if you have y, you cannot get x)

Sounds good, but think about the following scenario.

There's an election on an Ethereum Smart Contract with 3 Candidates:

  1. C1

  2. C2

  3. C3

Same logic:

  • Voter can't know who other Voters voted for. Results must only be revealed after the election is over.

  • To vote, each voter must distribute their hash.

  • Once all votes are submitted/election period is over, all voters distribute their actual vote.

  • Then you can verify that the Distributed Vote hashes to the previously Distributed Hash, and the vote can be counted. Sounds good.

But in a Smart Contract Election scenario:

  • All voters know the name/id/label of the 3 candidates.

  • All voters have access to the Smart Contract's code and can see which hash function was used.

Couldn't the voters just:

  1. Run the hash function for each candidate name/id/label by themselves

  2. Write down the resulting hash for each candidate (it would be the same for each candidate every time, right?)

  3. Go see which hashes are distributed in the Blockchain and reverse engineer who each person voted for?

I don't really know that much, so this might be a stupid question.



Answers 1


I think you missed this part:

In this implementation, a vote for choice1 will take the form: 1-my_secret_password and a vote for choice2 will take the form: 2-my_other_secret_password

Notice that the 1 and 2 are the actual votes. The passwords are included to make sure votes remain secret until the reveal period. Each vote is required to use a unique password. If two votes were to use the same password, then the vote commits will be the same. If the vote commits are the same, then only one vote will be counted!

This is exactly to prevent what you are describing. You basically create a random number locally and this will be included in the hash computation. No one else knows this number, so no one can reverse engineer it.

Markus - soliditydeveloper.com
Markus - soliditydeveloper.com
June 29, 2020 22:17 PM

Related Questions


How is the keccak256(a, b) function implemented?

Updated September 11, 2018 08:28 AM

What is a block hash?

Updated December 13, 2017 04:28 AM

Off-chain authorization system

Updated August 17, 2019 02:28 AM

Solidity: extract data from signed message?

Updated August 18, 2019 03:28 AM