Reveal Phase

Participants must reveal the original data (the preimage) that was used to generate their earlier cryptographic commitment hash. This proves they committed to a specific value without revealing it prematurely. For example, in a blind auction, bidders reveal their actual bid amount.

• Core Action: Submitting the secret that matches the hash.
• Verification: The network hashes the revealed data to check it matches the stored commitment.

The Reveal Phase operates within a strictly defined time window or block height. Participants must submit their reveal transaction before this period expires.

• Purpose: Prevents indefinite delays and ensures protocol finality.
• Consequence: Failure to reveal within the window typically results in the forfeiture of any staked collateral or the loss of voting/participation rights for that round.

Every reveal is validated on-chain by the protocol's smart contract or consensus rules. The contract recomputes the hash of the revealed data and compares it to the stored commitment from the previous phase.

• Trustless Execution: No trusted third party is needed; correctness is enforced by code.
• Gas Costs: Revealing transactions incur gas fees, which is a consideration for protocol design.

Many commit-reveal schemes require participants to post collateral (e.g., ETH, protocol tokens) during the commit phase. This collateral is at risk (slashed) if the participant acts maliciously or fails to reveal.

• Security Mechanism: Deters grinding attacks and spam by making dishonest behavior costly.
• Example: In Optimistic Rollup fraud proofs, a validator must commit and later reveal a fraud proof, with slashing for invalid claims.

By separating commitment from revelation, this scheme prevents others from seeing and copying or manipulating a participant's action before it's finalized.

• Use Case: DAO voting on sensitive proposals, where early visibility could influence other voters.
• Use Case: Random number generation (RNG) where the seed is committed first, then revealed after all bets are placed.

The Reveal Phase is functionally meaningless without the preceding Commit Phase. The two-phase structure is what provides security.

• Data Dependency: Each reveal must reference a specific, valid commitment transaction hash.
• State Transition: The protocol's state (e.g., election result, auction winner, RNG output) is only finalized after all valid reveals are processed and verified.

The Reveal Phase is critical for secure, anonymous voting on DAO proposals. Voters first commit a hash of their vote during a commit period. In the subsequent Reveal Phase, they submit the original vote and salt, allowing the smart contract to verify it matches the earlier commitment. This prevents vote buying and coercion, as final votes are only known after the commitment window closes.

• Example: Aragon and early MolochDAO implementations use this pattern.
• Key Benefit: Ensures vote secrecy until the commitment period ends, preserving the integrity of the decision-making process.

Commit-reveal is a foundational mechanism for generating provably fair random numbers on-chain, essential for NFTs, gaming, and lotteries. Multiple participants each commit a hash of a secret number. After all commitments are locked in, the Reveal Phase begins, where each participant discloses their number. The final random seed is computed from the combination of all revealed values. This prevents any participant from manipulating the outcome after seeing others' inputs.

• Prevents Back-running: No one can change their submitted number after seeing others.
• Use Case: Chainlink VRF and other RNG oracles use a sophisticated version of this principle.

In blockchain-based sealed-bid auctions, the Reveal Phase ensures bid confidentiality and finality. Bidders submit a cryptographic commitment (hash of bid amount + secret) before the deadline. When the Reveal Phase opens, bidders must reveal their actual bid and secret. The smart contract verifies the reveal against the commitment and the highest valid bid wins. This process prevents bidders from adjusting their bids based on others' actions during the bidding period.

• Guarantees Fairness: All bids are hidden until the auction closes.
• Consequence: Bidders who fail to reveal forfeit any locked collateral, ensuring serious participation.

Commit-reveal schemes can mitigate Maximal Extractable Value (MEV) and frontrunning. Users submit a transaction commitment (hash of tx data + fee) to a private mempool. During the Reveal Phase, the actual transaction is broadcast. This creates a time delay between when the intent is known to the network and when it can be executed, reducing the window for predatory bots to frontrun the trade. While not a complete solution, it adds a layer of protection.

• Limitation: Requires protocol-level or mempool-level integration.
• Trade-off: Introduces latency in exchange for improved transaction privacy.

A major practical consideration is handling participants who commit but do not reveal. This can stall processes like RNG or auctions. Systems mitigate this with slashing mechanisms or deposit forfeiture. For example, in a random number scheme, participants may be required to stake ETH when they commit; if they fail to reveal, they lose their stake. This incentivizes timely participation in the Reveal Phase.

• Economic Security: Penalties must be high enough to disincentivize denial-of-service attacks.
• Design Choice: The penalty model is a core part of any commit-reveal system's security.

The Reveal Phase is executed via a smart contract function, typically reveal(). The function logic:

