Hyberledger-Fabric 1.00 RPC学习(2)尝试建立一个network

本文参考：http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html

这里我们学习建立第一个Hyperledger Fabric network，包括两个organization（每个包括2个peer节点），以及一个“solo”的ordering service。

前提条件：安装docker、docker compose、go环境、npm、node.js，下载并安装好了Hyberledger Fabric Samples。

安装Hyberledger Fabric Samples简介：

• 建立一个目录

mkdir hyberledger-fabric
cd hyberledger-fabric

• 克隆一个仓库

git clone https://github.com/hyperledger/fabric-samples.git

• 下载特定的二进制文件

curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap-1.0.0-rc1.sh | bash

上述命令会下载自动化部署脚本，同时也会下载平台特定使用的二进制文件cryptogen,configtxgen,configtxlator, 以及peer，把他们放到上述仓库的bin目录下

接下来把bin目录加入到PATH环境变量中

vi /etc/profile

打开profile然后把下面语句添加进去即可

export PATH=/home/parallels/hyberledger-fabric/bin:$PATH

1.尝试run first-network

cd  fabric-samples/first-network

这里提供了一个脚本，byfn.sh，我们可以查看其的使用方法

如果你没有指定channel的名称，则该脚本则会使用默认的channel名称（mychannel）

CLI的超时参数（-t flag）可以选择，如果不选择，那么CLI容器将在脚本结束后退出。

2.生成network artifacts

执行如下命令：

./byfn.sh -m generate

遇到需要选择的地方选择y，会看到如下日志

这一步生成了network entity所需要的certificates以及keys，genesis block用于获取用于配置channel的ordering service以及transaction配置的集合。

3.启动network

接下来输入以下命令启动network，回复y

./byfn.sh -m up

可以看到如下输出结果

./byfn.sh -m up
Starting with channel 'mychannel' and CLI timeout of ''
Continue (y/n)?y
proceeding ...
Creating network "net_byfn" with the default driver
Creating peer0.org1.example.com
Creating peer1.org1.example.com
Creating peer0.org2.example.com
Creating orderer.example.com
Creating peer1.org2.example.com
Creating cli

 ____    _____      _      ____    _____
/ ___|  |_   _|    / \    |  _ \  |_   _|
\___ \    | |     / _ \   | |_) |   | |
 ___) |   | |    / ___ \  |  _ <    | |
|____/    |_|   /_/   \_\ |_| \_\   |_|

Channel name : mychannel
Creating channel...

日志从这里开始，这将启动所有的容器，形成这个完整的P2P的应用场景。

启动成功后会打印如下日志：

-- ::01.366 UTC [msp] GetLocalMSP -> DEBU  Returning existing local MSP
-- ::01.366 UTC [msp] GetDefaultSigningIdentity -> DEBU  Obtaining default signing identity
-- ::01.366 UTC [msp/identity] Sign -> DEBU  Sign: plaintext: 0AB1070A6708031A0C08F1E3ECC80510...6D7963631A0A0A0571756572790A0161
-- ::01.367 UTC [msp/identity] Sign -> DEBU  Sign: digest: E61DB37F4E8B0D32C9FE10E3936BA9B8CD278FAA1F3320B08712164248285C54
Query Result:
-- ::15.158 UTC [main] main -> INFO  Exiting.....
===================== Query on PEER3 on channel 'mychannel' is successful =====================

===================== All GOOD, BYFN execution completed =====================

 _____   _   _   ____
| ____| | \ | | |  _ \
|  _|   |  \| | | | | |
| |___  | |\  | | |_| |
|_____| |_| \_| |____/

通过上述日志能够看到不同的transaction。

4.关闭network

输入如下命令

./byfn.sh -m down

能够看到输出日志如下：

./byfn.sh -m down
Stopping with channel 'mychannel' and CLI timeout of ''
Continue (y/n)?y
proceeding ...
WARNING: The CHANNEL_NAME variable is not set. Defaulting to a blank string.
WARNING: The TIMEOUT variable is not set. Defaulting to a blank string.
Removing network net_byfn
468aaa6201ed
...
Untagged: dev-peer1.org2.example.com-mycc-1.0:latest
Deleted: sha256:ed3230614e64e1c83e510c0c282e982d2b06d148b1c498bbdcc429e2b2531e91
...

