Dice の公平性

​

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

• slothash：ベットのトランザクションが実行された時点での、Solana の SlotHashes sysvar の最新エントリ。これはネットワークが生成するエントロピーで、トランザクションの作成時点では分かりません（送信者は、トランザクションがどのスロットに取り込まれるかを正確に知ることができません）。
• user：オンチェーンのユーザーアカウント（プログラムがあなたのウォレットから導出するアカウント）の32バイトのアドレス。これにより、ロールはプレイヤー間で独立します。同じスロットに取り込まれた2つのベットでも、異なるロールになります。
• nonce：オンチェーンに保存され、プレイするたびに増加する個人のベットカウンター。これにより、同じスロット内であっても自分の連続したベットが互いに独立し、二重送信の防止も兼ねています。

​

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

入力
  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⁻¹¹⁴ 未満で、ハウスエッジより何十桁も小さいため、補正せずに記載するにとどめています。

​

勝利条件と配当

アンダー : roll < target のとき勝利      勝率 = 10000 通り中 target 通り
オーバー : roll > target のとき勝利      勝率 = 10000 通り中 9999 − target 通り

multiplier_bps = floor( (10000 − edge_bps) × 10000 / win_chance_bps )

​

保証されていること、されていないこと

• ロールの導出と精算は、プログラムが自ら読み取る入力を使って、1つのオンチェーン命令の中で行われます。バックエンドがロールを提供することはなく、偽って報告することもできません。
• 運営者は導出に一切入力を与えません。有利な結果が出るまで試行を繰り返せるサーバーシードは存在しません。
• ナンスは正確に一致しなければならないため、同じベットが誤って（または悪意によって）2回プレイされることはありません。
• すべてのプレイで導出の入力と結果がすべて公開されるため、過去のどのロールでも誰でも再計算できます。

• 取り込みは完全には制御できません。トランザクションが取り込まれる正確なスロットを決めるのは送信者ではなくネットワークです。
• すべての入力が公開されるため、送信遅延のパターンや、全体の勝率と表示された確率とのずれは、公開データから誰でも測定できます。組織的な不正を隠し続けることはできません。

​

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

1. Solana エクスプローラーでベットのトランザクションを開き、イベントのフィールドを読み取ります（アプリの Dice 画面ではセッションの公平性データの入力値が表示され、ベット履歴からトランザクションにリンクしています）。
2. sha256("dice" ‖ slothash ‖ user ‖ nonce) を再計算し、先頭16バイトをビッグエンディアンで読んで 10,000 で剰余を取り、イベントの roll と比較します。
3. 勝敗の判定（アンダーは roll < target、オーバーは roll > target）と倍率を、上記の式と照合します。