区块链 test-network 测试网络（参考官方文档）

一、测试网络

（前提，已配置好区块链的环境）

1.1启动测试网络

在test-network目录中，运行以下命令删除之前运行的所有容器或工程：

./network.sh down

再执行命令来启动网络

./network.sh up

1.2测试网络的组成部分

docker ps -a

1.3创建一个通道

运行以下命令以创建一个默认名称为“ mychannel”的通道：

./network.sh createChannel

也可以使用channel标志创建具有自定义名称的通道

./network.sh createChannel -c channel1

运行成功后会有提示joined之类的信息

1.4在通道启动一个链码

./network.sh deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -ccl go

depolyCC子命令将在节点上安装指定的链码（此处为asset-transfer-basic）

java版本

./network.sh deployCC -ccn  basic -ccp ../asset-transfer-basic/chaincode-java -ccl java -c channel1

1.5与网络交互

将bin目录下的二进制文件添加到CLI路径下（例如bin目录下的peer等二进制文件）

export PATH=${PWD}/../bin:$PATH

将fabric-samples代码库中的FABRIC_CFG_PATH设置为指向其中的core.yaml文件

export FABRIC_CFG_PATH=$PWD/../config/

您可以设置环境变量，以允许您作为Org1操作peer CLI ：

# Environment variables for Org1

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051

确定启动链码后，运行命令来初始化账本：

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C channel1 -n basic --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"InitLedger","Args":[]}'

注意：其中的channel的名字需与之前保持一致，以下的都是

命令成功后会有successful的提示信息

下面可以输入命令查询账本了：

peer chaincode query -C mychannel -n basic -c '{"Args":["GetAllAssets"]}'

修改账本：

当一个网络成员希望在账本上转一些或者改变一些资产，链码会被调用。使用以下的指令来通过调用 asset-transfer (basic) 链码改变账本上的资产所有者：

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n basic --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"TransferAsset","Args":["asset6","Christopher"]}'

因为 asset-transfer (basic) 链码的背书策略需要交易同时被 Org1 和 Org2 签名，链码调用指令需要使用 --peerAddresses 标签来指向 peer0.org1.example.com 和 peer0.org2.example.com。因为网络的 TLS 被开启，指令也需要用 --tlsRootCertFiles 标签指向每个 peer 节点的 TLS 证书。

调用链码之后，我们可以使用另一个查询来查看调用如何改变了区块链账本的资产。因为我们已经查询了 Org1 的 peer，我们可以把这个查询链码的机会通过 Org2 的 peer 来运行。设置以下的环境变量来操作 Org2：

# Environment variables for Org2

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=localhost:9051

查询运行在 peer0.org2.example.com asset-transfer (basic) 链码：

peer chaincode query -C mychannel -n basic -c '{"Args":["ReadAsset","asset6"]}'

1.6关停网络

使用完测试网络后，您可以使用以下命令关闭网络：

./network.sh down

该命令将停止并删除节点和链码容器，删除组织加密材料，并从Docker Registry移除链码镜像。 该命令还删除之前运行的通道项目和docker卷。

二、将智能合约部署到通道

此处大部分为自己的翻译，可能不准确，官方文档：

Deploying a smart contract to a channel — hyperledger-fabricdocs master 文档

用户同股票调用智能合约来与区块链账本进行交互。在Hyperldger Fabric 中，智能合约部署在链码上，组织想要执行事务或者查询账本都需要在他们的节点上下载链码。

2.1 打包智能合约（JAVA）

在打包之前，先要内置链码的依赖

可以看到在fabric-samples/chaincode/fabcar/java下的build.gradle

导入智能合约依赖：

在fabcar/java目录下输入命令：

./gradlew installDist

注意：这里运行后如出现拒绝连接，在命令前加上sudo即可

导入成功后，可以在build文件夹下找到建立的智能合约

创建链码包

导航回到test-network目录下，在此目录下我们可以将链码与其他网络工件打包在一起。

先配置一下，虽然之前也配置过，但不可以跳过

export PATH=${PWD}/../bin:$PATH
export FABRIC_CFG_PATH=$PWD/../config/

通过 peer lifecycle chaincode package 命令创建链码包

peer lifecycle chaincode package fabcar.tar.gz --path ../chaincode/fabcar/java/build/install/fabcar --lang java --label fabcar_1