如果您想了解有关底层工具和引导机制的更多信息，请继续阅读。 在接下来的章节中，我们将介绍构建功能齐全的Hyperledger Fabric网络的各种步骤和要求。

5.Crypto生成器

我们使用crytogen工具给我们不同的network entity生成加密证书（X509 certs）。这些证书代表了身份，当我们的entity在进行通信以及transact的时候进行签名与验证身份。

Cryptogen有一个配置文件crypto-config.yaml，包括了网络拓扑，同时允许我们给organization以及component（隶属于organization）生成一个证书与私钥的集合。每一个organization被分配一个唯一的根证书（绑定了隶属于Org的具体的component，包括peers与orderers）。通过给每个organization分配一个唯一的CA证书，我们正在模仿一个典型的网络，参与的成员将使用自己的证书颁发机构颁发的证书。Hyperledger Fabric的transaction与通信均被entity的私钥(keystore)进行签名，截止被公钥进行验证（signcerts）。

这个配置文件中有一个计数（count）的变量，我们使用其定义organization中peer的数量，在本例中我们定义每一个Org有两个peer。这里不会深入讨论X.509证书以及公钥框架。

在run这个工具之前，我们回顾一下crypto-config.yaml，请注意在ordererOrgs头下面的“Name”, “Domain” 以及 “Specs”这三个参数。

OrdererOrgs:
#---------------------------------------------------------
# Orderer
# --------------------------------------------------------
- Name: Orderer
  Domain: example.com
  # ------------------------------------------------------
  # "Specs" - See PeerOrgs below for complete description
# -----------------------------------------------------
  Specs:
    - Hostname: orderer
# -------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ------------------------------------------------------
PeerOrgs:
# -----------------------------------------------------
# Org1
# ----------------------------------------------------
- Name: Org1
  Domain: org1.example.com

network entity的命名规则约定如下：“{{.Hostname}}.{{.Domain}}”。因此，使用我们的ordering node作为参考，我们能看到一个名称为 - orderer.example.com的ordering node，该node与Orderer的MSP ID关联。 您还可以参考会员 Membership Service Providers (MSP)文档，以便更深入地了解MSP。

我们运行cryptogen工具之后，生成的证书与秘钥将会保存到crypto-config文件夹中。

6.配置transaction生成器

configtxgen tool用于创建如下配置项：

genesis block：是一个配置block用于初始化blockchain网络以及channel的，同样可以作为链上的第一个block

• orderer genesis block,
• channel channel configuration transaction
• 两个anchor peer transactions，其中每一个对应一个peer org

如何使用该工具请查看， Channel Configuration (configtxgen)

orderer block是ordering service的genesis block，channel transaction file在channel创建时广播给orderer。anchor peer transactions在channel定义了一个Org Anchor Peer。

Configtxgen有一个配置文件configtx.yaml，包括了sample network的定义。现有3个成员：一个Orderer Org以及两个Peer Orgs（Org1 Org2，每个包括2个peer节点）。这个文件定义了一个联合consortium，包括两个Peer Org。注意该文件的顶部profile section。你会发现有两个唯一的headers。一个用作orderer Genesis block  - TwoOrgsOrdererGenesis -，一个用作channel - TwoOrgsChannel。

后续我们在来看这些headers。

注意：sampleConsortium被定义在system-level profile中，接下来被channel-level profile引用。Channels存在在consortium的范围内，所有的consortium都在network的范围内。

这个配置文件包括了两个附加的定义。一个就是每个Peer Org(peer0.org1.example.com & peer0.org2.example.com)的anchor节点，另外一个就是指向每个成员的MSP目录的位置，基于此，我们可以将每个Org的根证书存放在orderer Genesis block中，这是一个很重要的概念。现在任意network entity与ordering service通信时就能对起数字签名进行验证。

7.运行tool

可以通过configtxgen and cryptogen手动生成证书/密钥以及各项配置文件。同样，可以参考byfn.sh脚本实现。

接下来我们尝试手动生成。

可以参考byfn.sh脚本中的generateCerts函数用来生成证书（这些证书被定义在crypto-config.yaml中的网络配置所使用）所需要的命令。为了方便起见，我们提供一个参考如下。

首先，先跑起来cryptogen工具，我们的二进制文件都在bin目录下，因此我们需要cd到tool所在的目录下.

../bin/cryptogen generate --config=./crypto-config.yaml

接下来，我们会告诉configtxgen工具去哪找到需要调用的configtx.yaml文件。

