Implement anti-pre-revelation mechanism for on-chain version

[0xferit]

Context

The current centralized server naturally prevents pre-revelation: commit hashes are held privately and never broadcast to other players, so no player can prove their commitment to others.

When the game moves on-chain (Ethereum), commit hashes become public. A player could share their (choice, salt) and anyone could verify it against the on-chain hash, making pre-revelation provable and enabling explicit coordination that bypasses focal-point discovery.

Goal

Implement an anti-pre-revelation mechanism so that revealing your commitment to others before the reveal phase is economically unprofitable, preserving the independent-convergence property of the Schelling game.

References

• On Anti-Pre-Revelation Games (Vitalik Buterin, 2015): Proposes a parallel betting game where anyone who receives a pre-revelation can bet against the revealer, making pre-revelation a liability.
• The P + Epsilon Attack (Vitalik Buterin, 2015): Describes how credible conditional bribes can make voting for the attacker's preferred outcome a dominant strategy at zero cost.

Approach (TBD)

The leading candidate is the parallel betting mechanism from the anti-pre-revelation post: if Alice pre-reveals to Bob, Bob can register a bet predicting Alice's choice. If Alice follows through, she loses coins to Bob. This converts the public good of detecting collusion into a private good of profitable betrayal.

Alternatives to evaluate:

• Timelock/threshold encryption (external decryption service like drand)
• ZK-based commit schemes
• Hybrid approaches

Current state

The centralized server provides anti-pre-revelation as an implementation artifact (hashes are private). This issue tracks making it a designed, cryptoeconomic property for the on-chain version.

[0xferit]

Deep Dive: Anti-Pre-Revelation Mechanism Options

This comment expands on the three alternative approaches listed in the issue, adds two more candidates, analyzes tradeoffs, and proposes a concrete phased implementation path.

---

Why pre-revelation is uniquely harmful here

In a standard commit-reveal vote the goal is a correct outcome; a defector who pre-reveals just loses a bribe opportunity. In the Schelling game the goal is independent convergence — pre-revelation doesn't merely distort an outcome, it destroys the measurement entirely. Any mechanism must therefore make pre-revelation unprofitable even when every player in a round wants to collude, not just a minority.

---

Option A — Parallel Betting (Vitalik 2015, leading candidate)

When Alice commits H(choice, salt) on-chain, a separate BettingPool contract allows anyone to post a prediction (alice_address, predicted_choice) backed by a stake. After reveal:

• If Alice's revealed choice matches the prediction → predictor wins Alice's bet deposit (or a portion of her round stake).
• If Alice's revealed choice does not match → Alice keeps her deposit and the predictor is slashed.

The key property: Bob, having received Alice's pre-revelation, can bet against her at any time before the reveal deadline. Alice now faces the choice of either (a) revealing the committed value and paying Bob, or (b) not revealing at all (forfeiting her own stake). Neither is better than simply not pre-revealing in the first place.

Sizing the bet cap matters. The bet payout must be ≥ the expected coordination gain from pre-revelation, otherwise colluding players can absorb the loss. If the round prize pool is P, the minimum profitable bet for a predictor should satisfy: bet_payout ≥ P / n where n is the number of players, so that a single informant can profitably destroy any collusion ring.

Griefing vector. A sophisticated attacker could spam predictions against every player (paying gas) to create pressure even without a real pre-revelation. Mitigation: require a minimum stake per prediction, and return the stake to Alice if the prediction was wrong (pure loss for the griefer). Alternatively, limit predictions to one per (predictor, committer) pair per round.

---

Option B — Timelock / Threshold Encryption (drand tlock)

The commit is encrypted to a future drand round rather than being a plain hash. The plaintext is provably inaccessible to everyone — including the player — until the drand network releases the round key. Pre-revelation of (choice, salt) is impossible because the player themselves cannot decrypt their own commitment before reveal time.

How it works with drand tlock:

1. Player encrypts choice || salt to drand round R_reveal using BLS threshold encryption.
2. The ciphertext (not a hash) is posted on-chain.
3. At round R_reveal the drand network publishes the threshold signature; anyone can decrypt and verify.

Tradeoffs:

• ✅ Pre-revelation is cryptographically impossible, not just economically unprofitable.
• ✅ No extra on-chain contracts or staking mechanics.
• ⚠️ Liveness dependency: if drand halts or is compromised between commit and reveal, the round is stuck. The drand League of Entropy network has a strong uptime record but is an external dependency.
• ⚠️ Players cannot change their mind (no "re-commit" option), because the commitment is locked.
• ⚠️ The on-chain verifier must handle BLS pairing checks, which are gas-heavy (though EIP-2537 BLS precompiles significantly reduce this cost on modern EVM).

