骰子 Provably Fair 公式怎么读：结果到底是怎么算出来的

你在游戏记录里看到一串字段：server seed、client seed、nonce，还有一长段哈希值。可真正让人卡住的，往往不是字段名字，而是那一笔为什么会变成 62.48、14.67 或别的点数。

多数 provably fair 骰子游戏的思路其实一致：先用隐藏的服务器种子做承诺，再把客户端种子和 nonce 按固定顺序混进去，最后把哈希输出映射成骰子区间。它不是全行业共用的一条公式，而是一类做法；实现细节会变，但核心部件通常相同。

四个输入各自负责什么

先看公平性页面或下注日志里最常见的几项。理解这些字段，比死记一条公式更重要，因为不同游戏在拼接顺序上可能并不一样。

下注时，服务器种子通常不会直接公开，先展示给你的是它的哈希。等到种子轮换或揭示后，你可以自己把公开出来的服务器种子再哈希一次，看看结果是否与之前公布的哈希一致。对得上，至少说明这个承诺没有在下注后被改写。

第一步：先做哈希承诺，再产生点数

在任何可见结果出现前，系统会先生成一个服务器种子，通常是一段较长的随机文本。接着，对它执行哈希函数，常见的是 SHA-256。

假设隐藏值写作 server_seed = "m7Kx9..."。经过处理后，页面可能先公布一段类似 SHA256(server_seed) = 9f4c...e21a 的结果，而不会把原始种子直接给你。

这样做的意义在于：哈希值可以先公开，但通常不能反推出原始输入；反过来，只要输入哪怕改动一点点，输出哈希也会变成另一串完全不同的内容。于是，游戏就能先绑定一个隐藏种子，之后再揭示出来供你核对。

第二步：把客户端种子和 nonce 加进去

骰子游戏不能每一笔都吃同样的输入，否则结果会重复。新变量就在这里进入公式。

客户端种子很多时候可由玩家修改。Nonce 则一般从 0 或 1 开始，每下一注加 1。常见拼接方式之一是：

message = client_seed + ":" + nonce

随后计算带密钥的哈希，例如：

HMAC_SHA256(key = server_seed, message = client_seed + ":" + nonce)

也有实现会把顺序反过来，或者加入额外分隔符、回合编号、游标位置。有些则不用 HMAC，而是直接对拼接后的整串文本做 SHA-256。正因为这些差异存在，复核时不能只看“是不是 provably fair”，还得知道这个具体游戏写明了哪条公式。

不过，把外观差异去掉后，底层结构还是很像：隐藏的服务器种子、可见的客户端种子、可见的 nonce，再加一个确定性的哈希输出。

第三步：把哈希结果映射成骰子点数

哈希函数吐出来的是十六进制字符，不是直接可读的 0.00 到 99.99。中间必须多一道转换。

以常见的 0.00 到 99.99 骰子格式为例，一种简化写法是：先截取哈希前 8 位十六进制字符，把它转成整数，再压进目标区间。

hash = HMAC_SHA256(server_seed, client_seed + ":" + nonce)
first_8_hex = hash[0..7]
number = hex_to_int(first_8_hex)
roll = (number % 10000) / 100

举例看，如果 first_8_hex 转成十进制后得到 58321467，那么：

58321467 % 10000 = 1467
roll = 14.67

这个例子只是为了让过程更直观，不代表所有网站都这么算。有的游戏内部会保留 5 位小数；有的输出区间是 0 到 99、1 到 100，或先得到 0 到 9999 再格式化；还有一些为了分布处理，不直接做简单取模，而是分段读取哈希，直到落进允许范围。

所以，少了“如何从哈希映射到点数”这条规则，即便四个输入都拿到了，你也未必能复现出完全相同的结果。

为什么很多公式会用 HMAC

HMAC-SHA256 常见，不是因为它神秘，而是因为它很适合“一个隐藏值 + 一个公开消息”这种结构。在这套机制里，服务器种子通常扮演 key，客户端种子加 nonce 组成 message。

它的特点很实用：输入完全相同，输出就完全相同；只改动一个字符，哪怕只是把 nonce 从 12 变成 13，结果也会出现剧烈变化。对复核工具而言，这正是想要的效果，因为它让每一笔记录都能被机械地重算。

