Decentralised Voting — Some Design Considerations

Photo by Element5 Digital on Unsplash

The process of Voting is one of the important milestones in human history.
It is a fundamental necessity for a people to decide the course of their destiny, and
the transparency and fairness with which the process must be conducted with is well recognised.

Despite this in 2020, when there is mass adoption of transacting through the internet for everything from shopping to banking,
the possibility of internet voting on an appreciable scale is still yet to be actualised, perhaps due to well founded
fears about hacking and other security risks.

The fate of a nation is too important to be entrusted into the hands of machines, Or so it seems.

Blockchain Technology holds some promise in this area in aiding to hold decentralised, free and fair elections where the citizens
can choose their representatives with the same level of ease with which they could hail a cab.

And as beginners we are exposed to solidity with the possibility of just that.

Below is a sample Ballot contract.

Voters are representated as addresses who can choose either to delegate or cast their own vote to their desired proposal.
And the proposal that secures the maximum votes is deemed the winning proposal.

Seems simple enough, but on closer inspection, it reveals some design considerations and tradeoffs to be made when going through
with such a process.

  • There is no stipulated end date to the voting process.
    This allows voters to case their votes over an indefinitely long period of time.Imagine if someone showed up to the polling booth long after the head of state was sworn in, and they are still able to register
    their vote!
    It is rather expensive to set delays in solidity, which is the same as asking the Ethereum miners to “wait” for
    sometime before they continue processing the contract.
    And since PoW “pays by the minute” unless our contract shells out exorbitant gas fees, miners are better off working on some other transaction.
    You can either be highly decentralised or highly synchronised but not both(at least not while being cheap).
    It is interesting how this might change with the adoption of Proof Of Stake.
    Full disclosure, it is possible set an end to the voting process by something like

But this would have to be checked before entering all the functions, and this approach presents some additional complexity.

  • The Chairperson holds the all important duty of assigning the participants the right to vote and their weights.
    Although it is expensive to do this in terms of gas fees if the voting populace is large and also brings in some amount of
    centralisation, it is necessary in the interest of democracy.
    And the chairperson cannot revoke a vote once it is given.

Note the voters[toVoter].voted condition check in giveRightToVote function.
If this check was absent,
Technically the Chairperson CAN vote as many times as he wants , by calling the giveRightToVote() with his
personal address and then voting!

  • Now for the actual voting.

Gas fees are charged for both computing time and storage space as these resources are used on all the Ethereum nodes on which
the contract is processed.
So it makes sense to store sender first before comparison.

setting sender.voted to true asap avoids possibility of re-entry attacks ,which is a notorious problem.

  • Countdown begins… err or does it?
    The votes for all the proposals have been tallied up and we have a winner.
    Now what?
    No fanfare?
    While the _winningproposal would be reflected on all the nodes in the network, there is no telling when it would end.
    As already mentioned this election isn’t exactly strictly bound by time.
    So much like the prospect of blockchain based voting itself.
    We just have to wait and watch…



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store