# 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.g`Vote: 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 ($$ $V$ $$):Judgment results (e.g.`1` Buyer wins,`2` Seller's representative wins).
* Salt ($$ $S$ $$): 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$：

$$
C\_i = \text{Keccak256}(V\_i \parallel S\_i \parallel \text{Address}\_i)
$$

* $$ $\parallel$ $$: 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.$$ $C\_i$ $$。
* Privacy: Due to the one-way nature of hash functions, and $$ $S\_i$ $$ Not disclosed, and outsiders (including other arbitrators) cannot obtain information from it $$ $C\_i$ $$ Reverse deduction $$ $V\_i$ $$。
* 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

```
function revealVote(uint256 _vote, uint256 _salt) external {
    // 1. Reconstruct the hash
    bytes32 computedHash = keccak256(abi.encodePacked(_vote, _salt, msg.sender));
    
    // 2. Retrieve stored commitment
    bytes32 storedHash = commitments[msg.sender][disputeId];
    
    // 3. Verify
    require(computedHash == storedHash, "Hash mismatch! Vote altered.");
    
    // 4. Record valid vote
    // ... logic to update vote counts ...
}
```

* 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 $$ $S'$ $$ Make $$ $\text{Hash}(A, S') == \text{StoredHash}(B, S)$ $$(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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.omnipact.io/developers/omnipact-technology-white-paper/readme/dan-decentralized-arbitration-network/4.3-the-commit-reveal-scheme.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.