实例化chaincode后, 可以查看初始值. 这些操作都是在CLI容器中进行:

peer chaincode query -C mychannel -n mycc -v v0 -c '{"Args": ["query", "a"]}'

# 转账
peer chaincode invoke -C mychannel -n mycc -v v0 -c '{"Args":["invoke","a","b","10"]}'

peer chaincode query -C mychannel -n mycc -v v0 -c '{"Args": ["query", "a"]}'

可以看到, 转账过后, a的值变成了90, b的值变成了210.

程序在启动的时候, 会读取配置文件和环境变量的值, 如 fabric-samples/basic-network/docker-compose.yml 中的 ORDERER_GENERAL_LOGLEVEL=debug, 这是传递给节点的参数, 传递参数的方法有环境变量, 配置文件, 动态环境变量, 默认值等. 获取参数的流程如下图所示:

每种组件的环境变量都要单独设置, 每个环境变量的名称都有前缀, 如ORDERER_GENERAL_LOGLEVEL的前缀是ORDERER, 它属于Orderer节点; 前缀是CORE的是Peer节点.

日志. 有 critcal, error, warning, notice, info, debug 六个级别, 越往后级别越低, 输出的内容也越丰富, 默认情况下为 info 级别.

logging:
    peer:info
    cauthdsl:warning
    gossip:warning
    ledger:info
    msp:warning
    policies:warning
    grpc:error

日志的输出格式为:

format: '%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}'

peer 部分的配置项较多, 可以分为通用配置, gossip, events, tls 等多个部分.

crypto-config.yaml 会指定网络的拓扑结构. 主要包括两种组织信息:

OrdererOrgs: 构成Orderer集群的节点所属组织

PeerOrgs: 构成Peer集群的节点所属组织

每个组织拥有:

Name: 组织名称

Domain: 组织的命名域

CA: 组织的CA地址, 包括Hostname域

若干节点: 每个节点包括 Hostname, CommonName, SANS等域. 可以用Specs字段指定一组节点, 或用Template字段指定自动生成节点的个数

User: 自动生成除admin外的用户个数

每个主机的配置一般可以通过Specs来指定或通过Template来自动顺序生成. 默认通用名为 主机名.组织域. 如, 域 org1.example.com 中, Peer节点的名称可能为 peer0.org1.example.com, peer1.org1.example.com 等.

OrdererOrgs:
  - Name: Orderer
    Domain: example.com
    CA:
        Country: US
        Province: California
        Locality: San Francisco
    Specs:
      - Hostname: orderer
PeerOrgs:
  - Name: Org1
    Domain: org1.example.com
    EnableNodeOUs: true
    CA:
        Country: US
        Province: California
        Locality: San Francisco
    Template:
      Count: 2
    Users:
      Count: 1
  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: true
    CA:
        Country: US
        Province: California
        Locality: San Francisco
    Template:
      Count: 2
    Users:
      Count: 1

例子中, Orderer组织通过Specs字段, 指定了主机名为orderer, 加上组织域, 就是orderer.example.com

Peer组织则通过Template来自动生成了Count个数的主机. Users字段下的Count字段会让cryptogen工具以自动顺序生成指定个数的普通用户.

因此, 该例子生成了两个节点和一个普通用户.

cryptogen工具生成的文件会放在当前目录下的 crypto-config 目录中. 目录结构如图所示:

fabric v1.1中, 每个组织下都有5个目录: ca, msp, tlsca, users, peers/orderers.

ca: 存放组织的根证书和对应的私钥文件, 默认采用EC算法, 证书为自签名(一般情况下, 根证书都是自签名). 组织内的实体将基于该证书作为根证书.

msp: 存放代表该组织的身份信息. msp下有 admincerts, cacerts, tlscacerts 三个目录.

• admincerts: 组织管理员的身份验证证书, 被根证书签名.
• cacerts: 组织的根证书, 与ca目录下的文件一样.
• tlscacerts: 用于TLS的CA证书, 自签名.

tlsca: 存放tls相关的私钥和证书.

users: 用户信息, 里面包括msp证书和tls证书.

peers: 存放属于该组织的所有Peer节点.

• peer0: 第1个Peer节点的信息, 包括msp证书和tls证书. msp(这个msp是peers里面的msp): 包括 admincerts, cacerts, tlscacerts 三个目录. admincerts 目录里的内容和外层的msp目录下的 admincerts 里的内容一样. 同理, 另外两个目录里的内容也分别和外层的msp目录下相应目录里的内容相同. keystore 目录下存放本节点的身份私钥, 用来签名. signcerts 目录下存放的是验证本节点签名的证书, 该证书被组织的根证书签名. tls: 存放tls相关的证书和私钥. ca.crt: 组织的根证书. server.crt: 验证本节点签名的证书, 被组织根证书签名. server.key: 本节点的身份私钥, 用来签名.
• peer1: 与peer0类似.

还有很多证书, 私钥等, 作用类似.

最重要的是msp目录下的内容. 一般包括:

• admincerts: 管理员的身份证书文件
• cacerts: 信任的根证书文件
• keystore: 节点的私钥, 用于签名
• signcerts: 节点的证书, 用于证明自己的身份
• tlscacerts: TLS连接用的证书
• intermediatecerts(可选): 信任的中间证书
• crls(可选): 证书撤销列表
• config.yaml(可选): 记录组织中的实体信息, 包括根证书位置和ID信息

这些身份文件随后分别发送到对应的Orderer节点和Peer节点上, 并放到对应的MSP路径下, 用于签名使用.

Orderer: 需要将 crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com 目录下的内容复制以 Orderer 节点的 /etc/hyperledger/fabric 目录下.

Peer: 需要将 crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com 目录下的内容复制到 Peer0 节点的 /etc/hyperledger/fabric 目录下. 其他 Peer 节点也类似.

CLI: 为方便操作, 将完整的 crypto-config 目录复制到 /etc/hyperledger/fabric 目录下. 即, 客户端需要有其他节点的证书.

可以通过 cryptogen showtemplate 查看默认的配置.

configtx.yaml 文件中的内容主要有 profile, organizations, orderer, application 四个部分.

• profile: 定义了一系列通道配置模板, 包括 Orderer 系统通道模板和应用通道类型模板.
• organizations: 定义了一系列的组织结构, 由其他部分引用.
• orderer: 系统通道相关配置, 包括 orderer 服务配置和参与 ordering service 的组织信息.
• application: 应用通道相关配置.