Hyperledger Fabric是一个经许可的区块链基础设施，旨在解决多方业务场景中建立问责制的问题。

尽管Hyperledger的成员资格模型确保了网络所有参与者的身份，但在现实世界中的多方业务场景中，数据保护和隐私法律带来了可能阻止所有数据在网络各方之间共享的法律法规要求。

在1.2之前，HL中的隐私是通过渠道的概念来解决的。希望在选择性的其他组织之间共享私有数据的公司（对等节点）是在一个单独的渠道中加入的。这种方法的问题是重复数据和在组织组之间创建大量渠道网络。

1.2版本是通过私有数据收集概念解决这一问题的一个巨大进步。集合可以被认为是由许多信息共享组组成的通道上的覆盖，但是在私有集合中共享的私有数据的散列在分类帐状态下进行维护，以确保有效性和完整性。在这种情况下，事务数据是大量的对等数据，以掩盖它甚至暴露给订购方节点。

假设读者已经对Hyperledger结构的基本架构有了相当的了解，我将在这里切入重点，分享我们关于实现"通过SideDBs隐私"的观点。

一个链码可以定义许多"集合"。存储在特定集合中的数据只有属于该集合的组织才能查看。

下面是查看私有数据集合的简单步骤：

步骤1。在集合中定义集合-配置.json

第2步。将数据分为公共结构和私有结构[这样我们可以让通道中的所有组织公开地看到数据的某些部分，但有些部分是隐藏的，并且只在某些方面共享]

步骤3：在代码中添加处理程序，将数据的公共部分保存到世界状态数据库，将私有数据保存到集合中。

在下面的示例中，我们定义了两个私人收藏。"collections1"用于持久化仅在CompanyA和CompanyB之间共享的数据（companyC对此数据没有可见性）。而"collections2"用于只能被CompanyA和CompanyC看到的数据（companyB对此没有可见性）。

（请注意，在我们的SAP testnet网络中，具有自己MSP的对等节点CompanyA被命名为"companyasp"，因此得名公司股东在collections配置中，

blockToLive参数定义最大时间（以块为单位）之后，数据将被自动清除（规定符合GDPR的要求）。值为0表示从不清除。

注：收集-配置.json在部署期间不需要与其他链码src文件一起压缩。在chaincide部署到通道之后，在"实例化"阶段，集合-配置.json需要上传。

假设每个属于该频道的对等节点都应该有能力检查区块链中某个项目的有效性和真实性，并读取该项目的某些基本属性，但是，如果一个公司希望根据某些合同协议，大数据和数据分析区别，只与某些公司共享有关该项目的一些信息，例如制造商、国家和价格，并对其他公司隐藏这些信息，那么我们需要对数据结构进行分解和征服，企业管理平台软件，因此：

请注意，由于项目id/密钥代表唯一的项目，因此最好使用它在正常通道数据和PrivateDB中匹配，因此我们有数据完整性。

例如：下面是简单的addItem代码，用于将公共部分存储在world state DB中，将私有部分存储在Collections/sideDB中。

[请注意，我只是将私有数据存储在collections1中，企业管理软件下载，在该代码中，我们可以使代码动态化，以确定要存储哪个"collection"基于任何特定的业务逻辑进行存储，例如基于项目id、所有者等]

大多数可用于访问正常通道数据的shim API方法也可用于私人收集。

现在将上述信息组合在一起，我们有一个简单的链码实现来演示私人数据的用法：

一个简单的实现可以在这个github repo中可以找到：

1.3中的挑战和1.4 w.r.t私有数据中的增强：

在1.3版本之前，如果需要更细粒度的访问控制（例如：在事务级别），云服务器比较，我们必须实现自己的访问控制逻辑作为链码的一部分来处理它。这是必要的，大数据和数据库，因为基于全渠道认可策略的对等选择的不确定性。

Fabric版本1.4支持基于链码的认可和基于状态的认可策略。这增加了支持基于事务的更严格访问控制的规定