加密协议
Commit / Reveal (提交/揭示)
对于 Round t，用户 i 持有私有秘密 s_i ∈ {0,1}^128，选择答案 b_i ∈ {0,1} 并发布：
其中 ‖ 表示拼接操作，round_t 是公开唯一的 Round (回合) 标识符。
在 Reveal (揭示) 阶段，用户 i 广播 (s_i, b_i)。Round Engine (回合引擎) 及任何第三方验证者计算 HMAC-SHA256(s_i ‖ round_t, b_i) 并检查其是否与先前发布的 c_i 匹配。不匹配的揭示将被拒绝；未揭示者将被淘汰出该 Round，但其 Commit (提交) 仍保留在 Merkle Root (默克尔根) 中以供审计。
为何使用 HMAC 而非普通哈希
普通提交 H(s_i ‖ b_i) 容易受到两种攻击：
- 彩虹预计算攻击。如果
s_i较短（移动端用户体验限制我们使用 ≤16 字节的设备绑定随机数），攻击者可以针对秘密空间预计算H(s ‖ 0)和H(s ‖ 1)的查找表，从而在揭示前破解提交。 - 跨 Round 重放攻击。如果没有 Round 绑定，在 Round
t中有效的提交可能被重放作为 Roundt' ≠ t中的证据。
HMAC 使用适当大小的密钥（此处为 128 位）并结合 Round 绑定（将 round_t 拼接到密钥消息中）消除了这两种攻击。在标准假设下，HMAC 构造的伪随机性确保：没有 s_i 的情况下，攻击者区分 b_i = 0 和 b_i = 1 的优势可忽略不计。
s_i 的来源
每个用户设备在进入 Round 时，通过浏览器的 crypto.getRandomValues(new Uint8Array(16)) 生成 s_i。该值仅在 Round 持续期间存储在 WebApp 的会话存储中。Reveal 阶段结束后即被丢弃。整个过程不涉及用户输入的密码。
对于在 Round 中途清除会话的用户，该 Round 将被视为放弃（他们无法揭示已不再持有密钥的提交）。Reputation Score (信誉评分) 将受到小幅负面更新。
Round Merkle Root (回合默克尔根)
在 Settle (结算) 阶段，引擎计算：
该根每 24 小时排队批量结算到 TON 网络。TON 上的一笔交易可以提交约 5,760 个 Round 根（每 60 秒一个 × 86,400 / 60 / 15 摊销）。
任何参与者都可以从引擎获取 Merkle 证明，并针对链上根验证自己的包含情况，无需信任引擎。
争议窗口
24 小时的争议窗口允许链上挑战：用户提交 Merkle 证明，显示链上根与链下引擎声明不匹配。如果挑战成功，该回合将被作废并重新结算；运营方需向 Treasury (国库) 支付 1,000 $POP 罚款。未被挑战的根将最终确定。
Reputation Score (信誉评分)
r_i ∈ [0, 1] 是对用户诚实度的贝叶斯估计，每个 Round 更新一次：
其中 λ(o_i^{(t)}) 是基于观测数据（参与情况、按时揭示、偏离少数派概率、异常标记）的似然函数。初始 r_i = 0.5（无信息先验）。
Reputation 会因不活跃而衰减，衰减率为 δ = 0.01 / 天。Reputation 不能超过 0.99（认知谦逊）或低于 0.01（允许恢复）。
在结算中，Reputation Score 乘以 Trust Ladder (信任阶梯) 乘数：
形式化安全论证
在假设 HMAC-SHA256 是伪随机函数 (PRF) 且 s_i 均匀随机且对攻击者未知的前提下，没有高效攻击者能够：
- 以不可忽略的优势区分
b_i = 0和b_i = 1对应的提交c_i = HMAC(s_i ‖ round_t, b_i)。（隐藏性。） - 找到
(s'_i, b'_i)≠(s_i, b_i)使得HMAC(s'_i ‖ round_t, b'_i) = c_i。（绑定性，基于 HMAC 的抗碰撞性。） - 在不与 DRAND 和 TON-VRF 验证者集共谋的情况下预测下一轮种子。（参见 Oracle & Randomness。）
这些是公平的 Commit / Reveal 协调游戏所需的三个属性。该协议不需要任何额外的密码学假设。
审计与开源
Round Engine 及验证逻辑以 MIT 许可证开源。代码仓库位于 github.com/cashpop-protocol/round-engine。Trail of Bits 的全面审计计划在第二阶段（2026 年第四季度）进行。