这条命令会在当前目录下创建一个fabcar.tar.gz的文件

–lang指定链码的语言；—path指定链码的路径；–label 用于安装链码后标识链码

2.2安装链码包

在打包智能合约之后，我们可以在节点上安装链码。链码需要安装在每一个支持事务的peer节点上。因为背书策略需要Org1和Org2 的背书，所以我们需要在这两个组织上的peer节点都安装链码。

先在Org1peer节点上安装链码，设置下面的环境变量以Org1 管理员身份操作

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_ADDRESS=localhost:7051

在节点上安装链码

peer lifecycle chaincode install fabcar.tar.gz

如上，命令运行成功后，会返回 Chaincode code package identifier，我们会使用这个东西在下一步骤批准链码。

现在，同上在Org2的peer节点上安装链码

配置环境

export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=localhost:9051

安装链码

peer lifecycle chaincode install fabcar.tar.gz

2.3 批准链码定义

在安装好链码包后，我们需要在组织上批准链码包的定义。这个定义包括链码治理的重要参数，比如名称、版本和背书策略

在部署链码之前需要通过在Application/Channel/lifeycleEndorsement 的策略批准通道成员。默认情况下，此策略要求大多数通道成员需要批准链码才能在通道上使用。因为我们现在通道上只有Org1和Org2 两个组织，我们都需批准。

如果组织已经在peer节点上安装了链码，则需要将package ID包含在组织批准的链码定义中。package ID 用于将节点上安装的链码与批准的链码定义相关联，并允许组织使用链码背书交易。

可以通过 peer lifecycle chaincode queryinstalled命令查询peer节点的package ID

package ID是链码标签和链码二进制文件的哈希的组合。每个节点都会生成同样的package ID

peer lifecycle chaincode queryinstalled

我们将会在批准链码时使用package ID，所以把他设置为环境变量。注意：每个用户的package ID并不相同

export CC_PACKAGE_ID=fabcar_1:69de748301770f6ef64b42aa6bb6cb291df20aa39542c3ef94008615704007f3

由于环境变量已设置为以 Org2 管理员身份操作peer节点，因此我们可以作为 Org2批准 Fabcar 的链码定义。链码在组织级别获得批准，只需要对一个peer节点执行命令。批准使用广播分发给组织内的其他peer节点。

peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name fabcar --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

–package-id 链码定义中的package标识

–sequence 此参数是一个整数，用于跟踪链码被定义或更新的次数。因为链码第一次部署到通道上，所以这个值为1，当fabcar的链码更新之后，该值会变为2。

如果使用的是 Fabric Chaincode Shim API 提供的低级 API，可以加上 --init-required 命令，以请求执行 Init 函数来初始化链码。链码的第一次调用需要用到 Init 函数，要加上 --isInit 标志，然后才能使用链码中的其他函数与账本交互。

我们可以使用–signature-policy 或者 --channel-config-policy来指定背书策略。背书策略指定了属于不同通道成员的节点需要多少个节点来验证给定链码的交易。由于我们没有设置策略，因此 Fabcar 的定义将使用默认背书策略，该策略要求交易在提交交易时需要大多数通道成员背书。这意味着，如果在通道中添加或删除新组织，背书策略会自动更新。在本教程中，默认策略需要 2 个中的 2 个多数背书，并且事务需要由 Org1 和 Org2 的peer节点背书。

需要批准具有管理员角色的身份的链码定义。因此，CORE_PEER_MSPCONFIGPATH变量需要指向包含管理员标识的 MSP 文件夹。不能批准客户端用户的链码定义。审批需要提交到排序服务，该服务将验证管理员签名，然后将审批分发给peer节点。

上面已经作为Org2的管理员批准了链码的定义，所以Org1也要批准。

配置环境：

export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
export CORE_PEER_ADDRESS=localhost:7051

批准链码

peer lifecycle chaincode approveformyorg -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name fabcar --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

我们现在拥有将 Fabcar 链码部署到通道的大多数节点。虽然只有大多数组织需要批准链码定义（使用默认策略），但所有组织都需要批准链码定义才能在其peer节点上启动链码。如果您在通道成员批准链码之前提交定义，组织将无法背书交易。因此，建议所有通道成员在提交链码定义之前批准链码。

