@
sillydaddy 确实有漏洞,尝试改进一下。既然你提到前端的代码是开放的,那我就把前端看成是一个诚实的参与者。
1. 订单哈希的生成规则不变
2. 系统需要把所有的订单哈希构建成一棵 Merkle Tree,这棵树是动态增长的
3. 每次生成新的订单,系统需要更新 Merkle Tree,然后将更新后的 Merkle Root 、当前订单哈希对应的 Merkle 验证路径发给前端
4. 前端验证 Merkle 路径是否有效,并且在前端缓存这次订单哈希
5. 用户下一次提交新的订单时,需要再次向前端请求上一个缓存的订单哈希在当前 Merkle Tree 中的验证路径
6. 前端验证 Merkle 路径是否有效,并且检查这条路径和第 4 步得到的路径是否在同一棵 Merkle Tree 中
7. 到一个验证周期后,系统公开订单总量,首末订单哈希,此外,每个用户还可以就任意订单请求当前 Merkle Tree 下的验证路径
8. 跟之前的协议一样,股东先验证哈希关系,然后验证其持有测试用户的历史订单的 Merkle 路径,这里的测试用户可以不需要在当前周期内有交易行为,只要之前任意时间有过历史订单即可
该协议下,系统有两种作弊的方法
1. 如果系统随机地漏掉用户的订单,那么每当一个用户第一次被漏掉后,就无法进行下一次交易(前端保证)
2. 系统固定一部分用户永久地进行特殊处理,将这些用户的订单额外生成一棵 Merkle Tree,不被计入交易。
针对第 2 种情况,股东的应对方法就是需要持有一定量的测试用户在周期内进行试探性交易,并且在每个新的周期增加新的测试。这样可以随着周期不断迭代,增加股东“抓到作弊”的概率。