在 Fabric 中使用私有数据（对官方教程做了修改）

在 Fabric 中使用私有数据（对官方教程做了修改）

本教程将带你练习在 Fabric 中定义、配置和使用私有数据。

关于私有数据的更多信息请参阅 私有数据 。

官方教程参考：https://hyperledger-fabric.readthedocs.io/zh_CN/release-1.4/private_data_tutorial.html

下边的图片阐明了弹珠私有数据示例所使用的私有数据模型。

收集器的 JSON 定义文件：

在通道中数据私有化的第一步是创建一个定义了私有数据权限的收集器。

收集器定义描述了谁可以持有数据、数据要分发到多少个节点上、多少节点可以传播私有数据 和私有数据要在私有数据库中存放多久。然后，我们将演示链码 API PutPrivateData 和 GetPrivateData 是如何将收集器映射到受保护的私有数据的。

收集器的定义包括一下属性：

• name: 收集器的名字。
• policy: 定义了可以持有数据收集器的组织节点。
• requiredPeerCount: 作为链码的背书条件，需要将私有数据传播到的节点数量。
• maxPeerCount: 为了数据冗余，现有背书节点需要尝试将数据分发到其他节点的数量。如果背书节点发生故障，当有请求提取私有数据时，则其他节点在提交时可用。
• blockToLive: 对于非常敏感的信息，比如价格或者个人信息，这个值表示在数据要以区块的形式在私有数据库中存放的时间。数据将在私有数据库中存在指定数量的区块数然后会被清除， 也就是数据会从网络中废弃。要永久保存私有数据，永远不被清除，就设置 blockToLive 为 0 。
• memberOnlyRead: 值为 true 则表示节点会自动强制只有属于收集器成员组织的客户端才有读取私有数据的权限。

为了说明私有数据的用法，弹珠私有数据示例包含了两个私有数据收集器的定义： collectionMarbles 和 collectionMarblePrivateDetails 。在 collectionMarbles 中的 policy 属性定义了允许通道中（Org1 和 Org2）所有成员使用私有数据库中的私有数据。 collectionMarblePrivateDetails 收集器只允许 Org1 的成员使用私有数据库中的私有数据。

创建策略定义的更多信息请参考 背书策略 主题。

// collections_config.json

[
  {
       "name": "collectionMarbles",  //收集器的名字
       "policy": "OR('Org1MSP.member', 'Org2MSP.member')",  //定义了可以持有数据收集器的组织节点
       "requiredPeerCount": 0,  // 作为链码的背书条件，需要将私有数据传播到的节点数量
       "maxPeerCount": 3,       //为了数据冗余，现有背书节点需要尝试将数据分发到其他节点的数量
       "blockToLive":1000000,   //表示在数据要以区块的形式在私有数据库中存放的时间,数据将在私有数据库中存在指定数量的区块数然后会被清除
       "memberOnlyRead": true   //值为true则表示节点会自动强制只有属于收集器成员组织的客户端才有读取私有数据的权限
  },

  {
       "name": "collectionMarblePrivateDetails",
       "policy": "OR('Org1MSP.member')",
       "requiredPeerCount": 0,
       "maxPeerCount": 3,
       "blockToLive":3,        //表示在数据要从其生成开始，网络中增加3个区块后就被删除
       "memberOnlyRead": true
  }
]

总结一下，上边我们为 collection.json 定义的策略允许 Org1 和 Org2 的所有节点在他们的私有数据库中存储和交易弹珠的私有数据 name, color, size, owner 。 但是只有 Org1 的节点可以在他的私有数据库中存储和交易 price 私有数据。

数据私有的一个额外的好处是，当使用了收集器以后，只有私有数据的哈希会通过排序节点， 而不是私有数据本身，从排序方面保证了私有数据的机密性。

具体操作开始：

1、安装fabric 1.4.0

参考教程：https://blog.csdn.net/glclh/article/details/108184471

2、修改docker-compose-cli.yaml文件（与官方教程最大的不同）

每个客户端每次只能操作一个peer节点，如果更改客户端连接的peer节点，必须同时更改相应的环境变量，否则客户端无法与其所连接的peer节点通信。

• peer0.org1.example.com 对应cli客户端
• peer1.org1.example.com 对应cli11客户端
• peer0.org2.example.com 对应cli02客户端
• peer1.org2.example.com 对应cli12客户端

在docker-compose-cli.yaml文件末尾添加以下内容：

  cli11:
    container_name: cli11
    image: hyperledger/fabric-tools:$IMAGE_TAG
    #是否存在终端
    tty: true
    #是否使用终端标准输入
    stdin_open: true
    environment:
      #客户端容器启动后，go的工作目录
      - GOPATH=/opt/gopath
      #容器启动后，对应的守护进程的本地套接字
      - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
      #日志级别
      #- FABRIC_LOGGING_SPEC=DEBUG
      - FABRIC_LOGGING_SPEC=INFO
      #当前客户端节点的ID
      - CORE_PEER_ID=cli11
      #客户端当前连接的peer节点
      - CORE_PEER_ADDRESS=peer1.org1.example.com:7051
      #客户端连接的peer节点所属组织的ID
      - CORE_PEER_LOCALMSPID=Org1MSP
      #通信是否使用tls加密
      - CORE_PEER_TLS_ENABLED=true
      #客户端连接的peer节点的三个文件
      #证书文件
      - CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/server.crt
      #私钥文件
      - CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/server.key
      #根证书文件
      - CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.crt
      #当前客户端的身份文件，指定客户端的身份
      - CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
    #客户端的工作目录  
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
    command: /bin/bash
    #卷的挂载