hyperledger fabric 1.2的一点特性

一、private data

1.1 概念

• 隐私数据保存在side DB中，Orderer service是看不见private data的
• 背书、排序、审计、写入peer中，都是用的hash值
• 当需要把private data分享给第三方时，验证hash值，证明数据是在某一个时间点的

1.2 数据流

• 发送invoke给背书节点（authorized），private data放在transient field中
• 背书节点模拟交易，并且存储再transient data store中（临时本地存储），通过goosip协议，根据collection policy传播
• 背书节点返回public data给客户端，包括private key 的hash
• Orderer排序，分割区块
• Peer验证，各个peer用同一种方法验证hash值。
• Commit期间，检查自己时候有权限拿到private data，如果有，再检查transient data store，如果没有的话就从其他peer那里pull，对比hash值，然后移出transient store

1.3 使用

• 在初始化链码的时候定义私有数据集合，结合private相关的函数使用

1.3 使用场景

• 当完整的交易需要信任的话，还是推荐用channel
• 当需要屏蔽orderer或者某些组织内节点时（存疑），使用collection

 

二、Service Discovery

    Sdk不需要维护静态信息，这个服务可以提供peer的动态信息，分为layouts和group to peer mapping，sdk可以根据策略选择peer进行背书。

提供功能：配置查询（MSPConfig）、peer成员信息查询、背书节点查询、本地peer成员信息查询。

三、Access Control Lists (ACL)

进一步提供了细粒度的访问控制列表，分为Signature和ImplicitMeta两种策略，具体见configtx.yaml。

四、CouchDB使用

4.1 流程

1. 在Hyperledger Fabric中启用CouchDB
2. 创建索引，索引会在出块的时候更新
3. 将索引添加到您的chaincode文件夹，通过node sdk可以指定位置，peer命令必须在特定位置
4. 安装并实例化Chaincode
5. 查询CouchDB状态数据库
6. 更新索引
7. 删除索引

注：深蓝在1.0上尝试直接用rest api访问couchdb，修改之后fabric未察觉到。

4.2 couchDB介绍

    couchDB的底层是一个B-tree的存储结构，为提高效率，所有的数据的插入或更新都是直接在树的叶子节点添加，不删除旧节点，通过版本号来 确定最新的数据－－版本号还能用来解决并发写的冲突。所以数据文件会越来越大，可以在适当地时间运行compact过程或replication过程，会 删除旧文件，使得数据文件得到压缩。

五、动态加入组织

1. 生成相关证书
2. 获取配置、提交配置更新
3. 将组织加入channel
4. 升级相关链码

六、可插拔的背书和验证

• 需要不同的交易背书，如UTXO等
• 可以替换系统合约，如ESCC和VSCC
• ESCC和VSCC独立出来，提供了签名（验证策略）和state相关的依赖项，可以自己实现接口，编译成so文件引用
• 插件一致性需要节点管理员保证，日后会做插件一致性的验证
• 如果返回ExecutionFailureError ，则链暂停防止分歧，其他错误都会被标记为invalid
• 导入插件的话推荐protobuf，其他的可能出问题

七、PeerLedger检查点

新增检查点，可以抛弃检查点之前的peerLedger，只留存vLedger（可指定策略）

八、Gossip领导人选举

静态：直接再core.yaml里面指定

动态：领导者发送心跳给其他节点，作为存活的证据，如果peer一段时间内没有收到这个信息，则开始重新选举，可以有多个领导者，但是网络稳定之后有一个领导者会放弃。

 

#参考文献

> http://hyperledger-fabric.readthedocs.io/en/release-1.2/

> https://github.com/hyperledger/fabric-samples

 

注：如有错误，还请大家指正。