【发布时间】:2021-12-10 08:02:36
【问题描述】:
我有一个与私人数据收集的实施相关的非常具体的查询,我在这里寻求专家的建议/建议。我们有一个在 Hyperledger Fabric 2.3.3 上运行的产品,该平台可以有任意数量的组织。例如,最初将有 4 个组织,下周将有 10 个组织加入网络。当这些组织开始相互交易时,问题就出现了。这些事务可以有许多对象,这些对象只需要在这些组织之间是私有的。为此,我们可以创建具有名称的私有数据集合:
collection_org1 collection_org2 collection_org3 集合_org1_org2 集合_org1_org3 集合_org1_org2_org3 collection_org2_org3
假设如果网络有 20 个组织作为参与者,那么会有多少个私有数据收集组合。
这是因为在给定时间,任何组织都可以与网络中的另一个组织或一系列组织开始交易。这里的问题是我们必须使用该模式创建大量私有数据集合并对其进行维护。
由于这个问题,我们删除了这个实现,并为每个组织使用了隐式私有数据收集。现在,如果有一个对象应该只与 org1、org2 和 org3 共享,则该对象被推送到collection_org1、collection_org2、collection_org3。我们使用设置 memberOnlyRead: false 和 memberOnlyWrite: false 来做到这一点,并在链码级别添加验证。此实现解决了上述问题,但产生了一个新问题。现在,我们想要实现关键级别的背书策略,这样如果 org1 更改了在 org2 和 org3 之间共享的私有对象,则 org1 必须从 org2 和 org3 对等方获得背书。这意味着对等节点将从他们自己的私有数据集合中读取对象,从而导致背书提案响应中的读取集不同,这进一步导致错误提示 read/write sets do not match。
例如,org1 在背书提案期间会从自己的私有数据集合collection_org1 中读取对象密钥:key1。以类似的方式,org2 将在背书期间从其自己的集合collection_org2 中读取相同的密钥,org3 也是如此。这会导致背书提案中出现不同的读取集。
我正在寻求以更好的方式实现整个功能的建议。请让我知道您的建议/建议。
【问题讨论】:
-
我相信您解决此问题的方法是从您的私人收藏中读取密钥,但从其他私人收藏中读取相同密钥的哈希值。
-
@david_k 即使在这种情况下,我也想验证私有数据哈希。为此,我将不得不调用函数
getPrivateDataHash(collection, key)。此函数从集合中读取结果相似的输出,即读取集将不同 -
我参与了一个类似的项目,该项目完成了您正在尝试做的事情,包括基于状态的背书,并认为这就是他们解决不同读/写集的方式。不幸的是,我现在无法确切知道它是如何解决的,但我认为这与读取您无法访问的集合的哈希值有关。
标签: hyperledger-fabric hyperledger hyperledger-fabric-sdk-js hyperledger-fabric2.2