2.4 提交链码定义到通道

在足够数量的组织批准链码定义后，一个组织可以将链码定义提交到通道。如果大多数通道成员批准了该定义，则提交交易将成功，链码定义中约定的参数将在通道上实现。

可以使用peer lifecycle chaincode checkcommitreadiness命令来检查通道成员是否批准了相同的链码定义。 checkcommitreadiness 命令的标志与用于批准组织的链码的标志相同。但是不需要包含 --package-id 标志。

peer lifecycle chaincode checkcommitreadiness --channelID mychannel --name fabcar --version 1.0 --sequence 1 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --output json

该命令将生成一个 JSON map，显示通道成员是否已批准

由于作为通道成员的两个组织都批准了相同的参数，因此链码定义已准备好提交到通道。可以使用 peer lifecycle chaincode commit 命令将链码定义提交到通道。提交命令还需要由组织管理员提交。

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name fabcar --version 1.0 --sequence 1 --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

–peerAddresses 标志来定位来自 Org1 的 peer0.org1.example.com 和来自 Org2 的 peer0.org2.example.com。commit交易将提交给加入通道的节点，以查询运营节点的组织批准的链码定义。该命令需要针对来自足够数量的组织的peer节点，以满足部署链码的策略。由于审批在每个组织内分发，因此可以定位属于通道成员的任何peer节点。

通道成员的链码定义背书被提交给排序服务，以添加到区块中并分发到通道。然后，通道上的peer节点验证是否有足够数量的组织批准了链码定义。peer lifecycle chaincode commit命令将等待节点的验证，然后再返回响应。

可以使用peer lifecycle chaincode querycommitted命令来确认链码定义已提交到通道。

peer lifecycle chaincode querycommitted --channelID mychannel --name fabcar --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

如果链码成功提交到通道，querycommitted命令将会返回链码定义的版本和sequence

2.5 调用链码

链码定义提交到通道后，链码将在加入安装链码的通道的对等节点上启动。Fabcar 链码现在已准备好由客户端应用程序调用。使用以下命令在账本上创建一组初始汽车。请注意，调用命令需要足够数量的peer节点以满足链码背书策略。

peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n fabcar --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"initLedger","Args":[]}'

调用成功

我们可以使用查询函数来读取由链码创建的汽车集：

peer chaincode query -C mychannel -n fabcar -c '{"Args":["queryAllCars"]}'

2.6 升级智能合约

可以使用相同的 Fabric 链码生命周期流程来升级已部署到通道的链码。通道成员可以通过安装新的链码包，然后批准具有新package ID、新链码版本和序列号递增 1 的链码定义来升级链码。新的链码可以在链码定义提交到通道后使用。此过程允许通道成员协调链码何时升级，并确保在将新链码部署到通道之前，有足够数量的通道成员准备好使用新链码。

通道成员还可以通过使用升级过程来更改链码背书策略。通过批准具有新背书策略的链码定义并将链码定义提交到通道，通道成员可以更改管理链码的背书策略，而无需安装新的链码包。

为了提供升级我们刚刚部署的 Fabcar 链码的场景，我们假设 Org1 和 Org2 想要安装用另一种语言编写的链码版本。他们将使用 Fabric 链码生命周期来更新链码版本，并确保两个组织在通道上激活之前都安装了新链码。

我们假设 Org1 和 Org2 最初安装了 Fabcar 链码的 GO 版本，但使用用 JavaScript 编写的链码会更舒服。第一步是打包 Fabcar 链码的 JavaScript 版本。如果您在完成本教程时使用 JavaScript 指令打包链码，则可以按照打包用 Go 或 Java 编写的链码的步骤来安装新的链码二进制文件。

从测试网络目录执行以下命令以安装链码依赖项。

cd ../chaincode/fabcar/javascript
npm install
cd ../../../test-network

执行以下命令来打包来自测试网络目录的 JavaScript 链码。我们将设置再次使用peer CLI 所需的环境变量，以防您关闭终端（一关闭终端就需要重新设置）。

export PATH=${PWD}/../bin:$PATH
export FABRIC_CFG_PATH=$PWD/../config/
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
peer lifecycle chaincode package fabcar_2.tar.gz --path ../chaincode/fabcar/javascript/ --lang node --label fabcar_2

