这个把戏，一段话讲清楚
密码学哈希函数把任意输入变成一个固定长度的指纹，这里有两个关键性质：你无法从指纹反推出输入，也找不到两个不同输入产生相同指纹。所以如果有人今天给你看一个秘密的指纹，明天再给你看这个秘密本身，你可以对这个秘密做哈希运算，检查是否匹配。如果匹配，那么他们今天给你看的秘密就是他们昨天已经有的那个。他们不可能在中间调换过，因为不同的秘密会产生不同的指纹，他们也不可能事后选一个秘密去凑指纹，因为那意味着要逆转哈希函数。
这就是承诺方案（commitment scheme），它就是“可证明公平”全部的密码学内容。庄家生成一个服务器种子，发布其SHA-256哈希值，用该种子派生出各轮游戏结果，等这对种子退役时再公布种子本身。其余的都只是配套流程。
已通过引擎验证_shared/seedApi.ts：getRandomKey 返回 {serverSeedHashed, clientSeed, nonce}；renewRandomKey 返回一对新的种子，同时附带 previousServerSeed 和 previousServerSeedHashed，即揭示值。_shared/SeedPanel.tsx 将该字段标注为“服务器种子（sha-256 承诺）”。_shared/rng.ts：sha256Hex() 计算指纹，hmacSha256Utf8() 计算每轮的哈希值，代码注释写道，演示引擎“使用与验证器检查结果相同的原语来生成结果——只有一套实现，因此演示结果永远不会偏离验证器所接受的结果”。
它证明的三件事
| 声明 | 成立的原因 | 核实方法 |
|---|---|---|
| 服务器种子在你下注前就已固定 | 种子的任何改动都会改变其哈希值，而哈希值在第一轮之前就已公布 | 在你游戏之前，先记下种子面板中的承诺值 |
| 揭示的种子就是当初承诺的那个 | 不同的种子不可能产生相同的SHA-256指纹 | 对揭示出的种子做哈希运算，与你记下的承诺值进行比对 |
| 每一局的结果都由种子对和轮次编号决定 | 结果是 HMAC-SHA256(服务器种子, "客户端种子-nonce-cursor") 经过该游戏公开的推导算法计算得出 | 用这四项输入在你的浏览器中重新计算该轮结果；面板会自动帮你完成这一步 |
这三项检查都是本地进行的：只需要揭示的种子、你的客户端种子、nonce 以及推导代码，检查时不需要庄家提供任何东西。
第三项声明才是真正为玩家发挥作用的一项，它依赖于推导算法的公开性。仅仅有种子的哈希值，并不能告诉你这个种子是如何变成一次掷骰子或一张牌的。而这里的这个函数是随客户端一起发布的，正是演示用来生成结果、也是验证器用来核实结果的同一套代码，所以重新计算一轮结果是真正的重新计算，而不是请求服务器自证清白。
ENGINE-VERIFIED_shared/demoLocal.ts: uAt() derives the per-round number as u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)), described as matching RandomUtils.generateHash on the server; _shared/rng.ts turns the first seven bytes of the HMAC into a uniform number in [0, 1) “matching the server’s Long→Double rounding bit-for-bit”. Each game’s derive module then maps that number to a roll, a card or a multiplier.
The verification walkthrough does all three steps on a real round. If you have never done it, do it once; the point of the scheme is not that you check every round but that you could check any of them, and the house cannot tell in advance which.
三件事它无法证明
它无法证明种子是随机的。承诺锁定了一个种子，但并未说明该种子是如何被选出的。如果庄家在生成服务器种子时就已知晓你的客户端种子，理论上它可以不断生成种子，直到找到一个前几局结果对自己有利的种子，然后再对其进行承诺。哈希值仍会完美通过校验。标准的防御方式是顺序：服务器种子先被承诺，客户端种子随后才被设定，这样无论庄家承诺了什么，它都不知道最终会与什么组合。
这个顺序问题正是本站面板存在一个值得明确指出的边界。在这里设置客户端种子并不会保留当前的服务器种子；它会轮换整对种子，而新的服务器种子是由携带你新客户端种子的同一个请求生成的。从客户端角度，无法证明新种子是在请求被读取之前就已固定的。服务器是否会预先生成下一个种子——就像一些运营商通过提前公布下一个承诺那样——在客户端的 API 中是不可见的，也没有
引擎验证_shared/seedApi.ts：setClientSeed(clientSeed) 会用新的客户端种子调用 renewRandomKey，并在 nonce 为 0 时返回一对新种子；rotate() 会在不带种子的情况下调用同一个接口。IHouseSeed 携带 serverSeedHashed、clientSeed 和 nonce，以及轮换时的上一对种子；该类型中不存在下一个种子的承诺字段。
在此之前，这个防御手段的实际版本其实就是该方案在其他方面已经提供给你的东西：揭示。一个针对你的客户端种子刻意
It cannot prove the game is fair in the other sense. “Provably fair” means the randomness was honest, not that the odds are even. A dice game can be perfectly verifiable and still return 99% by design; the edge lives in the payout table, which is a published number and a separate promise. The ethics of the house edge is about that promise. The commitment is silent on it.
它对没人核实的回合什么都无法证明。该方案是一种威慑，而不是保证。你从未重新计算过的回合，就是你完全依赖信任的回合，就跟在其他任何地方一样；改变的只是这种信任是可选的，而庄家无法知道你什么时候会去核实。这相较于一台你看不到内部结构的洗牌机是巨大的进步，但相较于
这个哈希是随机性的收据，而不是游戏本身的证书。这句话值得记住
什么能证明得更多
- 预先承诺的下一个种子。在任何客户端种子能与其配对之前，先公布下一个服务器种子的哈希，可以弥补上述顺序上的漏洞。这将是唯一能让面板证明种子在你的输入被知晓之前就已固定的改动。
- A public source of randomness. Mixing in a beacon that nobody controls, such as the drand network, removes the question of who chose the seed altogether; inside drand describes how that works and what it costs.
- A published derivation, kept public. Already the case here, and the part most easily lost when a client is rewritten. The verifier is only as honest as the code it runs.
这些改动都不会改变哈希本身是什么。它们改变的是哈希所对应的
,
什么是可证明公平赌场中的哈希承诺？
这是庄家秘密服务器种子的 SHA-256 指纹，会在游戏开始前展示，并在种子被揭示时进行核对。它证明了种子在你下注之前就已固定，并且被揭示的种子正是当初承诺的那个。
匹配的哈希能证明游戏是公平的吗？
它证明了随机性在承诺之后没有被篡改，并且在有公开推导方式的情况下，证明每个结果都是从种子对推导而来的。它无法证明种子是被随机选择的，也没有说明庄家优势的问题——那是一个另外公布的独立数字。
庄家能选出对自己有利的服务器种子吗？
只有在庄家选择服务器种子时就知道它将与哪个客户端种子配对的情况下才可能。防御措施是在客户端种子设定之前就先提交（commit）服务器种子。在本站，客户端种子的更改会在同一请求中轮换配对，因此这种顺序无法从客户端得到确认；文章描述了这一边界问题以及已提出的修复方案。
我该如何自行验证一局游戏？
轮换种子以揭示已退役的服务器种子，对其进行哈希以确认它与之前展示给你的承诺相符，然后基于你的客户端种子、nonce 和游标重新计算服务器种子的 HMAC-SHA256，并将结果代入该游戏公开的推导算法中。种子面板会在你的浏览器中执行这一重新计算过程。
为什么推导代码很重要？
因为哈希只能固定种子本身。把种子转化为一次掷骰或一张牌的结果是一个函数，除非这个函数是公开的，否则即便哈希匹配也无法说明结果是否就是该种子本应产生的结果。在这里，客户端使用的推导算法与演示模式生成结果时所用的完全相同。
可证明公平是否比持牌的 RNG 审计更好？
它们回答的是不同的问题。审计认证的是一个生成器在多次抽取中的统计表现；而承诺机制让你可以事后核实某一特定局的结果。两者互不可替代，也都不会改变庄家优势。
来源与参考资料
- 维基百科 — 承诺方案：隐藏性与绑定性，以及基于哈希的承诺
- 维基百科 — HMAC：密钥哈希及其作为伪随机函数的用途
- Betkyo 引擎源代码：_shared/seedApi.ts（提交、揭示与轮换）、_shared/rng.ts（sha256Hex、hmacSha256Utf8、7字节均匀分布）、_shared/demoLocal.ts（uAt 推导）、_shared/SeedPanel.tsx