加密赌场

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，记录算法的版本，始终存储证据并为用户提供一个简单的验证工具。