Web3 Casino 的“可验证公平”能验证什么？从随机数到链上结算
从 Stake 的种子验证到 Chainlink VRF，理解随机数、游戏规则、RTP 与链上结算各自能提供什么证据。
一笔充值可以在区块浏览器中查到，只能说明这笔转账有链上记录。游戏如何生成结果、奖励如何计算、资金由谁控制，还需要另外的证据。
同样，页面上的「Provably Fair」标识也有具体的验证范围。理解 Web3 Casino 的技术机制，首先要弄清楚：哪些信息可以独立核对，哪些环节仍然依赖平台或其他服务。
本文以 Stake 公开的随机数实现和 Chainlink VRF 为例，讨论不同机制提供的证据及其边界，最后用同一套问题分析 Zawa 的 Lucky Pick 实现。分析依据为技术文档、项目源码与部署记录，不代表对任何平台整体安全性的审计结论。
支付、随机数和结算，需要分别验证
分析一款使用加密货币的游戏，可以先把它拆成四个部分：
| 环节 | 需要回答的问题 | 可检查的证据 |
|---|---|---|
| 支付 | 资金是否转到了所声明的地址？ | 转账记录、收款地址、Token 合约 |
| 随机数 | 生成结果的过程是否符合公开机制？ | 种子承诺、公开算法或随机数证明 |
| 游戏规则 | 随机数如何变成输赢和奖励金额？ | 结果转换逻辑、概率与奖励公式 |
| 结算与控制权 | 谁能转移资金，什么条件下会付款？ | 合约逻辑、管理权限和实际结算记录 |
这个划分有助于限定每份证据的作用。例如，一条转账记录通常不足以解释某个开奖结果；一份随机数证明也不会自动覆盖奖励计算。
智能合约可以把规则写成程序，由区块链执行。但具体有哪些规则进入了合约，仍然要查看实际实现。以太坊智能合约介绍
Provably Fair：核对结果是否符合事先承诺
Stake 公开的实现使用服务器种子、客户端种子、递增计数等输入，通过 HMAC-SHA256 生成用于计算结果的数据。平台预先提供服务器种子的哈希，在种子更换后公开旧种子，使历史结果能够被复核。Stake 技术说明
可以把这里的哈希理解成事先留下的“指纹”。在密码学假设成立、原始记录可信的前提下，核对公开后的种子与原先的哈希，有助于发现事后替换种子的行为。结合完整输入和对应的游戏算法，还可以复算结果。
这种验证依赖算法、输入和历史承诺的可获得性。它的范围也需要明确：一次结果复核成功，并不同时证明平台持有足够资金，或者所有提款都能完成。上述文档也不能直接作为该平台所有游戏采用相同机制的证据。
链上 VRF：让合约先验证随机数证明
VRF 是 Verifiable Random Function，即可验证随机函数。
按照 Chainlink 的文档，每次请求会产生随机值及相应的密码学证明，证明会在链上验证，随后供应用使用。这里需要区分随机数的生成与证明的验证：链上验证并不意味着所有计算都在链上完成。Chainlink VRF 文档
与前面的种子公开机制相比，Chainlink VRF 将证明验证纳入了合约接收随机数的流程。这改变了验证发生的位置和时机，但游戏仍然需要正确使用这个随机数。
例如，随机数请求必须对应正确的游戏记录；系统不能选择性地丢弃不合意的结果。Chainlink 的安全说明专门讨论了请求匹配、取消或重新请求，以及请求发出后继续接受会影响结果的输入等问题。Chainlink VRF 安全说明
因此，仅凭“接入 VRF”无法判断整个游戏实现是否正确。随机数证明和应用如何使用随机数，需要分别检查。
结果可以复核，RTP 仍然需要单独理解
随机过程遵循公开机制，并不意味着所有结果具有相同概率，也不意味着奖励规则没有平台优势。
RTP（Return to Player，返还率）描述的是返还与投入之间的长期统计关系。理论 RTP 来自游戏的概率和奖励设计；实际 RTP 则来自一段历史数据中的返还总额与投入总额。两者在有限样本中可能存在差异。英国博彩委员会：RTP 的计算与监测
假设某个游戏标注 95% 的理论 RTP，这不代表每次有 95% 的中奖概率，也不保证某个玩家投入 100 个单位就能拿回 95 个单位。长期平均值不能被当作个人一次参与或一段时间内的收益承诺。英国博彩委员会：理解 RTP
比较不同规则时，还需要统一计算口径：奖励金额是否包含本金，是否另收费用，页面数字是否对应当前游戏版本。只有这些条件清楚，同名指标才具有可比性。
链上结算的证据，还包括合约权限
一款游戏即使通过智能合约结算，也需要说明哪些行为由代码固定，哪些行为由管理权限控制。
例如，采用可升级代理的系统，可以在保留用户交互地址的同时更换执行逻辑。升级能力有助于修复问题，也引入了对升级权限持有者的信任。因此，看到合约地址并不足以推断规则永远不会变化。以太坊智能合约升级文档
一份有依据的技术分析，应当记录具体网络、合约地址、实现版本，以及检查时点；再核对费用修改、暂停、升级和资金转移等权限。权限是否存在、由谁持有、受到什么限制，都需要从实际实现中确认。
例如，一份完整的游戏记录应当能够把参与时的规则、对应的随机数、结果转换过程、奖励计算和结算交易联系起来。如果证据只覆盖其中一部分，对“可验证”的描述也应限定在这一部分。
Zawa 如何处理这些问题？以 Lucky Pick 为例
Zawa 目前运行在 BNB Smart Chain，支持 BNB、USDT 等 Token，具体币种由房间规则确定。以 Lucky Pick 为例，参与金额、数字范围和奖励金额会在创建房间时写入智能合约，房主同时存入对应的奖励资金。
Lucky Pick 使用 Chainlink VRF 提供的随机数生成开奖结果，并将请求关联到具体订单，再由合约按规则处理结算。房间参数、开奖结果及资金转账分别留下记录，可用于核对游戏从规则到结算的过程。Lucky Pick 合约
页面展示的 RTP 是由房间参数计算的扣费前理论返还率，不代表单次中奖概率或个人收益。实际到账还需考虑平台佣金和 VRF 费用，部分费用按结算时的配置计算。因此，核对结果时也需要查看实际扣费与到账记录。