大家好，在此先感谢您的帮助， 我试图了解超级账本结构（和作曲家）的隐私功能。
应用场景看到同一网络中的不同卖方和交付者（例如，我从亚马逊带来了一个包裹（下了订单），由A快递员选择交付，出于成本原因，决定与快递公司B合作（分委托）在计划将包裹到达客户的多站交付路径中的单站）。对于此订单，我希望亚马逊，快递A和B看到交货计划的详细信息，但我不希望其他卖方或交货者看到它。
现在，可以使用 Composer ACL （或类似地，在Fabric中的Go中编写具有相同约束的链码）来实施上述要求。唯一的问题是，其他交付者或卖方对等方将完全有权访问磁盘上的世界状态和分类帐历史记录，以便他们可以规避ACL的执行并访问与其他组织的协议有关的所有数据。
ABAC（基于属性的访问控制）强制，使用注册证书属性有条件地区分链码中的访问和事务执行，具有相同的局限性：我认为主要用于评估不同角色可能有用在组织中（例如普通用户的管理员）。
然后，我们可以选择将“私人数据”（价格等）保留在分类帐之外，使用其他系统将其存储在带外。可以，但是如果我们不使用渠道，其他组织也可以了解与我们进行业务往来的人以及大约的订单和交付数量。从Fabric 1.2开始，甚至可以使用私有数据集合（PDC），将此私有信息插入到区块链网络中，避免使用其他外部系统，因为我们可以仅指定必须存储的数据仅由哪个组织对等。无论如何，PDC配置数据只是共享的JSON文件，因此每个组织都可以了解与您进行业务往来的人。
最后，我们有了 Channels ：我们可以为Amazon-Courier A-Courier B组实例化一个通道，以用于该订单以及将来将其用作参与者的订单。这似乎可以，因为订单数据现在仅在通道对等方之间分发。考虑到配置和维护渠道的管理负担，像我们这样的大场景（其中有成千上万的卖方和快递公司）可能需要NxM2渠道，其中有N个转售商，M个快递公司，这似乎不可行。
我没事吧？您认为还需要考虑其他因素吗？ 非常感谢
答案 0 :(得分：1)
根据您的情况，您想要两个组织（Amazon和Courier），并且在这种情况下，要让3个对等方（1个来自Amazon，2个来自Courier A和courier B）共享数据，我认为您是部分正确的strong>私有数据收集将是最好的选择（我曾经在HL架构上工作，无法在ACL上发表评论）。为什么？
推荐When to use a collection within a channel vs. a separate channel
您提到的另一件事是：“无论如何，PDC数据是共享的JSON配置文件，因此组织可以了解与您进行业务往来的人。” 那不是真的，只有实例化chaincode的组织/同伴可以访问collections-config.json文件，因为我们没有实例化每个组织/同级上的链码，因此您只能想到亚马逊有权访问json文件，从而获得有关“ 您与之开展业务的人”
的信息答案 1 :(得分：0)
非常感谢您的好意。
让我们深入探讨更详细的情况，如果我错了，抱歉：我只是在学习。假设我编写了一个链式代码来在分类帐上创建和保存订单，每个转销商都可以使用该链结单来处理自己的订单（因此，安装在每个转销给对等方的转销商上）。亚马逊和沃尔玛都将使用此链码，因为对于相同的功能和目标而言，这是可以的。 此外，交货过程的创建和更新都是标准化的链码，每个快递员都将调用它们，因此它们被安装在每个快递组织中。
在这种简化的情况下，我们将有可能仅在组织类型（代理商或快递公司）上而不是在特定组织“名称”（标识符）上将相同的链码安装在认可节点上。在这种情况下使用PDC（例如仅用于运费数据）仍然可行吗？据我了解，集合配置JSON已绑定到链码，并且您必须在其中指定特定的组织对等标识符：那么您是否需要为每个经销商使用不同的“订单创建”链码以及为每个经销商使用不同的“交付过程创建”链码快递员使用PDC，让JSON仅在授权对等方之间共享，并同时指定对等方ID？
如果我对前面的陈述不是完全错误，在我看来，ACL机制（如果您不熟悉作曲家，则与条件子句if \ then相同，如果您不熟悉作曲者，则为条件子句），该机制仅允许指定的组织根据交易或分类账数据在交易中的角色或与数据一起访问交易和分类账数据，是保护单个通道中竞争（但在后续交易中可能合作）参与者之间的数据隐私的最佳方法。 唯一的问题是，分类帐在所有组织对等方之间共享，因此可以在对等磁盘上直接读取该分类帐，从而规避了ACL数据访问控制。也许只有使用专用数据加密机制，并且密钥仅对特定的交易\数据涉众可用，才能解决此问题（或使用不同的渠道，但是转售商和快递公司之间的结合会非常困难）。
让我知道您是否同意或是否发现我错了，以及如何在超级账本中实际解决此问题。 非常感谢！ A