> ## 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. # Dice の公平性 > 運営者のシークレットが不要な理由と、公開された入力からの完全な導出方法。 Dice のロールには運営者のシークレットが一切使われません。ベットが実行された時点で取得される Solana のスロットハッシュ、あなたのアカウントアドレス、そして個人のベットカウンターからオンチェーンで導出され、ベットを行ったのと同じトランザクション内で精算されます。運営者が選べるシードは存在せず、後から公開するものもありません。 このページでは、すべての [Dice](/ja/docs/games/dice) のロールの背後にある正確な仕組みを説明します。Dice は [Provably Fair の仕組み](/ja/docs/provably-fair/overview)の中で最も単純なケースです。**運営者のシークレットがまったく存在しません**。ロールは公開された入力から導出され、ベットを行うのと同じトランザクション内でオンチェーンで精算されます。

Dice にコミットのステップがないのはなぜですか？

Crash にコミットされたシークレットが必要なのは、ラウンドの進行中、結果が *確定しているが隠されている* 必要があるからです。ダイスのロールにはそのような段階がありません。結果は、それを引いたのと同じ命令の中で使われます。そのため、シークレットをコミットする代わりに、導出には**運営者の入力を一切使いません**。コミットするものも公開するものもなく、運営者が有利に選べるシードもありません。 エントロピーは Solana ネットワーク自体から得られ、あなたのベットを識別する値と組み合わされます。 * **`slothash`**：ベットのトランザクションが実行された時点での、Solana の `SlotHashes` sysvar の最新エントリ。これはネットワークが生成するエントロピーで、トランザクションの作成時点では分かりません（送信者は、トランザクションがどのスロットに取り込まれるかを正確に知ることができません）。 * **`user`**：オンチェーンのユーザーアカウント（プログラムがあなたのウォレットから導出するアカウント）の32バイトのアドレス。これにより、ロールはプレイヤー間で独立します。同じスロットに取り込まれた2つのベットでも、異なるロールになります。 * **`nonce`**：オンチェーンに保存され、プレイするたびに増加する個人のベットカウンター。これにより、同じスロット内であっても自分の連続したベットが互いに独立し、二重送信の防止も兼ねています。

Dice のロールの正確な式は？

```text theme={null} 入力 slothash 32バイト ベットのトランザクション実行時の最新の Solana スロットハッシュ user 32バイト オンチェーンのユーザーアカウントのアドレス nonce 8バイト ベットカウンター（リトルエンディアン） 導出 hash = sha256( "dice" ‖ slothash ‖ user ‖ nonce ) // "dice" = ASCII 4バイト 0x64 0x69 0x63 0x65 roll = u128_be( hash[0..16] ) mod 10000 // 先頭16バイト、ビッグエンディアンの符号なし128ビット整数 結果 roll は 0..9999 の整数（小数点以下2桁で 0.00–99.99 に対応） ``` 再計算の際に重要な詳細： * ハッシュの入力は、次の順序どおりに連結したものです。ASCII タグ `"dice"`、スロットハッシュ、ユーザーアカウントのアドレス、そして **8バイトのリトルエンディアン**でエンコードしたナンス。 * サンプルは SHA-256 出力の**先頭16バイト**を**ビッグエンディアン**の符号なし128ビット整数として読み取り、10,000 で剰余を取ったものです。 * 128ビットのサンプルを 10,000 で剰余を取ることによる理論上の偏りは 2⁻¹¹⁴ 未満で、ハウスエッジより何十桁も小さいため、補正せずに記載するにとどめています。 ## 勝利条件と配当 ```text theme={null} アンダー : roll < target のとき勝利 勝率 = 10000 通り中 target 通り オーバー : roll > target のとき勝利 勝率 = 10000 通り中 9999 − target 通り multiplier_bps = floor( (10000 − edge_bps) × 10000 / win_chance_bps ) ``` 選択する勝率は 2% から 98% の範囲でなければなりません。現在のエッジ 1.5%（`edge_bps = 150`）では次のとおりです。 | ベット | 勝率 | 倍率 | | - | - | - | | アンダー 5000 | 50% | 1.97x | | アンダー 200 | 2% | 49.25x | | アンダー 9800 | 98% | 1.0051x | 期待リターンはどの目標値でも同じです。`勝率 × 倍率 ≈ 賭け金の 98.5%`（切り捨てにより、最大1ベーシスポイント分ハウスに有利になります）。現在のエッジと上限は[手数料と上限](/ja/docs/fees-and-limits)に記載しています。 ## 保証されていること、されていないこと **プログラムによって強制されること：** * ロールの導出**と**精算は、プログラムが自ら読み取る入力を使って、1つのオンチェーン命令の中で行われます。バックエンドがロールを提供することはなく、偽って報告することもできません。 * 運営者は導出に**一切入力を与えません**。有利な結果が出るまで試行を繰り返せるサーバーシードは存在しません。 * ナンスは正確に一致しなければならないため、同じベットが誤って（または悪意によって）2回プレイされることはありません。 * すべてのプレイで導出の入力と結果がすべて公開されるため、過去のどのロールでも誰でも再計算できます。 **正直な注意点：送信タイミング。** Dice のベットはガス代不要です。MCC のバックエンドがあなたに代わってトランザクションに署名し送信するため、*いつ* 送信するかは運営者が制御します。スロット `N−1` のハッシュはスロット `N` の開始時に公開されるため、非常に低遅延な運営者であれば、ベットが現在のスロットに取り込まれた *場合* のロールを予測し、送信を遅らせて引き直すことが理論上可能です。この仕組みは、それが存在しないふりをするのではなく、この点を認めています（これをなくすには VRF オラクルが必要ですが、ベットごとのコストが少額ベットにおけるハウスの期待値を上回ってしまいます）。これを制約しているのは次の点です。 * 取り込みは完全には制御できません。トランザクションが取り込まれる正確なスロットを決めるのは送信者ではなくネットワークです。 * すべての入力が公開されるため、送信遅延のパターンや、全体の勝率と表示された確率とのずれは、公開データから**誰でも測定できます**。組織的な不正を隠し続けることはできません。

Dice のロールを検証するには？

すべてのプレイで、ベット自身のトランザクション内に `DiceBetSettled` イベントが発行されます。このイベントには、`slothash`、`user`、`nonce`、`target_bps`、`direction`、`win_chance_bps`、`roll`、`multiplier_bps`、`is_win` に加え、精算の完全な内訳など、必要な情報がすべて含まれています。検証方法： 1. Solana エクスプローラーでベットのトランザクションを開き、イベントのフィールドを読み取ります（アプリの Dice 画面ではセッションの公平性データの入力値が表示され、ベット履歴からトランザクションにリンクしています）。 2. `sha256("dice" ‖ slothash ‖ user ‖ nonce)` を再計算し、先頭16バイトをビッグエンディアンで読んで 10,000 で剰余を取り、イベントの `roll` と比較します。 3. 勝敗の判定（アンダーは `roll < target`、オーバーは `roll > target`）と倍率を、上記の式と照合します。 エクスプローラーからイベントデータを読み取る一般的なヒントは、[ラウンドを検証する](/ja/docs/provably-fair/verify-a-round)を参照してください。 ゲーム自体の遊び方は、[Dice ゲームガイド](/ja/docs/games/dice)を参照してください。