---

Option C — ZK-Based Commit Scheme

Instead of posting H(choice, salt), the player posts a ZK proof that they know a valid (choice, salt) pair such that the commitment satisfies some predicate, without revealing either. The reveal phase accepts a ZK proof of consistent opening rather than the raw preimage.

Specific construction (Pedersen + Groth16 / PLONK):

• Commit: post a Pedersen commitment C = choice·G + salt·H on-chain.
• Reveal: submit a SNARK proof π that choice is in the valid range AND C was formed with that choice.
• The on-chain verifier checks π without ever seeing choice until the operator-defined reveal window opens.

Why this helps: Alice can share (choice, salt) with Bob off-chain, but Bob cannot post it on-chain during the commit phase (he has no commitment to attach it to), and during the reveal phase Alice must submit the proof herself (tied to her wallet). The social act of sharing is not prevented, but it gives Bob no on-chain leverage.

Tradeoffs:

• ✅ No external liveness dependency.
• ✅ Elegant: the commitment scheme itself encodes privacy.
• ⚠️ Trusted setup (for Groth16) or larger proof sizes (for PLONK/STARK).
• ⚠️ Client-side proving adds UX friction (seconds of compute in-browser via snarkjs, or requires a proving service).
• ⚠️ Does not prevent social coordination — Alice can still call Bob and say her number verbally. The ZK approach prevents verifiable on-chain proof, but not informal collusion.

---

Option D — Commit-Reveal² (newer, worth evaluating)

A recent construction (arXiv:2504.03936) layers a second commit-reveal on top of the first: the salt itself is committed in a separate prior round, making it infeasible to pre-reveal the choice without also pre-committing the salt, which itself has a binding deadline. This adds a second phase but requires no external services or ZK circuits.

Tradeoff: Doubles the number of on-chain transactions per player per round and adds a third phase (salt-commit → choice-commit → reveal), which may be prohibitive for a fast-paced game.

---

Option E — TEE-Assisted Reveal (honorable mention)

A Trusted Execution Environment (e.g. Intel TDX or AWS Nitro via Marlin/Phala) holds the reveal keys in a confidential enclave and enforces the reveal deadline. Players encrypt their choice to the TEE's public key; the TEE releases the plaintext only after the deadline.

Tradeoff: Trades cryptographic trust for hardware trust. Suitable as a bootstrap phase (cheap, fast, no ZK), but contradicts the trustless ethos of a fully on-chain Schelling game.

---

Recommendation: Phased approach

Phase	Mechanism	Trust assumption	Pre-revelation prevention
v1 (on-chain MVP)	Parallel betting (Option A)	Trustless	Economic (probabilistic)
v2	drand tlock (Option B)	Liveness of League of Entropy	Cryptographic (hard)
v3	ZK commits (Option C)	Trustless	Cryptographic (proof-based)

Start with Option A because it requires only an additional BettingPool.sol alongside the existing commit-reveal contract, with no new cryptographic dependencies. It also has an elegant game-theoretic property: it turns would-be colluders into potential informants, which is directly in the spirit of the Schelling game's incentive design.

Option B (drand) is the cleanest long-term solution and should be prototyped in parallel — the EVM BLS precompiles (EIP-2537) make on-chain verification feasible today.

---

Contract interface sketch (Option A)

interface IAntiPreRevelation {
    /// @notice Register a prediction that `committer` will reveal `predictedChoice`
    /// @dev Caller stakes msg.value; callable only during commit phase
    function predict(address committer, uint256 predictedChoice) external payable;

    /// @notice Settle predictions after reveal; called by the main game contract
    /// @dev If revealed == predicted, predictor wins committer's deposit share
    function settle(address committer, uint256 revealedChoice) external;
}

The main SchellingGame.sol calls settle() in its reveal handler, keeping the two contracts cleanly separated.

---

Open questions

1. Bet sizing: Should the predictable payout be a fixed fraction of the round pool, or dynamic (auction-style, highest bidder wins the right to predict against a given committer)?
2. Multi-round collusion: Does a one-round betting mechanism deter collusion rings that operate over many rounds with delayed compensation? Probably not — worth considering a cross-round reputation slash.
3. MEV: During the reveal phase, a MEV searcher who front-runs a reveal transaction could also submit a prediction in the same block. Is this acceptable (it still punishes the revealer) or does it distort incentives?
4. Interaction with forfeit: If a player forfeits (does not reveal), predictions against them should be refunded, not paid out — otherwise forfeiting becomes a free escape hatch from a correct prediction.