Crash 倍率的 Provably Fair 公式怎么验

你在游戏记录里复制了 server seed，又把那串哈希贴进校验器，前后能对上。可还有个更实际的问题：它究竟是怎么变成 1.27x、8.43x 这种 Crash 倍率的？这正是 provably fair formula for crash multiplier 要回答的事。

常见做法是，游戏先在开局前对一个隐藏值做“承诺”，再把它和玩家可见的数据混合，最后算出本局停在哪个倍率。只要流程公开、计算方法固定，玩家就能回头检查：这一局结果是否在下注后被改动过。范围也仅限这里。它不说明平台资金情况，不说明提款流程，更不说明整体经营方式。

Crash 公式到底在证明什么

Crash 每一局只需要一个关键数字：曲线停下来的倍率。Provably fair 试图证明的，不是“结果好不好”，而是这个数字是否来自一组预先承诺的输入，而不是看见谁下注、谁提前兑现之后临时改出来的。

这个验证通常分两步。第一步，开局前先公布 server seed 的哈希；等到后面公开原始 seed 时，再把它重新哈希，看看能否还原成同一串值。第二步，把公开后的 server seed、client seed 和 nonce 按固定顺序代入公式。因为原料和算法都已知，任何人都能重算一遍，再和历史记录里的 Crash 倍率比对。

这里的“provably fair”，说的是单局结果可核对。不要把它延伸理解成别的保证。

四个核心部件：server seed、hash、client seed、nonce

先看 server seed。你可以把它理解成一段很长的隐藏文本。游戏不会先把这段文本亮出来，而是先展示它的哈希值。哈希函数在实际使用里是单向的：你能拿 seed 去算哈希再比对，却很难反推出原始 seed。

再往下是 client seed。有些站点允许玩家手动改，有些则默认系统分配。它的意义，不是替代 server seed，而是给最终计算再加一个可见输入。

最后是 nonce。假如同一次会话里，server seed 和 client seed 连着用很多局，没有 nonce 的话，结果会重复。加上它以后，每局输入都会轻微变化，常见形式就是 0、1、2 这样递增。

第一步：开局前的哈希承诺

结果出来之前，游戏先生成 server seed，再把它哈希。玩家一开始常见到的，只是一串很长的字母和数字。

关键不在这串字符多复杂，而在时间顺序。只要哈希是在开局前就已展示，之后公开的 server seed 又能重新算回完全一样的哈希，运营方就不能事后换另一组 seed 来冒充原值，否则两边会对不上。

这一步就是“承诺”。隐藏输入先被锁定，但暂时不揭晓。对 Crash 来说，这一点很重要，因为倍率应该来源于早已承诺的 seed，而不是在下注分布变得清晰后才临时挑选。

第二步：把输入组合起来

等到本轮结束，或者整组种子轮换时，server seed 会被公开。接下来，系统要把 server seed、client seed 和 nonce 按既定顺序拼接并计算。顺序不能乱。

举个结构例子，serverSeed:clientSeed:nonce 与 clientSeed:serverSeed:nonce 不是同一个输入；把 nonce 放到最前面，结果又会不同。很多实现会把这串输入送进 HMAC-SHA256 或 SHA-256，得到一段十六进制输出，再取其中一部分转成十进制。

常见结构可能长这样：

hash = HMAC_SHA256(serverSeed, clientSeed:nonce)
hash = SHA256(serverSeed:clientSeed:nonce)

注意，这只是结构示意，不是全行业统一标准。不同 Crash 游戏可能使用不同哈希函数、不同拼接顺序，也可能在最后一步采用不同的倍率换算规则。所以校验时，必须对照该游戏自己公布的方法；两个校验器都可能“数学上没错”，但如果配方不同，结论一样会冲突。

第三步：哈希怎样变成 Crash 倍率

多数人真正想找的，就是这里。哈希输出本身不是倍率，系统还得把它映射成大于 1.00x 的停止点。

常见思路是：先生成哈希；再取其中一段可用区间，比如前若干个十六进制字符；把这段值转成一个整数；最后代入倍率公式。

其中一类 Crash 公式，会基于一个最大整数范围做分式换算。抽象写法常见于：

multiplier = floor((A / (A - n)) * 100) / 100

