我们可以依靠 Hyperledger Composer ACL 保护隐私吗？答案

【问题标题】：Can we rely on Hyperledger Composer ACL for privacy?我们可以依靠 Hyperledger Composer ACL 保护隐私吗？
【发布时间】：2017-11-25 00:55:11
【问题描述】：

Composer 提供了一些相当不错的 ACL 功能，具有足够的粒度来防止基于复杂业务逻辑的未经授权的访问。

我了解使用 composer 的 API，未经授权的用户将无法读取数据。

但是，如果用户使用 Fabric 的 API 会怎样？ composer 如何在 Fabric 级别实现其 ACL？业务网络是否共享单一渠道？在这种情况下，是否意味着任何参与者/节点都可以手动查看区块并查看私有数据？

所以我的问题是，我们是否可以依赖 Composer 并假设如果我们正确编写了 ACL 文件，那么数据是安全的？

【问题讨论】：

【解决方案1】：

我会这样说，Composer ACL 就像您在 Go 中编写 Fabric 链代码一样安全，并且包含对给定事务可以访问或更新哪些数据的显式条件检查。

数据未加密地存储在区块链上，并且存储在世界状态中（例如在 CouchDB 中）。因此，如果有人对磁盘上的文件或世界状态的 CouchDB 数据库具有本地访问权限，他们可以规避 ACL 规则。然而，这并非特定于 Composer，并且同样适用于用 Go 编写的 Fabric 链代码。

【讨论】：

所以我的意思是，假设参与者也将拥有网络中的节点，有没有办法防止他们未经授权的读取？是纯Fabric还是用Composer？
Fabric（和 Composer）支持通道的概念来控制数据在对等点之间的分布方式。例如。你可以在节点 A 和 B 之间有一个通道 1，在节点 A 和 C 之间有一个通道 2。它们基本上充当离散分类帐。如果数据分布在任何地方，那么各方都有字节（您正在分发要共享的数据）。您可以加密字节，但是您需要确保正确的各方拥有正确的私钥来解密数据。 AFAIK Fabric 还不能解决这个问题，所以你必须在带外处理。
@DanSelman 如果我们使用多个渠道来保护数据隐私，我们如何利用 Hyperledger Composer？由于作曲家仍然支持连接配置文件中的单个通道？或者，如果我们使用用户名/密码来保护这个 CouchDB 实例，这会是一个次要的解决方案吗？