Design a Blockchain E-Voting System

Medium45 min
1 / 30
understanding10 min read

Problem Statement: Secret Ballots on a Public Ledger

Frames e-voting as a privacy-preserving distributed correctness problem, not a generic blockchain CRUD app.

Problem statement

Design a blockchain-based electronic voting system in which every registered voter can cast exactly one ballot, the ballot content remains unlinkable to the voter's identity, the accumulated ledger is publicly tamper-evident, and the final tally is computable and independently re-verifiable by any observer without ever exposing an individual choice. The system must support registration with real-world identity checks, anonymous ballot submission, double-vote prevention, a tally phase with a post-election reveal or partial tally checks, dispute and recount windows, and legal certification of results.

The defining tension is that a blockchain is a public append-only broadcast medium while a democratic ballot is a secret. Publishing every transaction naively publishes every vote. The design therefore separates four planes: an identity plane that knows who may vote but never what they chose; a ballot plane that carries ciphertexts and zero-knowledge proofs but no identities; a consensus plane that orders and finalizes ballots under Byzantine faults; and a tally plane that converts ciphertexts into results through threshold decryption or homomorphic aggregation without any single party seeing an individual plaintext.

Why this is distinctive

A payments blockchain answers "did this state transition follow the rules?" with public balances. An election must answer the same question while keeping the per-voter state hidden forever, resisting coercion (a voter must not be able to prove how they voted, or votes become purchasable), surviving election-day denial-of-service, and producing a result a losing candidate's auditors can recompute from public data alone. Every architectural choice below is driven by one of these four pressures: eligibility without linkage, one-person-one-vote without surveillance, verifiability without receipts, and availability under adversarial load.

Public operating baseline versus design assumptions

Public evidence shows the category is real but contested. Estonia's internet voting channel carried a majority of ballots in its 2023 parliamentary election per the National Electoral Committee's published results; Helios has run open-audit organizational elections with homomorphic tallying since 2008; Snapshot and Compound Governor process millions of signature-based DAO votes off-chain and on-chain respectively; Vocdoni publishes a zkSNARK ballot protocol on a Tendermint-based chain; and the 2020 MIT CSAIL analysis of Voatz documented why mobile blockchain voting pilots failed security review. These are cited public facts, not requirements. For capacity planning this answer explicitly assumes a national-scale election with 50,000,000 registered voters, 30,000,000 cast ballots in a 14-hour window, and a peak hour containing 25% of turnout. Unless tied to a citation, every number is a stated design assumption.

Key Highlights

  • The core tension: a public append-only ledger versus a constitutionally secret ballot.
  • Four planes: identity, ballot, consensus, tally; no plane may see both identity and choice.
  • Coercion resistance requires receipt-freeness: the voter must be unable to prove their choice.
  • Public anchors: Estonia i-voting scale, Helios homomorphic tallying, MIT 2020 Voatz analysis, Vocdoni zkSNARK ballots, Snapshot DAO signatures.
  • Assumed scale: 50M registered, 30M ballots in 14 hours, 25% of turnout in the peak hour.
Lead With the Secrecy Paradox
Open by stating that a naive blockchain vote publishes every choice, so the design problem is cryptographic separation of eligibility from content. This instantly distinguishes you from candidates who draw a token-transfer diagram.
Do Not Draw 'Votes as Tokens'
Modeling a vote as an ERC-20 transfer to a candidate wallet leaks the choice, enables vote buying, and fails secrecy. Tokens carry provenance; ballots must not.

Section Rescue Kit

Buzzwords to use:

Receipt-FreenessUniversal Verifiability

Safe statements:

  • "Let me separate who may vote from what was voted before choosing any technology."
  • "I will treat secrecy and verifiability as simultaneous constraints, not sequential features."
Design a Blockchain E-Voting System - System Design | WinJob | WinJob