这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 1344 天前的主题，其中的信息可能已经有所发展或是发生改变。
应用场景是这样的：
几个股东拥有一个网上商店，用户给某个商品下单付款后，款项按照约定好的比例，分摊给各个股东。这里有一个隐患，那就是这个网上商店是由单个大股东维护的，大股东明显可以通过操纵订单数量，减少分配给其他股东的收益。
现在假设其他股东没有权力审查网上商城的后台，但商城的前端代码则是开放的。
那么如何通过密码学，防止这种在后台操纵订单(甚至用户)的行为。
要做到这点并非不可能，因为虽然其他股东无法审查商城后台的代码，但整个商城的规则，比如运营规则，收费规则是可以约定的。并且其他股东是可以伪装成用户去试探的。
最终实现：每一个用户的付款，都能按照约定好的比例，分配给各个股东，并且各个股东可以验证这一点几乎 100%成立。(假设用户在 100000 的量级，并且不考虑可信第三方比如银行这种方式)
可以参考：应用密码学，实现授权下的匿名 ( /t/771869 ) 。里面用到了盲签名。
几个股东拥有一个网上商店，用户给某个商品下单付款后，款项按照约定好的比例，分摊给各个股东。这里有一个隐患，那就是这个网上商店是由单个大股东维护的，大股东明显可以通过操纵订单数量，减少分配给其他股东的收益。
现在假设其他股东没有权力审查网上商城的后台，但商城的前端代码则是开放的。
那么如何通过密码学，防止这种在后台操纵订单(甚至用户)的行为。
要做到这点并非不可能，因为虽然其他股东无法审查商城后台的代码，但整个商城的规则，比如运营规则，收费规则是可以约定的。并且其他股东是可以伪装成用户去试探的。
最终实现：每一个用户的付款，都能按照约定好的比例，分配给各个股东，并且各个股东可以验证这一点几乎 100%成立。(假设用户在 100000 的量级，并且不考虑可信第三方比如银行这种方式)
可以参考：应用密码学，实现授权下的匿名 ( /t/771869 ) 。里面用到了盲签名。
 |
1
sillydaddy OP “各个股东可以验证这一点几乎 100%成立”
这里“几乎 100%”的含义，类似零知识证明里面的“证明了命题以接近 100%的概率成立”。 |
 |
2
summic 2021-04-25 11:04:22 +08:00  2
伪需求，看似技术问题，背后其实是博弈，别折腾程序员了
|
|
3
sillydaddy OP |
 |
4
murmur 2021-04-25 11:11:37 +08:00 3
没有，除非请人查账对库存，既然收入不知道，但是卖出去多少商品是可以查出来的
我猜有人想吹区块链，区块链屁问题解决不了，这个系统很灵性的在上链时会出 bug，有些数据登不上去，怎么办 |
|
6
sillydaddy OP @murmur 查库存这个确实是一个方向。不过如果卖的是可以拷贝的软件之类呢？ 软件的库存不像实物商品，要想各个股东就商品的库存数量认识达成一致，还是需要密码学来处理。
|
 |
7
Vegetable 2021-04-25 11:34:40 +08:00
简简单单的检查订单号是否连续就完了。
|
 |
8
wy315700 2021-04-25 11:43:44 +08:00 1
游戏里这种场景挺常见的，发行和研发按照流水分成，但是钱是先到的发行账上的，但是代码是研发控制的，所以研发会植入一个第三方统计功能对支付进行统计。然后双方合同约定一个数值，对账的时候误差在这个数值内就问题不大。
|
|
9
sillydaddy OP |
 |
10
westoy 2021-04-25 12:41:40 +08:00 1
接入的支付接口那边不和本身系统的流水做人工对账么
而且随便改流水， 这是把税务局当空气么 这需求就不是正经的业务流程会产生的啊 |
|
11
sillydaddy OP @westoy
哎，真实的需求是这样的： 某人要制作一个收费的订阅，用户付月费或年费来订阅其信息。然后这个人可以接受别人的投稿，然后按照约定的比例拿到订阅费。并且自己拿到的订阅费是可以独立验证的，没有被那个人侵吞。 所以，哪里不是正经业务流程了？非要我说实话才行啊。 |
 |
12
futou 2021-04-25 12:54:29 +08:00
#10 说得对。订单数量对应着收入，如何只操控订单数量而不改变收入？这里操控订单是否相当于为了给其它股东少分钱，虚拟增加或减少收入？那直接控制成亏本好了，一分钱也不用出...
|
 |
13
rain2meng 2021-04-25 14:00:17 +08:00 via Android
账本公开，比如使用区块链做账本，用户的购买行为在区块链上
|
 |
