暗号プロトコル
Commit (コミット) / Reveal (リビール)
Round (ラウンド) t において、秘密鍵 s_i ∈ {0,1}^128 を持つユーザー i は、回答 b_i ∈ {0,1} を選択し、以下を公開します：
ここで ‖ は連結を表し、round_t は公開された一意の Round 識別子です。
Reveal フェーズでは、ユーザー i が (s_i, b_i) をブロードキャストします。Round Engine (ラウンドエンジン) および任意の第三者検証者は HMAC-SHA256(s_i ‖ round_t, b_i) を計算し、それが以前に公開された c_i と一致することを確認します。一致しない Reveal は拒否されます。Reveal を行わなかったユーザーは Round から排除されますが、その Commit は監査のために Merkle Root (マークルルート) に残ります。
プレーンなハッシュではなく HMAC を使用する理由
プレーンな Commit H(s_i ‖ b_i) は、以下の2つの攻撃に対して脆弱です：
- Rainbow (レインボー) 事前計算。
s_iが短い場合（モバイル UX の制約により、デバイスにバインドされた乱数は最大16バイト）、秘密空間全体にわたるH(s ‖ 0)とH(s ‖ 1)の事前計算テーブルによって、Reveal 前に Commit が解読される可能性があります。 - クロスラウンドリプレイ。 Round バインディングがない場合、Round
tで有効な Commit が、Roundt' ≠ tでの証拠として再利用される可能性があります。
適切なサイズの鍵（ここでは128ビット）と Round バインディング（round_t を鍵付きメッセージに連結）を備えた HMAC は、両方の攻撃を排除します。標準的な仮定の下での HMAC 構造の擬似ランダム性により、s_i がなければ、攻撃者が b_i = 0 と b_i = 1 を区別するアドバンテージは無視できるほど小さくなります。
s_i の生成元
各ユーザーのデバイスは、Round エントリー時にブラウザの crypto.getRandomValues(new Uint8Array(16)) を使用して s_i を生成します。これは Round の期間中のみ WebApp のセッションストレージに保存されます。Reveal 後は破棄されます。ユーザーが入力する秘密は一切関与しません。
Round の途中でセッションをクリアしたユーザーは、その Round を放棄したものとみなされます（鍵を保持していない Commit を Reveal することはできません）。Reputation Score (レピュテーションスコア) はわずかに減少します。
Round Merkle Root (ラウンドマークルルート)
Settle (セトル) フェーズでは、Engine が以下を計算します：
このルートは、24時間ごとに TON へのバッチセトルメントのためにキューに入れられます。TON 上の1回のトランザクションで、約5,760の Round ルート（60秒ごと × 86,400 / 60 / 15 の償却）をコミットできます。
参加者は誰でも Engine から Merkle 証明を取得し、Engine を信頼することなく、オンチェーンルートに対して自分の包含を検証できます。
異議申立期間
24時間の異議申立期間により、オンチェーンでの異議申立が可能です。ユーザーは、オンチェーンルートがオフチェーンの Engine の主張と一致しないことを示す Merkle 証明を提出します。異議申立が成功した場合、その Round は無効化され、再セトルメントされます。オペレーターは Treasury (トレジャリー) に 1,000 $POP のペナルティを支払います。異議申立がなかったルートは確定されます。
Reputation Score (レピュテーションスコア)
r_i ∈ [0, 1] は、ユーザーの正直さに関するベイズ推定値であり、各 Round ごとに更新されます：
ここで λ(o_i^{(t)}) は、観測値（参加、時間通りの Reveal、マイノリティ確率からの逸脱、異常マーカー）に対する尤度関数です。初期値は r_i = 0.5（無情報事前分布）です。
Reputation は非アクティブ状態で δ = 0.01 / 日 の割合で減衰します。Reputation は 0.99（認識論的謙虚さ）を超えることも、0.01（回復を許容）を下回ることもできません。
Reputation Score は、セトルメントにおいて Trust Ladder (トラストラダー) の Multiplier (マルチプライヤー) と乗算されます：
形式的なセキュリティ論証
HMAC-SHA256 が擬似ランダム関数 (PRF) であり、s_i が一様ランダムで攻撃者に未知であるという仮定の下では、効率的な攻撃者は以下を実行できません：
b_i = 0とb_i = 1に対する Commitc_i = HMAC(s_i ‖ round_t, b_i)を無視できないアドバンテージで区別すること。（秘匿性）(s'_i, b'_i)≠(s_i, b_i)でHMAC(s'_i ‖ round_t, b'_i) = c_iとなるものを見つけること。（HMAC の衝突耐性の下での束縛性）- DRAND と TON-VRF の両方のバリデータセットと共謀せずに、次の Round のシードを予測すること。（Oracle & Randomness を参照）
これらは、公平な Commit / Reveal 協調ゲームに必要な3つの特性です。本プロトコルは、追加の暗号学的仮定を必要としません。
監査とオープンソース
Round Engine と検証ロジックは MIT ライセンスでオープンソース化されています。リポジトリは github.com/cashpop-protocol/round-engine にあります。Trail of Bits による完全な監査は、Phase 2（2026年第4四半期）を目標としています。