首先，我们需要设置一个环境变量，用于告知configtxgen根据去哪找configtx.yaml配置文件。接下来，我们调用configtxgen工具创建orderer Genesis block

export FABRIC_CFG_PATH=$PWD
../bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block

接着，我们创建channel transaction artifact(channel.tx)。然后，确保替换$CHANNEL_NAME（这里我用zeychannel替换的）或设置环境变量，语句如下：

export CHANNEL_NAME=mychannel

# this file contains the definitions for our sample channel
../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME

接着，我们在我们正在创建的channel上定义Org1的anchor节点。然后，确保替换$CHANNEL_NAME（这里我用zeychannel替换的）或设置环境变量，语句如下：

 

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP

然后，我们在相同的channel上定义Org2的anchor节点。

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP

8.启动network

我们利用docker-compose脚本来启动我们的network。docker-compose文件引用了我们之前下载的镜像，并使用前面生成的genesis block来引导orderer。

working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
# command: /bin/bash -c './scripts/script.sh ${CHANNEL_NAME}; sleep $TIMEOUT'
volumes

如果没有注释掉上面的命令的话，在network启动的时候，其将执行所有的CLI命令，具体请见 What’s happening behind the scenes?节。我们需要分析每一步的功能及句法，因此我们一步步执行命令。

timeout的变量适合使用较高的数值，默认是60s。

启动network，注意$CHANNEL_NAME,<pick_a_value>自己设定

CHANNEL_NAME=$CHANNEL_NAME TIMEOUT=<pick_a_value> docker-compose -f docker-compose-cli.yaml up -d

如果想看到实时日志，则不要加-d标示。如果需要日志流，则需要打开第二个终端进行操作。

9.环境变量

对于以下针对peer0.org1.example.com的CLI命令，我们需要使用以下给出的四个环境变量来介绍我们的命令。这些peer0.org1.example.com变量都被包含在CLI容器里，因此我们可以不用传递的操作它们。然而！，如果你想发送calls到其他peers或者orderer，你需要根据情况提供这些变量。打开docker-compose-base.yaml并查看具体的路径信息，

# Environment variables for PEER0

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
CORE_PEER_ADDRESS=peer0.org1.example.com:
CORE_PEER_LOCALMSPID="Org1MSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

10.创建并进入Channel

接下来进入到刚创建的CLI容器里面，

docker exec -it cli bash

如果成功则能看到如下信息

请回忆下我们使用configtxgen工具生成channel配置artifact-channel.tx。我们将把artifact作为创建channel的请求的一部分发送给orderer。

注意到在接下来的命令中我们发送了-- cafile作为命令的一部分。这个是orderer证书的本地路径，使得我们可以验证TLS握手。

我们使用-c flag 标注出我们的channel名称，用-f flag标注出我们的channel 配置transaction。在本例中是channel.tx，然而你可以使用不同的名称用于挂载配置transaction。使用下面创建channel的语句的时候注意channel-name。

export CHANNEL_NAME=mychannel

# the channel.tx file is mounted in the channel-artifacts directory within your CLI container
# as a result, we pass the full path for the file
# we also pass the path for the orderer ca-cert in order to verify the TLS handshake
# be sure to replace the $CHANNEL_NAME variable appropriately

peer channel create -o orderer.example.com: -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

上述命令返回了一个genesis block- <channel-ID.block> -我们可以通过这个id进入到channel。它包含channel.tx中指定的配置信息，创建成功后有如下输出：

接下来的操作都需要在CLI容器中进行，在操作peer0.org1.example.com之外的peer时，需要记得相关环境变量的命令。

接下来我们把peer0.org1.example.com加入到channel中去，channel-ID.block是之前生成的，这里我的是zeychannel.block。

# By default, this joins ``peer0.org1.example.com`` only
# the <channel-ID>.block was returned by the previous command

 peer channel join -b <channel-ID.block>

以下是成功的显示

你可把其他的peer加入到该channel上，但是需要设置上述的四个环境变量。

11.安装并实例化chaincode

我们这里只是使用已经存在的chaincode。

application通过chaincode与blockchain ledger进行交互。我们把chaincode安装到execute与endorse我们transaction的peer上，接下来在channel上初始化chaincode。

首先，安装sample go代码到4个peer之一的peer上。以下命令把chaincode的源代码放到了peer节点的文件系统上。

