最新的 HyperLedger Fabric 2.0 部署测试的网络的配置说明。
本系列文章如下： HyperLedger Fabric 2.0 测试网络部署 Fabric2.0 样例 first-network 生成配置说明 Fabric2.0启动网络脚本配置剖析 Fabric 2.0 创建通道与加入通道 Fabric 2.0
2. generateCerts
generateCerts ：生成证书 详细来看脚本:
主要执行了两个核心脚本分别是：
cryptogen generate --config=./crypto-config.yaml
实现根据crypto-config.yaml 生成证书文件。
./ccp-generate.sh
此处证书结构不做详细说明，详情查看Fabric2.0官方文档
2.2 ./ccp-generate.sh
生成调用nodejs SDK的相关区块链配置文件。此处不作详细配置说明。
3. generateChannelArtifacts
generateChannelArtifacts ：生成创始区块与通道文件
3.1 生成创始区块
脚本：
configtxgen -profile SampleMultiNodeEtcdRaft -channelID byfn-sys-channel -outputBlock ./channel-artifacts/genesis.block 由于我接触Fabric是从2018年开始就是1.x时代，2.x的话完全是没有接触，看到上面的shell，明显就有了点2.0的味道，按照常规套路先看2.0官方文档解释：
configtxgen 命令参数的使用在2.0发生了变化，为了方便比较我放一下1.4官方文档的：
差别在于 创世区块的网络共识模式定义变了，删除了TwoOrgsOrdererGenesis(原本的排序节点创始区块配置)、SampleDevModeKafka (kafka共识配置)。
剩余的还是解释一下：
SampleMultiNodeEtcdRaft：用于生成创始区块的，配合-o一起用，支持etcdraft模式的共识。
TwoOrgsChannel：用于生成通道的。
剩下生成通道的脚本与原先的没有太大差距此处不作详细说明，详情请看官方文档说明，
3.2 通道文件生成
通道配置：
TwoOrgsChannel: # 通道联盟名称，现在默认是SampleConsortium Consortium: SampleConsortium # 引用ChannelDefaults通道详细配置 <<: *ChannelDefaults Application: # // 引用ApplicationDefaults <<: *ApplicationDefaults # //通道组织定义 Organizations: - *Org1 - *Org2 Capabilities: <<: *ApplicationCapabilities 通道详细配置：
Channel: &ChannelDefaults # 通道权限策略 <ALL|ANY|MAJORITY> <sub_policy> Policies: # Who may invoke the 'Deliver' API Readers: Type: ImplicitMeta Rule: "ANY Readers" # Who may invoke the 'Broadcast' API Writers: Type: ImplicitMeta Rule: "ANY Writers" # By default, who may modify elements at this config level Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" # Capabilities describes the channel level capabilities, see the # dedicated Capabilities section elsewhere in this file for a full # description Capabilities: <<: *ChannelCapabilities 上面主要是对通道权限策略配置，其中策略这块主要有两种类型：
- Signature策略
SIGNATURE策略指定通过签名来对数据进行认证，例如数据必须满足一定的签名身份组合 这种策略比较灵活，主要定义MSP主体组合规范。在验证签名策略的基础上，支持AND、OR、NOutOf，可以构建如：‘An admin of org A and 2 other admins, or 11 of 20 org admins’等规范。 
- ImplicitMeta策略
这种策略不如SignaturePolicy灵活，并且只在配置上下文中有效。它不直接进行签名检查，而是通过引用其子元素的策略（最终还是通过Signature策略）来进行检查 检查结果又Rule限制，它支持默认规则，如：‘A majority of the organization admin policies’。
共识配置
SampleMultiNodeEtcdRaft: <<: *ChannelDefaults Capabilities: # 通道Capabilities 指定2.0 <<: *ChannelCapabilities Orderer: <<: *OrdererDefaults # 排序节点类型etcdraft OrdererType: etcdraft # 系统通道中raft节点配置 raft服务是在order节点内 EtcdRaft: Consenters: - Host: orderer.example.com Port: 7050 ClientTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt ServerTLSCert: crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt Addresses: - orderer.example.com:7050 Organizations: - *OrdererOrg Capabilities: # 排序节点Capabilities 指定2.0 <<: *OrdererCapabilities Application: <<: *ApplicationDefaults Organizations: - <<: *OrdererOrg Consortiums: SampleConsortium: Organizations: - *Org1 - *Org2 4. 总结
综合来看，比起1.x版本的Fabric,在配置最大的变化是删除了solo以及kafka模式，仅支持etcdraft共识模式其余并没有太大变化，因此对于有1.x部署经验并不会造成太大的困难。
转载自： https://me.csdn.net/qq_28540443