14
Veneris 2021-04-25 14:06:49 +08:00 1
就是区块链啊，发币，只要交易过程都是在链上，就能做到公开透明。
合约都是公开且无法篡改的，用户使用代币通过合约下单，交易完成后合约再把代币分配给几个股东。 然后再去交易所打通代币与法币的交互就可以了。 区块链众筹的常见模式了。 |
 |
15
weimao 2021-04-25 14:07:13 +08:00 1
尝试用区块链的思想来解决这个问题。
1. 首先让系统为每个订单都生成一个唯一的编号，并且把编号返回给用户，这个编号的生成规则就是上一个订单编号的哈希值（类似区块链的区块哈希）。 2. 股东会伪装成用户去下少量的订单，然后把这些订单的哈希编号自己保存下来 3. 到了一个结算周期时，系统就公开这个周期内的订单总量、第一个订单哈希和最后一个订单哈希 4. 股东根据公开的信息，从第一个订单哈希开始计算，逐个计算出所有订单哈希值，然后检查自己之前试探的订单哈希是否存在。 这个协议下，我能想到的作弊方法就是大股东选取结算周期内的一个子集（必须是连续的）来公开，那么他作弊成功的概率就取决于他是否能把所有的试探订单都划到这个连续子集内。其他股东只要将试探订单的分布做一些特殊处理，就可以有效地避免作弊 |
 |
16
momocraft 2021-04-25 14:26:52 +08:00
这个需求和广告投放者是反着的?
广告投放者希望给了钱 广告被展示足够多次数 也许可以借鉴他们的做法 |
 |
17
cairnechen 2021-04-25 14:33:42 +08:00
@sillydaddy 橙光游戏工作室？
|
|
18
sillydaddy OP @rain2meng #13
@Veneris #14 用区块链+合约+代币，应该可以解决，就是感觉是牛刀小用了。另外还得考虑代币的价值有波动吧，结算的时候。 @weimao #15 仔细想了下，这个思路还是有漏洞。比如大股东以一定的概率，漏掉订单。然后把其他没有漏掉的单子，排列拼接起来，生成你说的一系列哈希。这种漏单能否被发现，就看小股东伪装用户下的订单数量了。具体的概率计算应该类似于“生日问题” ( https://zh.wikipedia.org/zh-hans/%E7%94%9F%E6%97%A5%E5%95%8F%E9%A1%8C ) |
|
19
westoy 2021-04-25 15:25:53 +08:00
@sillydaddy
那你描述有问题啊， 一个主要流量来自 google 分发， 并且靠挂 adsense 获取广告收入的网站很明显不能算 alphabet 的股东啊 至于能不能解决? 目前任何一个应用内购平台都有漏单， 广告联盟也会主动砍号砍量甚至被动偷量 很明显不能啊 因为你依托平台本身就是靠平台导量， 本身就是不对等的， 这种核心机制的诉求是没法谈的。 而你获取的信息也是依靠上游平台给你的， 也是不对等 如果不依靠平台导量， 那干脆直接绕过自己做平台就好了， 对吧 那么区块链能解决么? 假设， 怎么解决 google 主动砍 adsense 量或者被动偷量的问题? 首先， 和 google 协商引入区块链体系， 那可能直接就 OVER 了 其次， 怎么保障 google 不依靠算力优势对你发起 51%? 人家只要想 ，甚至可以对你发起 99%............ |
 |
20
3dwelcome 2021-04-25 15:42:45 +08:00
@sillydaddy "订单是可以被后台篡改的", 这被后台篡改的逻辑就有问题。
我们公司用的是集权方式，订单逻辑和 V2 发帖一样，一旦锁定后，操作者就没办法修改。最高权限只有一个管理员，可以去覆盖，但没办法修改。 或者临时授权给操作者，指定订单里，覆盖修改一次的权限。 |
 |
21
libook 2021-04-25 15:56:24 +08:00 1
如果每一笔交易过程都有可能作弊，比如实际订单情况钱跟记录到链上的信息不一致，这个问题不好用技术解决，因为暂时没有办法能 100%保证买家一定是通过统一的渠道交易的，比如运营股东完全可以开 2 个支付渠道，一个上链，另一个不上链，结算的时候只用链上数据结算，最终还是可以贪掉不上链的部分。同理，即便用代币或 NFT，运营股东依然可以开 2 个交易和发货渠道，然后仅用一个渠道的数据结算。
下意识感觉业务拆解，由多个股东分别掌控会好一些，但是这样依然不可靠，比如任何一个股东都有可能偷偷做其他股东的业务来贪掉营收，比如掌控发货的股东私自卖货，又比如掌控交易的股东少记金额。 感觉技术上无解，还不如其他股东派一些卧底在运营股东身边，但反过来想甚至可能出现运营股东清廉但其他股东通过内鬼偷钱的情况。 感觉这种偷钱是可以做到天衣无缝的，除非是国家机关利用一些非公开资源来调查取证，当然也有搞不定跨国业务的局限性。 |
 |
