トレントギア

Provably Fairとは何ですか？ゲームの完全性をテストする方法

Provably Fairとは何ですか（PF）

Provably Fairは、ラウンド結果がランダムであり、ベット後にオペレータに置き換えることができなかったことを暗号的に検証できるプロトコルです。

アイデア：最初にコミットが公開され（隠されたサーバーシードのハッシュ）、ベット後にリビルが明らかになり（サーバーシード自体）、誰でもハッシュをチェックしてRNGを再現することができます。

基本プロトコル： commit→bet→reveal

1.コミット：ラウンドの開始前に、サーバーはランダムな'server_seed'を生成し、そのハッシュを公開します：


commit= （          塩）//またはKeccak-256

コミットは履歴/ブロックチェーン/ジャーナルに表示できます。

2.ベット：プレイヤーは（UIまたは自身の）client_seedを選択または確認し、次のベットを送信します：


client_seed、 roundId、 nonce

3.明らかに：ベットを終了した後、サーバーは'server_seed'（そして'salt'があった場合）を明らかにし、誰もがチェックできるようにします：


 （          salt）==commit//integrityチェック

4.RNG：乱数は決定論的で再現性がある：


rng=HMAC-SHA256 （key=server_seed、 msg=client_seed        roundId        nonce）
//またはrng=SHA-256 （server_seed        client_seed        roundId        nonce）

5.結果へのマッピング：変位なしでゲームの範囲に'rng'を変換します（以下を参照）。

💡 なぜノンスなのか？1つの'server_seed'を使用すると、予測可能性のリスクなしに多くのラウンドを費やすことができます。'nonce'はラウンド/ベットごとに増加します。

バイアスフリー番号を取得する方法

'rng％ N'を取るのは間違っています-これは2^kがNの倍数でない場合にモジュラーオフセットを与えます。それは正しいです-拒絶サンプリング：

pseudo（疑似）
//rng_bytes=32バイトhash→uint256 x=uint256 （rng_bytes）

limit=floor （2^256/N） N、 x>=limit：
rng_bytes=SHA-256 （rng_bytes）//」mix「再び決定的にx=uint256 （rng_bytes）

結果=x％ N

したがって、Nアウトカム（ルーレットセル、ドラムシンボルなど）に対する均一な分布が得られます。

ミニサンプル（プレーヤーステップ検証）

次のようにします：


server_seed="b2c6……e9"//ラウンド後に表示される（hex/utf8）
client_seed=「my-client-seed「//選択したroundId=」R-2025-10-17-001「
nonce=42 commit="c9a1……f3 "//publ。予めご了承ください

1）コミットの確認

'SHA-256 （server_seed）'を数え、'commit'と一致することを確認します。

2）決定論的RNG

カウント：


rng=HMAC-SHA256 （key=server_seed、 msg=client_seed         ":"         roundId         ":"         nonce）

3）結果への変換

ルーレット（37数字）→N=37の場合、拒絶サンプリングを適用して'x％ 37'を取ります。

スロットの場合、複数のRNGチャンクを使用して、割り当てテーブルに従ってリール/シンボルを定義します。

4）履歴の結果に対するチェック

このサイトには、計算で使用されたのと同じ入力が表示されます：'server_seed'、 'client_seed'、 'roundId'、 'nonce'、 'hashAlgo'、 'rngAlgo'、 'mappingVersion'。

代替/利得： VRF（検証可能なランダム関数）

コミットの代わりに、オペレータは（またはオプションで）VRFを使用できます：

1.スマートコントラクトまたはパブリックレジストリは、プロバイダに「VRF （seed）」を要求します。

2.'（ランダム、証明）'によって発行されました。

3.誰もが同じ公開VRFキーペアで「証明」をチェックアウトすることができます。

4.次に、結果への同じRNGマッピングのステップ。

長所：オペレータへの信頼が少ない。デメリット：VRFプロバイダ/チェーンへの依存と可能なコスト。

カジノがPFを正しく実装する方法

契約（PFデータ契約）

ラウンド履歴の余白：

'serverSeedHash'、 'serverSeedReveal'、 'clientSeed'、 'roundId'、 'nonce'、 'hashAlgo'、 'rngAlgo'、 'mappingVer'、 'proofUrl' （опц）、'calcVer'。
値-WORMストレージ（不変）、タイムスタンプ（UTC）。

シード生成

'server_seed'は暗号PRNG （OS CSPRNG/HSM）によって生成されます。

シッドは直列（回転）の間で繰り返されるべきではありません。

'client_seed'-プレイヤーによって選択されるか、クライアント上で生成され、確認されます。

パブリッシングコミット

コミットはベット前に利用可能です（履歴、RSS、オンチェーンアンカー）。

