加密賭場

Torrent Gear

Provably Fair是什麼以及如何測試遊戲的誠信

什麼是Provably Fair （PF）

Provably Fair是一種協議，允許加密驗證回合的結果是隨機的，並且在下註後無法被操作員欺騙。

想法：首先發布commit（隱藏服務器種子的哈希），然後在下註後顯示revil（服務器種子本身），並且任何人都可以檢查哈希並播放RNG，給定玩家的客戶端種子和回合ID。

基本協議： commit → bet → reveal

1.Commit：在開始回合之前,服務器會生成隨機的「server_seed」並發布其哈希：


commit = SHA-256(server_seed         salt）//或 Keccak-256

Commit可以輸出到歷史/區塊鏈/雜誌中。

2.投註：玩家選擇或確認其「client_seed」（來自UI或自己的投註），從以下位置發送投註：


client_seed, roundId, nonce

3.Reveal：關閉費率後,服務器會顯示「server_seed」（如果有的話,「salt」（如果有的話））,以便每個人都可以檢查：


SHA-256(server_seed         salt）==commit//驗證完整性

4.RNG：確定性和可重現的隨機性數：


rng = HMAC-SHA256(key=server_seed, msg=client_seed          roundId          nonce)
/或rng=SHA-256（server_seed         client_seed          roundId          nonce)

5.映射到結果：我們將「rng」轉換為無偏移的遊戲範圍（請參見下文）。

💡 為什麼nonce？這樣，在單個「server_seed」下可以進行許多回合，而沒有可預測的風險：每個回合/投註都將「nonce」嵌入其中。

如何獲得無偏移數（bias-free）

如果2^k不是N.的倍數，則誤用「rng％N」會產生模塊化偏移。正確-反射采樣：

pseudo
/rng_bytes=32字節哈希→ uint 256 x=uint 256（rng_bytes）

limit = floor(2^256 / N) N while x >= limit:
rng_bytes=SHA-256 （rng_bytes）//再次以確定性x=uint 256 （rng_bytes）

result = 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」 //opub。提前

1）檢查Commit

計算「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代替commit：

1.智能合同或公共註冊處要求提供商「VRF（種子）」。

2.由「（random，proof）」出版。

3.任何人都可以檢查同一個公共關鍵對VRF的「證明」。

4.接下來是將RNG映射到結果中的相同步驟。

優點：對操作員的信心降低。缺點：對VRF提供商/鏈條的依賴以及可能的成本。

賭場應如何正確實施PF

合同（PF數據合同）

回合歷史上的字段：

`serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.), `calcVer`.
值在WORM存儲（immutable）中，帶有時間印章（UTC）。

Sides生成

「server_seed」由耐密碼的PRNG（OS CSPRNG/HSM）生成。

蘋果酒絕不能在系列之間重復（輪換）。

「client_seed」-由玩家選擇或在客戶端上生成並確認。

Commites的出版

Commites最多可以下註（歷史，RSS，鏈式錨定）。

對於批次，可以使用commites mercli樹，每天發布根。

披露（reveal）

在發布結果之前,將顯示「server_seed」並進行邏輯化。

對於一個座位上的系列回合-系列結束後的披露（提前指定策略）。

透明的mapping

捕獲了映射算法的版本（「mappingVer」）。

任何更改（「mappingVer」/「rngAlgo」）僅帶有公告和新的commites系列。

審計和爭議

原始輸入+計算記錄得以保留；當發生爭議時，會生成一個報告：→ RNG →映射的輸入→結果。

Strims/Live：在WORM中存儲CV/RFID事件的哈希主播,視頻。

玩家如何檢查誠實（支票清單）

1.打開回合歷史記錄，復制：「serverSeedReveal」，「clientSeed」，「roundId」，「nonce」，「hashAlgo」，「rngAlgo」，「mappingVer」。

2.計算「serverSeedReveal」哈希並與「serverSeedHash」進行比較。

3.根據指定的算法（HMAC/Hash+輸入）計算RNG。

4.將「無位置」映射（rejection采樣）應用到結果數。

5.確保結果與顯示的結果相同。

6.如果聲稱VRF,請檢查「proof」（驗證按鈕或獨立腳本/塊explorer）。

類型錯誤（反模式）

「rng% N」沒有反射采樣→偏移概率。

隱藏或更改的「client_seed」（由服務器生成而無需玩家參與）。

下註後的「server_seed」過熱（下註會追溯更改）。

沒有版本/發布的不透明算法更改。

系列之間的座位重播。

沒有WORM/時間印章-無法證明事件的順序。

PF和業務邏輯的混合（例如，應用獎勵以改變結果空間，但這在「mappingVer」中沒有描述）。

常見問題（簡稱）

可以檢查插槽，而不僅僅是輪盤賭嗎？

是的。PF適用於選舉順序（例如，鼓上的符號索引）。重要的是要記錄概率表和RNG讀取順序。

如果我輸入了我的「client_seed」，操作員仍然可以「拾取」「server_seed」？

不，如果commit是在賭註之前發布的。它捕獲「server_seed」，並且不允許事後替換它。

為什麼有時會打包地露出蘋果酒？

因此，沒有辦法在系列中「超越」sid。如果提前發布Commit並且披露策略是透明的，則允許這樣做。

格式的迷你參考

哈希：SHA-256或Keccak-256。

RNG：HMAC-SHA256（服務器sid作為密鑰）或串聯SHA-256。

標識符是：「roundId」（UTC郵票+遊戲+嵌入式），「nonce」（系列中的投註計數器）。

Версии: `rngAlgo=HMAC-SHA256@1`, `mappingVer=roulette.v2`, `calcVer=wallet-7.2`.

操作員的PF實施支票

密碼學和蘋果酒

[] CSPRNG/HSM;唯一的「server_seed」，記錄的輪換。

「client_seed」-由玩家控制，保存在故事中。

出版物和存儲

下註前，訪問歷史/出版渠道/主持人。
WORM存儲，UTC模具，mercley-batches的比例。

算法

無偏移的RNG和映射；轉化「rngAlgo/mappingVer」。
「檢查誠實」腳本/頁面（需要開源）。

現場和混合體

Hash主持人CV/RFID/回合階段，雜誌「當投註窗口關閉時」。
爭議程序（報告vkhodov→iskhod，引用commits/VRF）。

安全性和審計

PF協議的獨立審計，錯誤賞金。
決策的邏輯是不可改變的；定期播放測試。

Provably Fair將「相信我們」變成「自己檢查」。隨著commit/revil或VRF，確定性的RNG和正確的mapping而沒有偏移，任何回合都可以復制和可驗證。對於玩家來說，這是透明度和信任。對於運營商來說-減少爭議，更強大的品牌和遵守監管機構的要求。主要的是紀律：提前發布commits，記錄算法的版本，始終存儲證據並為用戶提供一個簡單的驗證工具。