Hyperledger Fabric 动态多组织场景下私有数据集合优化方案咨询

本方案针对Fabric 2.3.3版本下，动态新增组织场景中私有数据集合爆炸、多组织背书读写集不匹配的痛点设计，共有3种可落地的实现方案：

方案1：单主集合存储+多组织哈希索引方案 #

该方案改造成本最低，适配现有架构的最小改动逻辑如下：

• 每一份需要多组织共享的私有数据，全量内容仅存到交易发起方的隐式私有集合中，比如org1发起的共享给org2、org3的数据，全量只写_implicit_org_org1集合的对应key
• 同时在org2、org3的隐式私有集合中，仅写入该数据的哈希值、主集合归属、版本号三个字段，key和主集合的key保持一致
• 该方案保留当前memberOnlyRead: false的配置，非集合成员组织可正常读取集合内的私有数据，链码层做最终权限校验
• 背书逻辑统一调整为：所有参与背书的组织，都从主集合（即数据发起方的隐式集合）读取全量私有数据做校验，不需要读自身集合的索引数据
• 链码层新增校验逻辑：修改数据时，先校验请求方是否在该数据的权限列表中，同时验证各参与方本地索引的哈希值和主集合数据哈希一致，防止篡改

优点：

• 完全避免集合数量爆炸，集合数量和组织数量完全一致
• 读集来源统一，不会出现read/write sets do not match报错
• 不需要改动原有链码的核心权限校验逻辑，改造成本极低

缺点：

• 数据发起方节点需要承担所有背书请求的私有数据读取压力，适合单交易参与组织不超过10个的场景

方案2：动态私有数据集合复用方案 #

Hyperledger Fabric 2.0及以上版本支持链码调用时动态创建私有数据集合，不需要预先在链码打包时定义，可按业务维度而非组织组合维度创建集合：

• 每发起一笔多组织共享的交易，先按业务唯一ID生成集合名称，比如collection_{业务流水号}
• 动态创建集合时，仅将本次交易的参与组织设置为集合的成员，memberOnlyRead和memberOnlyWrite都设为true，背书策略直接设置为集合所有成员的多数签名即可
• 数据仅存到这个动态创建的集合中，所有参与方背书时都从同一个集合读取数据，读集完全一致
• 闲置超过一定时间的历史集合可以直接调用链码接口删除，降低运维成本

优点：

• 集合数量和业务交易数量挂钩，不会出现组合爆炸的问题，20个组织的场景下集合数量远低于组织组合模式
• 原生支持集合级的背书策略，不需要自行实现键级策略，读写集天然一致

缺点：

• 需要实现动态集合的生命周期管理逻辑，包括创建、过期清理
• 链码需要申请创建/删除集合的相关权限

方案3：私有数据状态哈希共识方案 #

如果业务场景必须要把全量数据存在每个参与方的本地集合，可以通过哈希共识的方式绕过读写集校验的问题：

• 背书阶段各组织读取自身集合的对应数据后，不直接返回数据内容到读写集，仅返回数据的哈希值和版本号
• 链码层统一校验所有参与方返回的哈希值完全一致，校验通过后，在写集里统一写入所有参与方集合对应key的新值
• 交易提交阶段各节点只校验哈希的共识结果，不校验读集的原始数据来源

优点：

• 完全保留了每个参与方本地存全量数据的特性，数据可用性更高
• 读写集只存哈希，不会出现来源不一致的问题

缺点：

• 需要修改原有读写集的生成逻辑，链码改造量较大
• 跨组织数据同步不一致时会导致背书失败，需要额外实现数据同步校验逻辑

内容的提问来源于stack exchange，提问作者Akshay Sood