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

[sillydaddy]

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

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

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

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

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

[sillydaddy]

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

[summic]

伪需求，看似技术问题，背后其实是博弈，别折腾程序员了

[sillydaddy]

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

[murmur]

没有，除非请人查账对库存，既然收入不知道，但是卖出去多少商品是可以查出来的

我猜有人想吹区块链，区块链屁问题解决不了，这个系统很灵性的在上链时会出 bug，有些数据登不上去，怎么办

[dqzcwxb]

@murmur #4 区块链是未来,区块链解决所有问题,利好 btc!

[sillydaddy]

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

[Vegetable]

简简单单的检查订单号是否连续就完了。

[wy315700]

游戏里这种场景挺常见的，发行和研发按照流水分成，但是钱是先到的发行账上的，但是代码是研发控制的，所以研发会植入一个第三方统计功能对支付进行统计。然后双方合同约定一个数值，对账的时候误差在这个数值内就问题不大。

[sillydaddy]

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

[westoy]

接入的支付接口那边不和本身系统的流水做人工对账么

而且随便改流水， 这是把税务局当空气么

这需求就不是正经的业务流程会产生的啊

[sillydaddy]

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

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

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

[futou]

#10 说得对。订单数量对应着收入，如何只操控订单数量而不改变收入？这里操控订单是否相当于为了给其它股东少分钱，虚拟增加或减少收入？那直接控制成亏本好了，一分钱也不用出...

[rain2meng]

账本公开，比如使用区块链做账本，用户的购买行为在区块链上

[Veneris]

就是区块链啊，发币，只要交易过程都是在链上，就能做到公开透明。
合约都是公开且无法篡改的，用户使用代币通过合约下单，交易完成后合约再把代币分配给几个股东。
然后再去交易所打通代币与法币的交互就可以了。
区块链众筹的常见模式了。

[weimao]

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

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

[momocraft]

这个需求和广告投放者是反着的?
广告投放者希望给了钱 广告被展示足够多次数
也许可以借鉴他们的做法

[cairnechen]

@sillydaddy 橙光游戏工作室？

[sillydaddy]

@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]

@sillydaddy

那你描述有问题啊， 一个主要流量来自 google 分发， 并且靠挂 adsense 获取广告收入的网站很明显不能算 alphabet 的股东啊

至于能不能解决?

目前任何一个应用内购平台都有漏单， 广告联盟也会主动砍号砍量甚至被动偷量

很明显不能啊

因为你依托平台本身就是靠平台导量， 本身就是不对等的， 这种核心机制的诉求是没法谈的。

而你获取的信息也是依靠上游平台给你的， 也是不对等

如果不依靠平台导量， 那干脆直接绕过自己做平台就好了， 对吧

那么区块链能解决么?

假设， 怎么解决 google 主动砍 adsense 量或者被动偷量的问题?

首先， 和 google 协商引入区块链体系， 那可能直接就 OVER 了

其次， 怎么保障 google 不依靠算力优势对你发起 51%? 人家只要想 ，甚至可以对你发起 99%............

[3dwelcome]

@sillydaddy "订单是可以被后台篡改的", 这被后台篡改的逻辑就有问题。

我们公司用的是集权方式，订单逻辑和 V2 发帖一样，一旦锁定后，操作者就没办法修改。最高权限只有一个管理员，可以去覆盖，但没办法修改。

或者临时授权给操作者，指定订单里，覆盖修改一次的权限。