这里的 A 是由位数范围决定的固定上限，n 则是从哈希里取出的整数。有些版本还带额外规则：当哈希满足某个整除条件时，直接触发 1.00x。也有实现会在四舍五入前先扣掉一点边际，或者改用 52 位而不是 32 位去取值，这都会改变数值区间与结果分布。

结论很直接：Crash 倍率并不存在一个放之四海皆准的 provably fair 公式。更准确地说，是有几类常见公式家族，而每个游戏的验证器都必须和自己的文档一字不差地对应。

一个按结构演示的核对例子

假设有这样一局，下面数字仅作演示：

Server seed：一段开局前隐藏、结束后公开的文本
Client seed：player-84
Nonce：17

这局开始前，系统已经展示过 server seed 的哈希。等公开原值后，你先自己哈希一次，确认和之前的承诺一致。随后，按该游戏公布的方法继续计算。比如它规定：以 server seed 作为 HMAC-SHA256 的 key，把 player-84:17 当作 message。

算出来的十六进制哈希，也许会以 3fa4c9... 开头。接着，你按规则截取指定片段，转成十进制整数，再代入它的 Crash 公式。若你重算出的倍率是 2.61x，而历史记录显示的也是 2.61x，这一局就通过了公式核对。

如果对不上，可能是公布的输入有误，也可能是你用错了公式，或者历史展示和说明文档彼此不一致。无论结果是 1.08x 这种偏低值，还是很高的倍率，检查的重点都不是“看起来像不像随机”，而是它是否和那组承诺输入保持一致。

它能证明什么，不能证明什么

还有个容易忽视的限制：这种验证发生在事后。server seed 在公开前仍是隐藏的，所以系统不会提前告诉你下一局会停在哪。它也不会消除波动。Crash 完全可能连续很多局都在低位结束，偶尔才拉出很长一段高倍率。

Provably fair 检查的是生成过程的完整性，不提供预测能力，也不改变单次会话的结果起伏。

为什么两个 Crash 校验器会算出不同结果

对不上，并不一定意味着被动过手脚。更常见的情况，是你拿错了“菜谱”。

一个校验器可能默认 SHA-256，实际游戏却用 HMAC-SHA256；另一个可能读取前 52 位，而游戏只取前 32 位；还有的忽略了某个“命中条件即 1.00x”的特殊规则。连格式细节都可能出问题，比如多了空格、分隔符写错、大小写处理不同，或者 nonce 实际从 0 开始，你却按 1 去算。

遇到差异时，先逐项核对这些细节：

哈希函数是否一致
输入顺序是否一致
分隔符是否一致
Nonce 起始值是否一致
使用了多少位或多少个十六进制字符
四舍五入规则是否一致
是否带有瞬间坠毁到 1.00x 的附加条件

怎么读一页像样的 provably fair 说明

只有哈希展示，还不够。真正有用的说明页，应该把“哈希如何变成倍率”也讲清楚，至少要让第三方能独立复算。

这意味着它需要明确写出：使用哪种哈希函数，输入按什么顺序拼接，nonce 如何递增，以及十六进制输出怎样转换成最终 Crash 数字。缺少这些信息时，玩家最多只能确认“承诺”存在，却无法完整验证倍率计算。

有些站点还允许手动修改 client seed。这样做不会天然带来更好或更差的结果，但会让输入来源更透明，因为至少其中一个值由玩家侧决定。

常见问题

Q1：Crash 倍率有统一的 provably fair 标准公式吗？
A：没有。很多游戏的思路相近，但具体实现可能在哈希函数、输入顺序、位数长度、取值区间、舍入方式以及是否存在 1.00x 特殊条件上都不同。

Q2：Crash 公式里的 nonce 是干什么的？
A：它通常是每局或每次下注递增的计数器。当同一组 server seed 和 client seed 被连续使用时，nonce 负责让每次计算输入发生变化，避免重复结果。

Q3：Provably fair 是否代表游戏整体没问题，或者已经被独立认可？
A：不是。它只能帮助你验证某一局结果是否符合已公布的密码学方法与承诺输入，范围不覆盖资金安排、提款处理或其他运营层面的事项。

理性游戏

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

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

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

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