たくさんの場合、毎日公開されるルートでコミット・マークリー・ツリーを使用できます。

明らかにする

結果を公開する前に、'server_seed'が展開され、ログが記録されます。

1つの座席の一連のラウンド-シリーズの終了後の開示（事前にポリシーを示します）。

透明なマッピング

マッピングアルゴリズムのバージョン（'mappingVer'）を修正しました。

変更（'mappingVer'/'rngAlgo'）-発表と新しい一連のコミットのみ。

監査と紛争

未加工入力+保存される計算の記録；引数すると、レポートが生成されます：inputs→RNG→mapping→outcome。

ストリーム/ライブ：ストアCV/RFIDイベントハッシュアンカー、WORMのビデオ。

プレーヤーが正直さ（チェックリスト）をチェックする方法)

1.ラウンドの履歴を開き、コピーします：'serverSeedReveal'、 'clientSeed'、 'roundId'、 'nonce'、 'hashAlgo'、 'rngAlgo'、 'mappingVer'。

2.ハッシュ'serverSeedReveal'を数え、'serverSeedHash'と比較します。

3.指定されたアルゴリズム（HMAC/Hash+入力）に従ってRNGを計算します。

4.結果の数に「公平な」マッピング（拒絶サンプリング）を適用します。

5.結果が示されているのと同じであることを確認してください。

6.VRFが宣言されている場合は、'proof' （「Verify」ボタンまたは独立したスクリプト/ブロックエクスプローラ）をチェックしてください。

典型的なエラー（アンチパターン）

'rng％ N'拒絶サンプリング→バイアス確率。

「client_seed」（プレイヤーの参加なしでサーバーによって生成された）を隠したり変更したりします。

ベット後に'server_seed'を再生成します（コミットは遡って変更されます）。

バージョン/パブリケーションなしで不透明なアルゴリズムが変更されます。

シリーズ間の側面の再生。

WORM/タイムスタンプの欠如-イベントの順序を証明することはできません。

PFとビジネスロジックのミキシング（例えば、ボーナスは結果空間を変更するような方法で適用されますが、これは'mappingVer'では説明されていません）。

FAQ（短い）

ルーレットだけでなく、スロットをチェックすることは可能ですか？

はい、私はしました。PFは選択シーケンスに適用されます（例えば、リール上のシンボルインデックス）。RNG確率表と読み取り順序が文書化されていることが重要です。

そして、'client_seed'を入力すると、オペレータは'server_seed'を「拾う」ことができますか？

コミットが入札前に投稿された場合ではありません。'server_seed'を修正し、それを遡って置き換えることはできません。

なぜ彼らは時々バッチで側面を明らかにするのですか？

シリーズの種を「整理」することができなかったように。これは、コミットが事前に公開され、開示方針が透明である場合に許容されます。

ミニリファレンスフォーマット

ハッシュ：SHA-256またはKeccak-256。

RNG： HMAC-SHA256または連結SHA-256。

識別子：'roundId' （UTC-stamp+game+increment）、 'nonce'（シリーズ内のベットカウンタ）。

'rngAlgo=HMAC-SHA256@1'、 'mappingVer=roulette。v2'、'calcVer=wallet-7。2`.

オペレータPF実装チェックリスト

暗号とサイド

CSPRNG/HSM；一意の'server_seed'、ドキュメント化された回転。
'client_seed'-プレイヤーによって制御され、履歴に保存されます。

出版物とストレージ

ベットへのコミット、履歴/出版チャンネル/アンカーへのアクセス。
WORMの貯蔵、UTCの切手、スケールのためのmerkleyバッチ。

アルゴリズム

バイアスのないRNGとマッピング；バージョン管理'rngAlgo/mappingVer'
スクリプト/ページ「正直を確認」（オープンソースが望ましい）。

ライブとハイブリッド

CV/RFID/ラウンドフェーズハッシュアンカー、ログ「ベッティングウィンドウが閉じられたとき」。
紛争手続（vkhodov→iskhodレポート、コミット/VRFへのリンク）。

セキュリティと監査

PFプロトコルの独立監査、バグバウンティ。
意思決定ログは不変です。定期的なリプレイテスト。

Provably Fairは「、私たちを信頼する」ことを「自分で確認する」に変えます。"コミット/revilまたはVRF、決定論的RNG、および正しいオフセットマッピングを使用すると、任意のラウンドが再現可能で検証可能になります。プレイヤーにとっては透明性と信頼です。オペレータのために-より少ない論争、より強いブランドと規制要件の遵守。主なものは規律です：事前にコミットを公開し、アルゴリズムのバージョンを修正し、証拠を常に保存し、ユーザーに簡単な検証ツールを提供します。