22
podel 2021-04-25 15:59:11 +08:00
楼上说得对。直接区块链账本。P2P，每个人手里面的账本能够制约其他人的账本。
|
 |
23
q197 2021-04-25 16:06:13 +08:00
用户提交购买请求时前端给每个股东的服务器发信息…… 滑稽
|
|
24
sillydaddy OP @libook #21 >“暂时没有办法能 100%保证买家一定是通过统一的渠道交易的” ， “运营股东完全可以开 2 个支付渠道，一个上链，另一个不上链，结算的时候只用链上数据结算，最终还是可以贪掉不上链的部分”
我考虑的都是前端都是公开的情形，可以对前端的代码进行审计。如果交易渠道可以有多个的话，那么这些渠道应该是公开可查的吧。如果是通过针对特定的用户提供“秘密的”交易渠道，那仅仅对前端做检查就不管用了。 不过，正像#10 楼提到的，这种应该用税务审计之类的就可以了吧。 |
|
25
weimao 2021-04-25 16:14:51 +08:00 1
@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 种情况，股东的应对方法就是需要持有一定量的测试用户在周期内进行试探性交易，并且在每个新的周期增加新的测试。这样可以随着周期不断迭代，增加股东“抓到作弊”的概率。 |
|
26
sillydaddy OP |
|
27
sillydaddy OP @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 的方法，我再消化一下。 |
|
28
murmur 2021-04-25 16:57:22 +08:00
|
 |
29
madadimy 2021-04-25 17:04:30 +08:00
微信支付有个分账的功能
|
|
30
sillydaddy OP @murmur #28
你从哪儿看出来我要解决整个“链条”的问题了？ 你说的跟这个主题讨论的根本不在一个范畴。 |
 |
31
baiyi 2021-04-25 17:17:48 +08:00
我觉得应该引入一个值得信任的第三方，否则很难从技术层面解决问题，在技术是掌握在某一方手中的情况下
|
 |
32
DeutschXP 2021-04-25 17:34:44 +08:00 via iPhone
合作协议里面规定，允许双方认可的第三方进行税务审计，或分享相应部分的审计数据。
如果审计都没发现问题，那你也别想那么多了，如果审计有问题，人家敢签字么？ |
|
33
DeutschXP 2021-04-25 17:41:39 +08:00 via iPhone 1
你也可以参考一下电影界包括好莱坞是怎么审计票房的。
本来就不应该只靠技术解决的问题，就不要想着技术解决了。就算你今天弄个方案出来，那也得技术没有缺陷，对方认可，法庭认可。但对方即使认可签字，肯定里面大抵会有一条，一旦发现算法技术缺陷，就不再认可接受。加密算法这一块，哪有人敢说是百分百安全可靠的？最多都只是现有技术条件下保证多少年内安全。 |
 |
34
kekxv 2021-04-25 17:57:25 +08:00 via iPhone
要求每个月提供银行流水或者对应系统的流水不就好了？
|
 |
35
lance6716 2021-04-25 18:35:13 +08:00 via Android
MPC 安全多方计算？
|
|
36
sillydaddy OP |
|
37
lance6716 2021-04-26 23:34:30 +08:00 via Android
|
 |
38
dallaslu 2021-04-27 11:58:10 +08:00
分账功能就是干这个的吧？
|
 |
39
fengmumu 2021-04-30 16:23:54 +08:00 via Android
首先。现成的就有分账系统，其次数据库能更改，意味着你改了用户侧数据就有问题了，就算你可以搞两个，你直接拉一开始收款方的流水对账就好了啊
|
 |
40
pjntt 2021-05-02 14:16:05 +08:00
有个疑问，楼主举的例子，虽然前端开放的，但平台是股东在管理方，虽然能你能看但能不能按你的想法改进，得看大股东意思。这种导流的合作，不都是大股东说的算吗？
|
|
41
sillydaddy OP @pjntt 对，只有大股东愿意才可以啊。
|
 |
42
israinbow 2021-05-04 22:15:51 +08:00
参照人民币发行, 每一张都有自己的唯一识别号, 且不可更改不可销毁, 连号发行
然后透明总收入 首先所有用户付款进入一个池, 从池中给每一个单位付款提供一个号, 先把号发给股东, 最后让大股东随意分配收益, 股东收益和号数对齐就能证明无损失 |
 |
43
cyrivlclth 2021-08-04 16:07:06 +08:00
换个思路想想，大股东在漏单的同时，怎么去保证股东伪装的用户下的单不会被漏掉
|
|
44
sillydaddy OP @cyrivlclth
可以参考#27 楼提到的。大概 50 个伪装订单就能保证漏单有极大的概率(>99%)被发现。 |
Select Language