Dice 公平性

​

Dice 为什么没有承诺步骤？

• slothash —— 你的下注交易执行那一刻，Solana SlotHashes sysvar 中最新的条目。这是由网络产生的熵，在构造交易时并不可知（发送方无法确知一笔交易会落在哪个槽位）。
• user —— 你链上用户账户（程序由你的钱包推导出的账户）的 32 字节地址。它使不同玩家之间的点数相互独立：落在同一槽位的两笔下注会得到不同的点数。
• nonce —— 你个人的下注计数器，存储在链上，每玩一次递增。它使你自己连续的下注即便落在同一槽位也彼此独立，同时兼作重复提交的防护。

​

Dice 点数的精确公式是什么？

输入
  slothash   32 字节   下注交易执行时最新的 Solana 槽位哈希
  user       32 字节   你链上用户账户的地址
  nonce      8 字节    你的下注计数器，小端

推导
  hash = sha256( "dice" ‖ slothash ‖ user ‖ nonce )   // "dice" = 4 个 ASCII 字节 0x64 0x69 0x63 0x65
  roll = u128_be( hash[0..16] ) mod 10000              // 前 16 字节，按大端读作无符号 128 位整数

结果
  roll 是 0..9999 之间的整数 —— 对应 0.00–99.99，保留两位小数

• 哈希输入是按以下确切顺序拼接的：ASCII 标签 "dice"、槽位哈希、用户账户地址，然后是编码为 8 字节小端的 nonce。
• 采样取 SHA-256 输出的前 16 字节，按大端读作无符号 128 位整数，再对 10,000 取模。
• 把 128 位样本对 10,000 取模，其理论偏差低于 2⁻¹¹⁴ —— 比庄家优势小了几十个数量级，因此我们选择把它记录下来而非去修正它。

​

获胜条件与赔付

押下方（Under）：roll < target 时获胜      胜率 = 10000 种结果中的 target 种
押上方（Over） ：roll > target 时获胜      胜率 = 10000 种结果中的 9999 − target 种

multiplier_bps = floor( (10000 − edge_bps) × 10000 / win_chance_bps )

​

什么被保证了，什么没有

• 点数的推导与结算都在一条链上指令内完成，所用输入由程序自己读取。后端并不提供点数，也无法谎报它。
• 运营方对推导不贡献任何输入 —— 不存在可供反复试算以求有利结果的服务器种子。
• 你的 nonce 必须被原样回传，因此同一笔下注不会被意外（或恶意）玩两次。
• 每次游戏都会公布全部推导输入与结果，因此历史上每一次掷骰任何人都可以重新计算。

• 打包并非完全可控 —— 决定交易确切落在哪个槽位的是网络，而不是发送方。
• 每一项输入都会公布，因此提交延迟的规律，以及整体胜率与所报概率之间的任何偏离，任何人都能用公开数据度量出来。系统性的滥用无法隐藏。

​

如何验证一次掷骰？

1. 在 Solana 区块浏览器上打开该笔下注的交易并读取事件字段（应用中的 Dice 界面会显示本次会话的公平性输入，你的下注记录中也有指向交易的链接）。
2. 重新计算 sha256("dice" ‖ slothash ‖ user ‖ nonce)，取前 16 字节按大端对 10,000 取模，再与事件中的 roll 对照。
3. 依据上面的公式核对胜负判定（押下方为 roll < target，押上方为 roll > target）与倍数。