> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mycryptocasino.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Provably Fairの概要
> コミット・リビール方式をわかりやすく解説し、チェーンのエントロピーが加えるもの、自分で確認できることを説明します。
My Crypto Casinoのすべてのゲーム結果は、オンチェーンプログラムが実行する**Solanaのチェーンエントロピーと組み合わせたコミット・リビール方式**によって生成されます。これはプレイヤーにとって2つのことを意味します。
1. **結果を後から変更することはできません。** 運営者は、自分が提供する値（秘密の値）の暗号学的フィンガープリントをオンチェーンで公開することで、プレイの*前に*その値を固定します。その後、公開された秘密の値がフィンガープリントと完全に一致しない限り、プログラムは精算を拒否します。
2. **すべてを自分で確認できます。** 入力値と正確な式はすべて公開されています。どのラウンドやベットの後でも、オンチェーンデータから結果を再計算し、ゲームが支払った内容と照合できます。
このページでは、この方式をわかりやすく説明します。正確な式は各ゲームのページに、実際のラウンドを1ステップずつ確認する手順は[ラウンドを検証する](/ja/docs/provably-fair/verify-a-round)に記載しています。
Provably Fairは何で構成されていますか？
**コミットされた秘密の値。** プレイ中に結果を隠しておく必要があるゲーム（Crash、Mines）では、バックエンドがランダムな32バイトの秘密の値を生成し、プレイ開始前にそのSHA-256ハッシュ（*コミットメント*）をオンチェーンで公開します。ハッシュは封をした封筒のようなものです。秘密の値について何も明かしませんが、一度公開されると、それに一致するのはまったく同じ秘密の値だけです。最後に秘密の値が公開されると、プログラム自身がそれをハッシュ化し、コミットメントと一致しなければトランザクションを拒否します。
**Solanaのチェーンエントロピー。** 結果が秘密の値だけで決まることはありません。**スロットハッシュ**も混ぜ合わされます。これは直近のSolanaスロットのハッシュで、決められたタイミングでプログラムがSolanaの`SlotHashes` sysvarから読み取ります。この値はカジノではなくSolanaネットワークが生成するもので、コミットメントの時点ではまだ存在しません。
**公開された決定論的な式。** 結果は、これらの入力値に対する固定された数学的関数です。同じ関数がオンチェーンプログラム内で実行され（バックエンドが結果を偽って報告することはできません。計算するのはプログラムです）、これらのページでも公開されているため、自分で実行できます。
ラウンドはどのような流れで進みますか？
```mermaid theme={null}
sequenceDiagram
participant MCC as MCCバックエンド（運営者）
participant SOL as Solanaプログラム
participant You as プレイヤー
Note over MCC,SOL: 1. コミット
MCC->>SOL: コミットメント = sha256(秘密の値) を公開
Note over You,SOL: 2. プレイ
You->>SOL: ベットがオンチェーンで行われる
Note over SOL: 3. チェーンエントロピー
SOL->>SOL: 最新のSolanaスロットハッシュを取得
Note over MCC,SOL: 4. 公開
MCC->>SOL: 秘密の値を提出
SOL->>SOL: sha256(秘密の値) がコミットメントと一致するか検証
SOL->>SOL: 公開された式で結果を計算
Note over You: 5. 検証（後からいつでも）
You->>SOL: コミットメント、スロットハッシュ、秘密の値をチェーンから読み取る
You->>You: 結果を再計算して照合
```
Diceはこの流れを1つのトランザクションにまとめています。プレイ中に守るべき隠れた状態がないため、運営者の秘密の値はそもそも存在しません。出目はスロットハッシュ、アカウント、ベットカウンターから導出され、それを引いたのと同じ命令の中で精算されます。
## 各ゲームが何をいつコミットするか
| ゲーム | 運営者の秘密の値 | チェーンエントロピー | 結果が確定するタイミング | オンチェーンで強制される内容 |
| - | - | - | - | - |
| [Crash](/ja/docs/provably-fair/crash) | 32バイトの秘密の値。**ベット受付開始前に**コミット | ラウンド開始時に取得されるスロットハッシュ | ラウンド開始時 | コミットメントの照合 + 公開時にプログラムがクラッシュポイントを計算 |
| [Dice](/ja/docs/provably-fair/dice) | なし | ベットのトランザクションが処理された時点のスロットハッシュ | ベットのトランザクションが取り込まれた時点 | プログラムが1つの命令で出目を導出し精算 |
| [Mines](/ja/docs/provably-fair/mines) | 32バイトのシード。**ゲームを開始するトランザクション内で**コミット | 同じ開始トランザクション内で取得されるスロットハッシュ | ゲーム開始時（最初のタイルを選ぶ前） | シードの照合 + 精算時にプログラムが盤面全体を再導出 |
## 保証されること、前提としていること
ここではマーケティングよりも誠実さが大切なので、正確に説明します。この方式は**公開されたチェーンエントロピーを用いたコミット・リビール方式であり、VRFではありません**（VRF：検証可能なランダム関数）。以下は、*コードによって強制される*部分と、*運営者が正しく振る舞うことを前提とする*部分の正確な境界線です。
### オンチェーンプログラムによって強制されること
* **コミット後に結果をすり替えることはできません。** プログラムは公開された秘密の値をハッシュ化し、公開済みのコミットメントと一致しない精算をすべて拒否します。運営者がラウンドの展開を見てから別の秘密の値を選ぶことはできません。
* **運営者が生成しないエントロピー。** スロットハッシュはSolanaネットワークから得られます。コミットメントを公開する時点では未知であり、カジノが生成するものでもありません。
* **結果はオンチェーンで計算されます。** クラッシュポイント、Diceの出目、Minesの盤面は、プログラム自身が計算（または再導出して照合）します。式が生み出さない結果をバックエンドが報告することはできません。
* **完全な公開監査が可能です。** すべてのラウンドとベットは、導出に必要なすべての入力値と結果を含むオンチェーンイベントを発行します。当事者のプレイヤーに限らず誰でも、過去のすべての結果を再計算できます。
### 前提としていること：正直な注意点
* **タイミングによる影響。** 運営者のバックエンドは特定のトランザクションを*いつ*送信するかを選べるため、*どの*スロットハッシュが取得されるかに部分的に影響を与えられます。各ゲームのページで、そのゲームにおいてこれで何ができ、何ができないかを明確に説明しています。
* **キャンセルは可能ですが、返金のみです。** 運営者はCrashのラウンドやMinesのゲームを無効にできます。無効化すると必ずすべての賭け金が全額返金され（プログラムにはキャンセルを通じて没収する手段がありません）、すべての無効化は公開記録されるため、キャンセルの頻度は誰でも監査できます。キャンセルが頻発していれば、それは不正な運営者の兆候としてオンチェーンで目に見える形になります。
* **Minesの盤面はプレイ中、運営者が把握しています。** これは構造上避けられません。タイルをめくった結果はオフチェーンで即座に返され、それを返す側は盤面を知っている必要があります。コミットメントは、盤面が最初のタイルを選ぶ前に確定し、その後書き換えられないことを保証します。その具体的な強制方法は[Minesの公平性](/ja/docs/provably-fair/mines)をご覧ください。
### なぜこうしたトレードオフを受け入れるのか
これらは手抜きではなく、即座にシームレスなゲームプレイを実現するための代償です。各ゲームは、このスペクトラムの中でそれぞれ必要な位置にあります。
* **Mines**：タイルをめくった結果をミリ秒単位で返すには、構造上、盤面をすでに知っている当事者が必要です。代替案（クリックごとにオンチェーントランザクションを送る、あるいはタイルをめくるたびにオラクルとやり取りする）では、タイル1枚ごとに手数料と待ち時間が発生します。即座に遊べて、しかもオンチェーンで精算されるMinesには、盤面を知る運営者が欠かせません。コミットメントの仕組みは、その知識でできることを封じ込めるために存在します。
* **Crash**：全員で共有するライブラウンドには、全プレイヤーのために同時に進行させる誰かが必要です。これは構造上の必然というより実用上の選択であり、そのためプログラムにはオラクルベースの乱数（VRF）への移行経路があらかじめ組み込まれています。これは、経済性が許す範囲でタイミングに関する注意点を取り除く将来のフェーズです。
* **Dice**：スペクトラムの反対側です。プレイ中に隠すものが何もないため、運営者の秘密の値はそもそも存在しません。運営者への信頼を取り除いてもコストがかからない場面では、設計上それを取り除いています。
まとめると、ゲームを運営するのは運営者ですが、チェーンによって不正は**不可能**（コミット後のあらゆる操作）になるか、**公に検知可能**（タイミングのパターン、キャンセルの頻度、勝率の統計）になります。
**結果の公平性と資金の保管の違い**
このセクションは*結果*がどのように生成されるかについての説明です。入金、残高、出金がオンチェーンでどのように保管されるかは別のテーマです。[オンチェーンアーキテクチャ](/ja/docs/security/on-chain-architecture)をご覧ください。
## 自分で検証する
* アプリでは、終了したすべてのCrashラウンドの詳細に公平性データ（公開された秘密の値、ブロックハッシュ、オンチェーントランザクションへのリンク）が表示され、ワンクリックの公平性検証ツールも用意されています。
* DiceとMinesは、導出に使うすべての入力値を、そのベット自身のトランザクションの精算イベントで公開しています。
[ラウンドを検証する](/ja/docs/provably-fair/verify-a-round)では、アプリ内のデータから数行のコードで結果を再計算するまで、手順全体を順を追って説明しています。