4.3 The Commit-Reveal Scheme

On a transparent public blockchain, all transaction data is instantly visible to the entire network upon broadcast. If the arbitrator directly submits the voting results (e.gVote: YES),Subsequent arbitrators will be able to see the choices of the early voters. This can lead to serious mirroring attacks or free-riding behavior—arbitrators no longer analyze the evidence independently but blindly follow the choices of early voters, undermining the "independent judgment" assumption required for Schelling point games.

To address this issue, OmniPact implemented a strict Commit-Reveal two-phase voting protocol.

4.3.1 Phase 1: The Commit Phase

At this stage, the arbitrator has made a ruling, but the ruling must be "sealed" and uploaded to the blockchain. We use a one-way hash function to implement this "digital envelope".

1. Local Computation

The arbitrator client generates the following data locally:

  • Vote ():Judgment results (e.g.1 Buyer wins,2 Seller's representative wins).

  • Salt (): A high-entropy random number (e.g., a large 256-bit integer). Salt is crucial to prevent brute-force attacks.

2. Hash Generation

Arbitrator calculates commitment hash $C$:

Ci=Keccak256(ViSiAddressi)C_i = \text{Keccak256}(V_i \parallel S_i \parallel \text{Address}_i)
  • : Data splicing operation.

  • Address Binding: Including the sender's address in the hash calculation prevents other malicious nodes from directly copying (replaying) the hash value to forge votes.

3. On-Chain Submission

Arbitrator call commitVote(bytes32 commitment)。

  • Only hash values ​​are stored on the chain.

  • Privacy: Due to the one-way nature of hash functions, and Not disclosed, and outsiders (including other arbitrators) cannot obtain information from it Reverse deduction

  • Note: Gas fees will be charged at this stage.

4.3.2 Phase 2: The Reveal Phase

commitPeriod Once the agreement concludes (e.g., 24 hours later), it enters the disclosure phase. At this point, all arbitrators must disclose their original data to verify the commitments.

1. Data Exposure

The arbitrator calls revealVote(uint256 vote, uint256 salt).

2. On-Chain Verification

The smart contract re-executes the hash calculation and compares it with the commitment stored in Phase 1:

Solidity

  • Consistency check: If an arbitrator attempts to change a vote during the disclosure phase (e.g., seeing everyone else voted A and wanting to change their vote to A), they will be unable to find a new one Make (Hash collision) The transaction will be rejected.

4.3.3 Security Analysis: Preventing Mirroring

1. Salt Generation

If only Keccak256(Vote) is calculated, the hash can be cracked instantly by brute force due to the extremely small value space of $V$ (typically only 2-3 options).

Introducing a random salt ($S$) greatly expands the input space, making brute force computationally infeasible. The OmniPact SDK automatically generates a strong random salt locally and stores it encrypted on the user's device.

2. Enforced Independence

Because no genuine voting information was leaked before the end of the Commit phase, all arbitrators were forced to independently review the evidence and make their judgments. When the Reveal phase began, everyone revealed their cards simultaneously, at which point it was impossible to change the outcome.

3. Non-Reveal Penalty

If an arbitrator submits a hash during the Commit phase but finds themselves in the minority during the Reveal phase, they might choose not to reveal (abstain from voting) to avoid being penalized.

To curb this behavior, OmniPact stipulates that committing but not revealing is equivalent to abstaining and will incur a slight reputation point deduction. This ensures that arbitrators are incentivized to complete the entire process.


This mechanism is the most classic cryptographic primitive in decentralized voting systems. By explaining in detail the role of Salt and the necessity of Address Binding, it demonstrates the rigor of the protocol's detailed design.

Last updated