1. Checks that the current block is within the reveal period.
2. Validates that the caller has a pending commitment.
3. Hashes the provided message and salt using keccak256.
4. Verifies the computed hash matches the stored commitment.
5. Processes the revealed data (e.g., tallies a vote, computes a random seed).
6. Deletes the commitment to prevent replay.

• Core Function: require(commitments[msg.sender] == keccak256(abi.encodePacked(message, salt)), "Invalid reveal");
• State Transition: Moves the system from a committed state to a resolved state.

The sequential nature of reveals can expose participants to timing attacks. Malicious actors can monitor the blockchain for early reveals and attempt to front-run or grief later participants by manipulating transaction fees or submitting invalid reveals to disrupt the process. This is mitigated by using cryptographic commitments (like hash functions) that make the initial commit unguessable.

A core security assumption is that committed data will be available for the reveal. A data withholding attack occurs when a participant commits to data but never reveals it, potentially stalling the protocol or causing a loss of funds (e.g., in auctions or lotteries). Solutions include:

• Slashing mechanisms that penalize unrevealed commits.
• Deposits or bonds that are forfeited upon failure to reveal.
• Fallback values that trigger after a timeout.

The security of the entire scheme hinges on the cryptographic binding and hiding properties of the commitment function (e.g., SHA-256).

• Binding: It must be computationally infeasible to find two different inputs (data1, data2) that produce the same commitment hash. A break here allows equivocation.
• Hiding: The commitment must not leak any information about the original data before the reveal. A break here enables pre-computation attacks.

In applications like random number generation (RNG) or leader election, the reveal phase aggregates individual secrets to produce a final, unbiased result. This requires trust minimization:

• No single participant should be able to bias the final output by choosing when or what to reveal.
• The protocol must be verifiably fair, allowing anyone to cryptographically verify that the revealed values correctly correspond to the initial commitments and produce the declared result.

The reveal phase transitions the system from a state of conditional promises to cryptographic finality. Each reveal must be publicly verifiable against its commitment on-chain. Key checks include:

• Validating that hash(revealed_data + salt) == original_commitment.
• Enforcing that reveals occur within a strict, predefined time window.
• Ensuring the logic for processing reveals (e.g., tallying votes, selecting a winner) is deterministic and tamper-proof once all data is public.

Security is enforced through cryptoeconomic design. The protocol must structure incentives so that honest revelation is the dominant strategy in the game-theoretic model. This involves:

• Rewards for successful participation in the reveal phase.
• Penalties (slashing) for non-participation or fraudulent reveals.
• Cost analysis ensuring that the cost of attacking (e.g., bribing, withholding) exceeds the potential profit, making attacks economically irrational.

A cryptographic primitive that allows one party to commit to a chosen value while keeping it hidden, with the ability to later reveal it. It consists of two phases:

• Commit Phase: The sender generates a commitment (a sealed envelope) using the secret value and a random nonce.
• Reveal Phase: The sender discloses the original value and nonce, allowing the receiver to verify it matches the earlier commitment. This ensures binding (the sender cannot change the value) and hiding (the receiver cannot learn the value before the reveal).

A method by which one party (the prover) can prove to another (the verifier) that a statement is true, without revealing any information beyond the validity of the statement itself. ZKPs often use commitment schemes in their protocols.

• Role in Reveal: A prover may commit to a witness value, then use a ZKP to demonstrate they know a valid opening for the commitment that satisfies a circuit, without ever revealing the witness during the proof verification.

A hash-based data structure used to efficiently verify the contents of large datasets. A Merkle root acts as a cryptographic commitment to the entire set of data.

• Reveal Connection: To prove a specific piece of data (e.g., a transaction) is included in the set, one provides a Merkle proof (a path of hashes). The Reveal Phase here involves providing the leaf data and the proof, which can be hashed to recompute and verify the publicly known root.

A function that requires a prescribed amount of sequential computation to evaluate, but whose output can be verified quickly. VDFs are used in consensus and randomness generation.

• Reveal Parallel: The 'reveal' in a VDF-based system is the publication of the function's output after the time delay. The commitment is the initial input or a public parameter. The sequential work ensures the output could not be predicted or manipulated before its reveal time.

A two-phase voting mechanism designed to prevent strategic voting based on early results.

1. Commit Phase: Voters submit a hash of their vote (commitment).
2. Reveal Phase: Voters later submit their actual vote, which is checked against the hash. This ensures votes remain secret until all commitments are collected, preventing vote copying and promoting honest preference expression.

A method of encrypting a message so that it can only be decrypted after a specific point in time, enforced by computational effort (like a VDF) or a blockchain block height.

• The Reveal: The encrypted ciphertext is the commitment. The 'reveal' is the event where either the necessary time has passed and the decryption key is computable, or a condition (e.g., a block number) is met, allowing the message to be decrypted and read.