peer chaincode install -n zeychaincode -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02

安装成功打印如下日志

接下来，在channel上实例化chaincode。这将在channel上初始化chaincode，同时设置chaincode的endorsement的策略，然后在目标peer上启动chaincode容器。请注意-P参数，我们通过设置这个参数，来指定transaction的endorsement的需求level，用于验证chaincode。

在下面的命令，我们定义了endorsement策略为-P "OR ('Org0MSP.member','Org1MSP.member')"。这表示我们需要隶属于Org1或者Org2的peer进行“endorsement”（也就是说，只有一个endorsement）。如果把or改为and则说明我们需要两个endorsement。

# be sure to replace the $CHANNEL_NAME environment variable
# if you did not install your chaincode with a name of mycc, then modify that argument as well

peer chaincode instantiate -o orderer.example.com: --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C zeychannel -n zeychaincode -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.member','Org2MSP.member')"

请在 endorsement policies中查看更详细的策略说明。

12.查询

首先查询a的值，确保chaincode已经正常的实例化，同时确保state DB已经被填充

# be sure to set the -C and -n flags appropriately

peer chaincode query -C zeychannel -n zeychaincode -c '{"Args":["query","a"]}'

13.调用

让我们从a账户转移10个到b账户，这个命令将会创建新的block同时更新state DB。

# be sure to set the -C and -n flags appropriately

peer chaincode invoke -o orderer.example.com:  --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem  -C zeychannel -n zeychaincode -c '{"Args":["invoke","a","b","10"]}'

然后查询

# be sure to set the -C and -n flags appropriately

peer chaincode query -C zeychannel -n zeychaincode -c '{"Args":["query","a"]}'

14.上述调用过程解析

• script.sh脚本在CLI容器内部执行，该脚本执行了createChannel命令，提供了channel名称，同时使用channel.tx进行channel配置
• createChannel的输出是一个genesis block，使用channel名称命名的block，例如zeychannel.block，该block在peers的文件系统上存储（个人理解就在chain上作为一个block存储的），该block包括channel.tx指定的channel配置信息。
• 加入channel的命令对所有4个peer进行执行，把之前生成的genesis block作为输入。这个join命令使得peers加入到了zeychannel（我自己创建的）里面，同时创建了一个以zeychannel.block作为开始的chain。
• 接着，我们拥有了由4个peer，两个organization组成的channel。这都在我们TwoOrgsChannel profile.里面。
• peer0.org1.example.com 与 peer1.org1.example.com 隶属于 Org1; peer0.org2.example.com 以及 peer1.org2.example.com 隶属于 Org2。这些关系在crypto-config.yaml中定义，同时在我们的docker compose中指定了MSP的路径。
• Org1MSP (peer0.org1.example.com) 以及 Org2MSP (peer0.org2.example.com)的anchor节点接下来被更新了。我们基于建立的channel把Org1MSPanchors.tx 与 Org2MSPanchors.tx 的artifacts，发送给orderering service，以实现上述的更新。
• chaincode_example02被安装在了peer0.org1.example.com 与 peer0.org2.example.com
• 接着chaincode在peer0.org2.example.com被实例化。实例化把chaincode加到channel上，并启动目标peer的容器，接着初始化chaincode有关的键-值对（ [“a”,”100” “b”,”200”]）。实例化的过程导致了dev-peer0.org2.example.com-zeychaincode-1.0的启动。
• 实例化需要有endorsement策略的参数，这里设置为-P "OR    ('Org1MSP.member','Org2MSP.member')"，表示任意transaction必须被Org1 或者 Org2的一个peer进行endorsed。
• 接下来把对“a”的查询发送给peer0.org1.example.com，即在peer0.org1.example.com查询a的值。chaincode之前已经安装在了peer0.org1.example.com上，因此这个查询将会针对Org1 peer0 启动一个容器（dev-peer0.org1.example.com-zeychaincode-1.0），然后查询结果得到返回，没有任何写的操作发生，因此返回值是100
• 接着调用请求发送给peer0.org1.example.com，把10个从a转移到b。
• 然后chaincode在peer1.org2.example.com进行安装。
• 然后一个查询a的余额的请求发送到peer1.org2.example.com。这个启动了第三个chaincode容器（dev-peer1.org2.example.com-mycc-1.0），90被返回。正确的反应了上述transaction，a的值被改为了10。