一次完整的复核流程示例

假设某一轮揭示后，页面给出的字段如下。

复核顺序通常分两段。先对揭示后的服务器种子执行页面写明的算法，常见是 SHA-256；如果输出刚好等于下注前公布的哈希，说明承诺能对上。

接着，严格按该游戏说明重建计算式。例如：

hash = HMAC_SHA256("R4vN2pL8xQ", "player-27:41")

然后再应用这款游戏声明的点数转换规则。如果你算出来的点数与下注历史里的点数一致，就表示该回合结果可以由这些已公开输入复现，而不是事后随意改写。

这个检查没有模糊空间。能对上，就是对上；对不上，就需要回头检查公式、顺序、分隔符和 nonce 起始值。

Provably fair 能证明什么，不能证明什么

这个词很容易让人误会范围很大。对骰子游戏来说，它验证的是“单回合完整性”，不是对整个平台作全面背书。

它通常能证明三件事：公开后的服务器种子与先前公布的哈希一致；该回合点数可以由服务器种子、客户端种子、nonce 和声明公式复算出来；在默认公布公式就是实际公式的前提下，这笔结果不是在承诺后临时改掉的。

Nonce 在这里尤其关键，因为它让每一笔下注都拥有不同输入，整个序列才可以逐回合审视。

但它证明不了很多别的事情。比如账户余额处理、提现流程、客服裁量、限制措施、平台财务状况，或站内所有游戏是否都采用同一方法，都不在这套校验的直接覆盖范围里。它也不能让你提前预测下一次结果，因为服务器种子在揭示前仍然是隐藏的；已公布的哈希更像一把“事后对账”的钥匙，而不是“提前看牌”的窗口。

这也是 provably fair 与 RNG 测试常被混淆的地方。RNG 认证更像外部测试模型，用来评估随机机制表现；provably fair 则偏向玩家侧复现模型，针对的是某一局能否按公开输入重算。

常见公式差异，往往就差在细节

不少复核失败，并不是结果真有问题，而是抄错了一个冒号，或者把 nonce 起点理解反了。下面这些变化最常见。

少一个分隔符，结果就会完全不同。把 0 当成 1，同样会错。所以最稳妥的做法，是照着该游戏自己的说明一字不差地复制，再用本地脚本或可信的哈希工具重算。

怎么看公平性页面才不容易迷路

玩家真正关心的，往往不是抽象的“哈希是什么”，而是“我的 62.48 是怎么来的”。查一笔记录时，重点找下面几项：

下注前公布的服务器种子哈希；揭示后的服务器种子；你的客户端种子；该笔下注对应的 nonce；以及精确的哈希算法和点数映射规则。

只要缺了其中任意一项，独立复核就会变得困难，甚至无法完成。不同站点的界面、字段命名和展示方式差异很大，但大多数骰子 provably fair 公式，骨架都还是这些核心元素。

常见问题

provably fair formula for dice roll 一般长什么样？
没有单一通用公式。常见模式是用 HMAC-SHA256，把服务器种子作为 key，把客户端种子和 nonce 组成 message，再按该游戏声明的规则把哈希输出映射到骰子区间。

只看已公布的哈希，能不能提前算出下一次骰子结果？
不能。已公布的哈希只是对隐藏服务器种子的承诺，不等于服务器种子本身。它通常适合事后核验，不能单靠这一串哈希预知未来结果。

provably fair 是否等于整个平台各方面都公平？
不等于。它验证的是某一局游戏能否根据公开输入被复算，以及服务器种子承诺是否前后一致；至于余额处理、提款流程、账户措施或整体经营情况，都不由这套机制单独证明。

理性游戏

博彩应当被当作需要付费的娱乐，而不是赚钱或者翻本的途径。

参与者需年满 18 岁，部分司法辖区要求 21 岁，请遵守你所在地区适用的最低年龄规定。

如需帮助：美国读者可拨打 1-800-MY-RESET(1-800-697-3738)；其它地区请查询当地的问题赌博求助资源。

本文是关于相关机制的一般性说明，不构成法律建议，也不是对博彩行为或任何平台的推荐。各地的可用性与法律规定不同，请以你所在辖区的规则为准。