Hyperledger fabric Hyperledger结构和编写器隐私支持-完整场景

大家好，提前感谢你们的帮助， 我试图了解hyperledger结构（和编写器）的隐私功能

应用场景在同一网络中看到不同的卖家和发货人（例如，我从亚马逊带来了一个包裹（下了订单），选择由快递员发货，出于成本原因，快递员决定合作（副代表）通过快递员B在多站交付路径中进行单站运送，计划包裹到达客户）。对于这张订单，我希望亚马逊、快递员A和B看到发货计划的详细信息，但我不希望其他卖家或发货人看到

现在，可以使用Composer acl强制执行上述要求（或者，类似地，在Go-in-Fabric中编写具有相同约束的链码）。唯一的问题是，其他交付方或卖方对等方可以完全访问磁盘上的世界状态和分类账历史记录，这样他们就可以绕过ACL强制，访问与其他组织的协议相关的所有数据

ABAC（基于属性的访问控制）实施，使用注册证书属性有条件地区分链码中的访问和事务执行，具有相同的限制：我认为主要用于评估组织中的不同角色（例如，管理员和普通用户）

然后我们可以选择将“私人数据”（价格等）保留在分类账之外，使用不同的系统将其存储在带外。这没关系，但如果我们不使用渠道，其他组织将能够了解我们与谁做生意以及订单和交货的大致数量。甚至可以从Fabric 1.2开始，使用私有数据收集（PDC）将这些私有信息插入区块链网络，避免使用不同的外部系统，因为我们可以只指定哪些数据必须由哪个组织存储。总之，PDC配置数据只是共享的JSON文件，所以每个组织都可以了解您与谁做生意

最后，我们有频道：我们可以为Amazon Courier a-Courier B组实例化一个频道，用于此订单以及将来将其作为参与者的订单。这似乎没问题，因为订单数据现在只在渠道对等方之间传播。考虑到配置和维护渠道的管理负担，像我们这样一个巨大的场景，即我们有数千名卖家和快递员，可能需要潜在的NxM2渠道，其中N名经销商和M名快递员，这似乎不可行

我明白了吗？你认为还有其他考虑吗？

---

非常感谢

我认为你部分是对的，根据你的场景，你需要两个组织（Amazon和Courier），也就是说，3个对等方（1个来自Amazon，2个来自Courier A和Courier B）共享数据，在这种情况下，私人数据收集将是最好的选择（我在HL fabric上工作过，不能对ACL发表评论）。为什么?

您不希望整个业务逻辑有所不同，只希望数据的一部分是私有的。因此，如果您创建一个新频道，您必须安装一个新的链码（或再次安装相同的链码）

PDC允许您希望所有渠道参与者在保持部分数据私有的同时查看事务的用例

提及

您提到的另一件事是，“无论如何，PDC数据是共享的JSON配置文件，所以组织可以了解您与谁做生意。”

---

这不是真的，只有实例化链码的组织/对等方可以访问collections-config.json文件，因为我们不会在每个组织/对等方上实例化链码，因此您可以认为只有Amazon可以访问json文件，从而访问有关“您与谁做生意的信息”谢谢您的友好回答，非常感谢

让我们深入到一个更详细的场景中，如果我错了，请原谅：我只是在学习。假设我编写了一个链码，在分类账上创建并保存一个订单，每个经销商都可以使用它来处理自己的订单（因此，安装在每个经销商的同级客户上）。亚马逊和沃尔玛都会使用这个链码，因为它可以实现相同的功能和目标。 此外，交付流程的创建和更新是每个快递员调用的标准化链码，因此它们安装在每个快递组织上

在这个简化的场景中，我们可能会在背书节点上安装相同的链码，这仅取决于组织类型（分销商或快递公司），而不是特定的组织“名称”（标识符）。在这种情况下，使用PDC（例如，仅用于交付费用数据）仍然可行吗？据我所知，集合配置JSON绑定到链码，您必须在其中指定特定的组织对等标识符：然后，您是否需要为每个分销商提供不同的“订单创建”链码，以及为每个快递员提供不同的“交付流程创建”链码，以使用PDC，仅在授权对等方上共享JSON，并且，同时，指定对等id

如果我对前面的陈述没有完全错误，那么在我看来，ACL机制（与链码中的条件子句If\then相同，如果您不熟悉composer），只允许指定的组织根据其在交易中的角色或数据访问交易和分类账数据，是保护单一渠道中竞争（但在后续交易中可能是合作）参与者之间数据隐私的最佳方式。 唯一的问题是分类账在所有组织pee之间共享