但是这部分卡掉了，在npm install的时候，但是命令跟之前java的一致。

2.7 清除

当我们完成使用链码指挥，我们可以执行以下命令来清除 Logspout工具（之前是可选选项，可跳过）

docker stop logspout
docker rm logspout

可以在test-network目录下执行以下命令来停止网络

./network.sh down

编写智能合约并将其部署到通道后，您可以使用 Fabric SDK 提供的 API 从客户端应用程序调用智能合约。这允许最终用户与区块链分类账上的资产进行交互。要开始使用 Fabric SDK，请参阅编写您的第一个应用程序教程。

三、编写第一个应用

关于 FabCar

FabCar例子演示了如何查询保存在账本上的Car（我们业务对象例子），以及如何更新账本（向账本添加新的Car）。 它包含以下两个组件:

1. 示例应用程序：调用区块链网络，调用智能合约中实现的交易。
2. 智能合约：实现了涉及与账本交互的交易。

我们将按照以下三个步骤进行：

1. 搭建开发环境。 我们的应用程序需要和网络交互，所以我们需要一个智能合约和 应用程序使用的基础网络。

2. 浏览一个示例智能合约。 我们将查看示例智能合约 Fabcar 来学习他们的交易，还有应用程序是怎么使用他们来进行查询和更新账本的。

3. 使用示例应用程序和智能合约交互。 我们的应用程序将使用 FabCar 智能合约来查询和更新账本上的汽车资产。我们将进入到应用程序的代码和他们创建的交易，包括查询一辆汽车，查询一批汽车和创建一辆新车。

在完成这个教程之后，你将基本理解一个应用是如何通过编程关联智能合约来和 Fabric 网络上的多个节点的账本的进行交互的。

3.1准备工作

因为是在linux环境下，需要安装 Python v2.7，make，和C/C++编译器工具链。执行以下命令：

sudo apt install build-essential

3.2设置区块链网络

在此之前，需要关闭所有网络

3.2.1启动网络

先进入fabcar目录

cd fabric-samples/fabcar

使用 startFabric.sh 脚本启动网络（此处为java版本，可换为其他），如果命令执行后有权限问题的错误，可以在命令前加sudo

./startFabric.sh java

此命令将部署两个peer节点和一个排序节点以部署Fabric测试网络。 我们将使用证书颁发机构启动测试网络，而不是使用cryptogen工具。 我们将使用这些CA的其中一个来创建证书以及一些key， 这些加密资料将在之后的步骤中被我们的应用程序使用。startFabric.sh 脚本还将部署和初始化在 mychannel 通道上的 FabCar智能合约的Java版本，然后调用智能合约来把初始数据存储在帐本上。

此命令执行完成后，会有下一步命令的提示：

3.2.2 示例应用

从 fabric-samples/fabcar 目录，进入到 java 文件夹。

cd java

运行以下命令安装应用程序依赖项

mvn test

运行此命令时，会自动执行CilentTest.java

3.2.3 登记管理员用户

当我们创建网络的时候，一个管理员用户（ admin）被证书授权服务器（CA）创建成了 注册员 。我们第一步要使用 enrollAdmin.java 程序为 admin 生成私钥、公钥和 x.509 证书。这个程序使用一个 证书签名请求 （CSR）——现在本地生成公钥和私钥，然后把公钥发送到 CA ，CA 会发布会一个让应用程序使用的证书。这三个证书会保存在钱包中，以便于我们以管理员的身份使用 CA 。

直接在java版本里面运行，之前在linux里下载了idea，可以在IDEA里直接运行java文件，在终端运行这样的maven项目总是出错，俺不会。

3.2.4 注册和登记应用程序用户

既然我们的 admin 是用来与CA一起工作的。 我们也已经在钱包中有了管理员的凭据， 那么我们可以创建一个新的应用程序用户，它将被用于与区块链交互。 运行registerUser.java注册和记录一个名为 appUser 的新用户

与admin注册类似，该程序使用CSR注册 appUser 并将其凭证与 admin 凭证一起存储在钱包中。 现在，我们有了两个独立用户的身份—— admin 和 appUser ——它们可以被我们的应用程序使用。

之后内容可看官方文档，很详细。

编写你的第一个应用 — hyperledger-fabricdocs master 文档