Commit-Reveal Voting

Commit-Reveal Voting is a cryptographic protocol that separates the voting process into two distinct phases to preserve voter privacy and prevent strategic manipulation. In the commit phase, voters submit a cryptographic hash—a one-way, fixed-length digest—of their secret vote combined with a random salt. This commitment is recorded on-chain, locking in their choice without revealing it. Later, in the reveal phase, voters must publicly submit their original vote and salt. The system verifies the reveal by hashing the submitted data and checking it matches the earlier commitment. This mechanism ensures votes cannot be changed after commitment and prevents voters from being influenced by seeing others' choices mid-vote.

The primary technical components enabling this scheme are the cryptographic hash function (like SHA-256 or Keccak) and the random salt. The hash function's properties—preimage resistance and collision resistance—guarantee that the commitment reveals nothing about the vote, while the unique salt prevents brute-force attacks where an attacker could guess simple votes. The random salt is crucial; without it, an attacker could hash all possible vote options (e.g., 'Yes' or 'No') to discover a voter's commitment. This design makes the scheme particularly resistant to sniping or last-minute manipulation, where voters might change their votes based on a leading outcome.

A canonical example of commit-reveal voting is its use in decentralized autonomous organization (DAO) governance proposals. For instance, a DAO might use it to vote on a contentious treasury allocation. During a 3-day commit period, members submit hashes. After this period closes, a 2-day reveal period begins where voters disclose their votes. Only votes that are properly revealed are counted. This prevents a well-funded actor from watching the live tally and deploying capital at the last second to swing the vote, a tactic known as vote buying or flash loan voting. The process ensures the final outcome reflects the genuine, pre-committed preferences of the participants.

While powerful, the commit-reveal scheme introduces specific trade-offs and challenges. It requires voters to complete two transactions (commit and reveal), doubling gas fees and complexity, which can reduce participation. There is also a vote forfeiture risk; if a voter commits but fails to reveal, their vote and any associated stake are lost, potentially skewing results. Furthermore, the scheme protects vote privacy only during the voting window; all choices are public after the reveal phase. For long-term privacy, more complex systems like zero-knowledge proofs or homomorphic encryption may be required. Despite these drawbacks, commit-reveal remains a foundational, transparent method for achieving fair voting in transparent environments like blockchains.

The commit-reveal pattern extends beyond simple yes/no voting into various blockchain applications. It is the underlying mechanism for fair random number generation (RNG) in many smart contracts, where participants commit to a number later revealed to compute a collective random seed. It's also used in sealed-bid auctions on-chain, where bidders commit to their bid amount and only reveal it after the bidding period closes, preventing front-running. These use cases leverage the same core property: binding to a secret value early in a process without disclosing it, thereby enforcing fairness and mitigating information leakage that could be exploited for profit.

Commit-reveal voting is a two-phase cryptographic protocol designed to ensure vote privacy and prevent strategic manipulation, such as vote copying or last-minute swings. In the commit phase, voters submit a cryptographic hash of their encrypted vote, along with a secret salt, to the blockchain. This hash acts as a sealed, unchangeable commitment. Once the commitment period ends, the protocol enters the reveal phase, where voters must publicly submit their original vote and the salt. The system verifies the reveal by hashing the submitted data and checking it matches the earlier commitment. Votes with invalid or missing reveals are discarded.

The core cryptographic property enabling this scheme is the preimage resistance of hash functions like SHA-256. It is computationally infeasible to derive the original vote from the hash commitment, preserving secrecy during the commit window. The random salt is crucial; without it, a voter's choice could be guessed if the set of possible votes is small (e.g., a simple 'yes' or 'no'), as an attacker could hash all possibilities to find a match. The salt ensures each commitment is unique, even for identical votes, preventing enumeration attacks.

This mechanism is vital in on-chain governance for projects like DAOs, where it prevents voters from being influenced by seeing others' choices before submitting their own. It also underpins fair random number generation (RNG) in smart contracts, where participants commit to numbers later revealed to compute a result. A key limitation is voter participation complexity, as users must safely store their salt and return for the reveal phase; votes not revealed are lost. Furthermore, while it hides individual votes during commitment, the final reveal makes all choices permanently public on the ledger for verification.

In practice, a commit-reveal vote smart contract manages the phases through timers and state variables. It stores commitments in a mapping, and during the reveal phase, it executes a function like revealVote(choice, salt) that calls keccak256(abi.encodePacked(choice, salt)) to validate against the stored hash. Major blockchain platforms, including Ethereum, utilize variants of this scheme for applications like the ENS auction process and various DAO governance modules. It represents a fundamental privacy-preserving primitive, trading some user convenience for enhanced strategic resistance in decentralized systems.

The commit-reveal process is a two-phase cryptographic protocol used in blockchain voting to separate the act of casting a ballot from the act of making that ballot's choice public. In the first commit phase, a voter generates a cryptographic hash of their vote—combined with a secret random value called a salt—and submits only this hash to the blockchain. This commit transaction locks in the voter's intent without revealing their actual choice, as the hash function is a one-way operation. The commitment is recorded on-chain, timestamped, and immutable.

Following a predetermined time window for commitments, the process enters the reveal phase. During this second stage, voters must submit a second transaction containing their original vote and the exact salt they used. The network verifies this reveal by hashing the submitted data; if it matches the previously stored commitment hash, the vote is counted. Votes that are not properly revealed within the timeframe are invalidated. This separation prevents front-running and vote copying, as late voters cannot simply observe and mimic leading votes to influence the outcome.

The security of the scheme hinges on the properties of the cryptographic hash and the secrecy of the salt. The salt prevents others from guessing a voter's choice by brute-forcing the hash of known options (e.g., "Yes" or "No"). Without the unique salt, identical votes would produce identical hashes, breaking anonymity. This mechanism is crucial for on-chain governance in systems like DAO treasuries or protocol upgrades, where transparent vote buying or last-minute strategic swings could undermine the integrity of the decision-making process.

A practical example is a DAO voting on a funding proposal. Alice wants to vote "Yes." She randomly generates a salt, s123, and computes hash("Yes" + "s123"), submitting the resulting hash as her commit. Later, in the reveal phase, she submits the plaintext data ("Yes", "s123"). The smart contract hashes this data; upon a match, her "Yes" vote is tallied. An observer who saw only the commit hash cannot determine her vote, and a malicious actor cannot change their vote after seeing hers, as their commitment hash would not match.