大家好,谢谢您的帮助,我正在试着理解超级分类系统结构(和作曲家)的隐私功能。
应用程序场景在同一个网络中看到不同的销售者和送货人(例如,我从亚马逊带来了一个包裹(下订单),选择由A信使交付,出于成本原因,该信使决定与快递B合作,在为包裹到达客户的多站配送路径中进行单站配送)。对于这一订单,我希望亚马逊,快递A和B看到送货计划的细节,但我不希望其他销售者或送货人看到它。
现在,可以使用Composer ACL(或者类似地,在Go in Fabric中编写具有相同约束的链码)强制执行上述需求。唯一的问题是,其他交付方或卖方同行将能够完全访问磁盘上的世界状态和分类账记录,从而能够规避ACL的执行,并访问与其他组织协议相关的所有数据。
基于属性的访问控制( ABAC,Attribute Based )强制执行,使用注册证书属性在链码中有条件地区分访问和事务执行,具有相同的限制:我认为评估组织中不同角色(例如,管理员与正常用户的角色)可能是有用的。
然后,我们可以选择将“私有数据”(价格等)保存在分类账之外,使用不同的系统将它们存储在带外。这是可以的,但如果我们不使用渠道,其他组织将能够理解我们与谁做生意,以及订单和送货的大致数量。这些私有信息甚至可以使用Fabric 1.2,即专用数据集(PDC)插入到块链网络中,避免使用不同的外部系统,因为我们只需要指定哪些数据必须由哪个组织节点存储。总之,PDC配置数据只是共享的JSON文件,因此每个组织都可以了解您与谁做生意。
最后,我们有通道:我们可以为组实例化一个通道,用于这个订单和未来的订单,让它们成为参与者。这似乎没问题,因为订单数据现在只在通道对等点之间传播。考虑到配置和维护一个通道的管理负担,像我们这样有上千个卖家和快递商的巨大场景可能需要潜在的NxM2通道,有N个经销商和M个信使,这似乎是不可行的。
我还好吗?在你看来,还有其他的考虑吗?非常感谢
发布于 2019-02-06 07:00:09
我认为您在一定程度上是正确的,根据您的场景,您希望有两个组织(亚马逊和快递),在这个场景中,有3个对等点(一个来自亚马逊,两个来自快递A和快递B)共享数据--在这种情况下,Private 将是最好的选择(我曾经研究过HL,不能对ACL发表评论)。为什么?
另外,您提到的另一件事是,“无论如何,PDC数据都是共享的JSON配置文件,所以组织可以理解您与谁做生意。”Thats不是真正的,只有org/peer实例化链码才能访问集合-config.json文件,因为我们不对每个org/peer上的链码进行实例化,这样您就可以想到只有亚马逊可以访问json文件,从而获得关于“您与做生意的”的信息。
发布于 2019-02-09 12:00:53
谢谢您的友好答复,非常感谢。
让我们深入到一个更详细的场景,如果我错了,很抱歉:我只是在学习。假设我编写了一个链码来创建和保存分类账上的订单,每个分销商都可以使用它自己的订单(因此,安装在每个分销商内部对等服务器上)。亚马逊( Amazon )和沃尔玛( Walmart )都会使用这个链码,因为它可以实现相同的功能和目标。另外,交付过程的创建和更新也是标准化的链码,每个信使都要调用这些代码,因此它们被安装在每个信使组织中。
在这个简化的场景中,我们可能会有相同的链码可能安装在一个背书节点上,这取决于组织类型(经销商或信使),而不是特定的组织“名称”(标识符)。在这种情况下拥有PDC (例如仅针对送货费数据)仍然是可行的?据我所知,集合配置JSON被绑定到链码中,您必须在其中指定特定的组织对等点标识符:您是否需要为每个分销商指定不同的"order create“链码,以及为每个快递员创建不同的链码以使用PDC,使JSON只在授权的对等点上共享,同时指定对等点id?
如果我没有完全错误地理解前面的语句,那么在我看来,ACL机制(这与条件子句相同)(如果您不熟悉composer,则在链码中),它只允许指定的组织根据它们在事务中的角色或数据访问事务和分类账数据,这是在单个通道中保护相互竞争(但在随后的事务中可能合作的)参与者之间数据隐私的最佳方法。唯一的问题是,分类帐在所有组织对等点之间共享,而不能直接在对等磁盘上读取,从而避免了ACL数据访问控制。也许只有使用私有数据加密机制,只有特定的事务\数据涉众才能使用密钥,才能解决这个问题(或者使用不同的通道,但经销商和快递者之间的组合会使其变得非常困难)。
让我知道,如果你同意或如果你发现我错了,以及如何实际解决这个问题在超级分类账。非常感谢!一个
https://stackoverflow.com/questions/54544412
复制相似问题