能不能应用密码学，解决订单操纵，实现收益分摊？

[sillydaddy]

应用场景是这样的：
几个股东拥有一个网上商店，用户给某个商品下单付款后，款项按照约定好的比例，分摊给各个股东。这里有一个隐患，那就是这个网上商店是由单个大股东维护的，大股东明显可以通过操纵订单数量，减少分配给其他股东的收益。

现在假设其他股东没有权力审查网上商城的后台，但商城的前端代码则是开放的。

那么如何通过密码学，防止这种在后台操纵订单(甚至用户)的行为。
要做到这点并非不可能，因为虽然其他股东无法审查商城后台的代码，但整个商城的规则，比如运营规则，收费规则是可以约定的。并且其他股东是可以伪装成用户去试探的。

最终实现：每一个用户的付款，都能按照约定好的比例，分配给各个股东，并且各个股东可以验证这一点几乎 100%成立。(假设用户在 100000 的量级，并且不考虑可信第三方比如银行这种方式)

可以参考：应用密码学，实现授权下的匿名 ( /t/771869 ) 。里面用到了盲签名。

[libook]

如果每一笔交易过程都有可能作弊，比如实际订单情况钱跟记录到链上的信息不一致，这个问题不好用技术解决，因为暂时没有办法能 100%保证买家一定是通过统一的渠道交易的，比如运营股东完全可以开 2 个支付渠道，一个上链，另一个不上链，结算的时候只用链上数据结算，最终还是可以贪掉不上链的部分。同理，即便用代币或 NFT，运营股东依然可以开 2 个交易和发货渠道，然后仅用一个渠道的数据结算。

下意识感觉业务拆解，由多个股东分别掌控会好一些，但是这样依然不可靠，比如任何一个股东都有可能偷偷做其他股东的业务来贪掉营收，比如掌控发货的股东私自卖货，又比如掌控交易的股东少记金额。

感觉技术上无解，还不如其他股东派一些卧底在运营股东身边，但反过来想甚至可能出现运营股东清廉但其他股东通过内鬼偷钱的情况。

感觉这种偷钱是可以做到天衣无缝的，除非是国家机关利用一些非公开资源来调查取证，当然也有搞不定跨国业务的局限性。

[podel]

楼上说得对。直接区块链账本。P2P，每个人手里面的账本能够制约其他人的账本。

[q197]

用户提交购买请求时前端给每个股东的服务器发信息…… 滑稽

[sillydaddy]

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

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

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

[weimao]

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

[sillydaddy]

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

[sillydaddy]

@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 的方法，我再消化一下。

[murmur]

@sillydaddy 你想的太简单，商场如战场，技术能解决问题也不至于抢公章下毒药了

这东西如果入库就是吃了回扣的呢

[madadimy]

微信支付有个分账的功能

[sillydaddy]

@murmur #28
你从哪儿看出来我要解决整个“链条”的问题了？ 你说的跟这个主题讨论的根本不在一个范畴。

[baiyi]

我觉得应该引入一个值得信任的第三方，否则很难从技术层面解决问题，在技术是掌握在某一方手中的情况下

[DeutschXP]

合作协议里面规定，允许双方认可的第三方进行税务审计，或分享相应部分的审计数据。
如果审计都没发现问题，那你也别想那么多了，如果审计有问题，人家敢签字么？

[DeutschXP]

你也可以参考一下电影界包括好莱坞是怎么审计票房的。
本来就不应该只靠技术解决的问题，就不要想着技术解决了。就算你今天弄个方案出来，那也得技术没有缺陷，对方认可，法庭认可。但对方即使认可签字，肯定里面大抵会有一条，一旦发现算法技术缺陷，就不再认可接受。加密算法这一块，哪有人敢说是百分百安全可靠的？最多都只是现有技术条件下保证多少年内安全。

[kekxv]

要求每个月提供银行流水或者对应系统的流水不就好了？

[lance6716]

MPC 安全多方计算？

[sillydaddy]

@DeutschXP #33 这个问题不在“不应该靠技术解决”的范围内吧
@lance6716 #35 不清楚安全多方计算能不能做到。在这个例子里，多方要计算的目标是什么呢？

[lance6716]

@sillydaddy 各个股东分摊到的收益。
本站现与 Google 达成深度合作！只需要在 Google.com 中搜索“安全多方计算”即可学习相关知识

[dallaslu]

分账功能就是干这个的吧？

[fengmumu]

首先。现成的就有分账系统，其次数据库能更改，意味着你改了用户侧数据就有问题了，就算你可以搞两个，你直接拉一开始收款方的流水对账就好了啊

[pjntt]

有个疑问，楼主举的例子，虽然前端开放的，但平台是股东在管理方，虽然能你能看但能不能按你的想法改进，得看大股东意思。这种导流的合作，不都是大股东说的算吗？