@weimao #25
我用数据验证了一下你在#15 的方法，看系统如果故意随机漏掉用户的订单，会有多大的概率被发现。

如果将“间谍账号”生成的“间谍订单”的数量固定为 50 个，而系统要故意漏掉总订单数量的 10%，那么
- 实际 100 个订单，其中 50 个“间谍订单”，故意漏掉 10 个订单，不被发现的概率 < (50/100)^10=0.0009
- 实际 1000 个订单，其中 50 个“间谍订单”，故意漏掉 100 个订单，不被发现的概率 < (50/1000)^100=0.00592
- 实际 10000 个订单，其中 50 个“间谍订单”，故意漏掉 1000 个订单，不被发现的概率 < (50/10000)^1000=0.00665
- 实际 100000 个订单，其中 50 个“间谍订单”，故意漏掉 10000 个订单，不被发现的概率 < (50/100000)^10000=0.00673

所以，只要安排 50 个间谍订单，如果系统故意漏掉了 10%的订单，就能被以 99%以上的概率被发现。也就是说，如果大股东想通过故意漏掉 10%的订单来增加自己的收益(大概提高 11%的收益)，那么其他股东发现其作弊的概率高达 99%以上。
这种随机插入“间谍订单”的方法，配合你说的哈希值编号，可以很容易发现大股东的作弊。

你说的 merkel tree 的方法，我再消化一下。

@q197 #23
对对，我想的一种方法就是这个，哈哈，前端的代码是可以审查的。。不过应该需要配合一定的加密签名、然后用户要支持匿名，否则服务器可以针对不同的登录用户提供“差别前端代码”，你懂的。用户匿名的方法，其实可以用“授权下的匿名”( /t/771869 ) 这种。

@libook #21 >“暂时没有办法能 100%保证买家一定是通过统一的渠道交易的” ， “运营股东完全可以开 2 个支付渠道，一个上链，另一个不上链，结算的时候只用链上数据结算，最终还是可以贪掉不上链的部分”

我考虑的都是前端都是公开的情形，可以对前端的代码进行审计。如果交易渠道可以有多个的话，那么这些渠道应该是公开可查的吧。如果是通过针对特定的用户提供“秘密的”交易渠道，那仅仅对前端做检查就不管用了。

不过，正像#10 楼提到的，这种应该用税务审计之类的就可以了吧。

@rain2meng #13
@Veneris #14
用区块链+合约+代币，应该可以解决，就是感觉是牛刀小用了。另外还得考虑代币的价值有波动吧，结算的时候。

@weimao #15
仔细想了下，这个思路还是有漏洞。比如大股东以一定的概率，漏掉订单。然后把其他没有漏掉的单子，排列拼接起来，生成你说的一系列哈希。这种漏单能否被发现，就看小股东伪装用户下的订单数量了。具体的概率计算应该类似于“生日问题”
( https://zh.wikipedia.org/zh-hans/%E7%94%9F%E6%97%A5%E5%95%8F%E9%A1%8C )

@westoy
哎，真实的需求是这样的：

某人要制作一个收费的订阅，用户付月费或年费来订阅其信息。然后这个人可以接受别人的投稿，然后按照约定的比例拿到订阅费。并且自己拿到的订阅费是可以独立验证的，没有被那个人侵吞。

所以，哪里不是正经业务流程了？非要我说实话才行啊。

@Vegetable #7 订单是可以被后台篡改的
@wy315700 #8 学习了，研发可以控制代码，发行可以控制收入。不过主题里的大股东既控制收入又控制代码。

@murmur 查库存这个确实是一个方向。不过如果卖的是可以拷贝的软件之类呢？ 软件的库存不像实物商品，要想各个股东就商品的库存数量认识达成一致，还是需要密码学来处理。

@summic
可以看一下主题里提到的“授权下的匿名”，感叹一下密码学的应用可以达到怎样的高度。
怎么会是伪需求呢？

“各个股东可以验证这一点几乎 100%成立”
这里“几乎 100%”的含义，类似零知识证明里面的“证明了命题以接近 100%的概率成立”。

@wipbssldo
去线下店对比了一下，应该是机器屏幕的问题，或者是哪里配置的有问题，店里的机器没有问题。不过确实找不到哪里的配置有问题，因为之前用的默认配置就有问题。

@SorryChen 重影和光晕，应该是眼睛散光吧。我没有这种情况，我说的“光晕”在附言里面解释了，就是文字显得比周围格外的亮。

@wipbssldo
不只是 VSCode 的问题啊，整个系统、还有所有其他软件都是这样。

@lostberryzz
你说的这个不是主要的问题。问题跟具体的“主题”没关系，是这台笔记本整个表现就是那样——白天虽然问题没暗光条件那么严重，但相比其他的显示器，仍然让人不舒服。

@no1xsyzy
对，就是切断“使用记录”与“注册记录”的联系。

比如 10000 个用户注册并使用服务，服务提供方知道这 10000 个注册用户的注册信息(包括付款信息)，也知道这 10000 个用户各自的使用过程信息(比如浏览记录)。但没办法建立注册信息与使用过程信息的一对一关系。

如果主题中的第 3 条成立，那么服务提供方可以把用户准确地区分为 10000 个，各自画像，但画像信息与注册信息是解除关联的。如果主题中的第 3 条不成立，也就是说服务方无法确定用户由同一个授权码生成的不同登录码实际上是同一个授权码生成的，那么服务方甚至都不能确定这 10000 个用户画像。

@chonger 看不了是指什么呢？ 我是能看清，但就是感觉白字比较亮。

@xuegy 不要吓我啊。我同事也看了我的本儿，也说白色有点靓。。

@gps949 #14 > “一个对于服务方来说不该知道个人信息、对于结算方来说不该知道购买服务（按国内审查来说这个其实也是该知道的）。按上述过程并不会透露啊？”

可以再看一下主题里面的前 2 条，把授权码和登录码分开，主要是让服务方没办法将用户注册(付款)得到授权时暴露的信息，与用户使用服务时的信息一一关联起来。

举个例子，xiaoming 用 [email protected] 注册了一个服务，付款后，服务方得到了 [email protected] 这个用户名与付款信息。同时，xiaoming 使用服务时，比如看 iqiyi 视频，xiaoming 所有的浏览记录都与这个 [email protected] 关联起来了。按照正常的逻辑，[email protected] 和他付款时暴露的少量信息，并不会暴露他的实名信息。但考虑到
1. 国内都是实名制的
2. 服务商作出一些“额外的努力”，有没有可能将 [email protected] 以及付款信息，与 xiaoming 关联起来呢？
这些都会危及用户的隐私。多平台的话，效果更甚。

@q9OxQg
@Jirajine
在 v 站见过迷雾 tong，但没想到它采用了“盲签名”这样的技术，感觉这点确实挺好的。

@hahastudio 你这么说好像也没错。。用户名本来也是匿名的，不过关联到付费信息就不是匿名的了。