- 把每个题目中的内容隐藏一部分
- 这部分内容信息量不大，但是对正确解题影响很大，比如一些数量值等
- 考生必须戴耳机，通过鼠标点击听到这些关键部分

支持一下

@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 种情况，股东的应对方法就是需要持有一定量的测试用户在周期内进行试探性交易，并且在每个新的周期增加新的测试。这样可以随着周期不断迭代，增加股东“抓到作弊”的概率。

尝试用区块链的思想来解决这个问题。
1. 首先让系统为每个订单都生成一个唯一的编号，并且把编号返回给用户，这个编号的生成规则就是上一个订单编号的哈希值（类似区块链的区块哈希）。
2. 股东会伪装成用户去下少量的订单，然后把这些订单的哈希编号自己保存下来
3. 到了一个结算周期时，系统就公开这个周期内的订单总量、第一个订单哈希和最后一个订单哈希
4. 股东根据公开的信息，从第一个订单哈希开始计算，逐个计算出所有订单哈希值，然后检查自己之前试探的订单哈希是否存在。

这个协议下，我能想到的作弊方法就是大股东选取结算周期内的一个子集（必须是连续的）来公开，那么他作弊成功的概率就取决于他是否能把所有的试探订单都划到这个连续子集内。其他股东只要将试探订单的分布做一些特殊处理，就可以有效地避免作弊

用 helm 管理 k8s 上的所有配置文件
持续集成：bitbucket+drone——git tag 触发 docker build
持续部署：drone 配置 pipeline 实现 docker build 成功后触发 helm 配置更新、k8s 部署