hyperledger fabric是区块链中联盟链的优秀实现，主要代码由IBM、Intel、各大银行等贡献，目前v1.1版的kafka共识方式可达到1000/s次的吞吐量。本文中我们依次讨论：区块链的共通特性、fabric核心概念、fabric的交易执行流程。本文来源于笔者欲对公司部分业务上链而进行培训的PPT，故图多文字少，不要怕太长。

1、区块链解决方案的特性

1.1 分布式帐本

区块链核心概念是分布式帐本，就像下面的图1所示，同样的帐本（全量的交易数据，详见下节）在任意一台节点（不包括客户端）上都有。所以，其优点是数据很难造假，造假后也可以通过追溯记录来追究法律责任。而缺点就是极大的浪费，传统服务每份数据都尽量少存几份，即使存了三份拷贝都已经考虑到诸多异常，并使服务可用性达到N个9了。而区块链这种特性，同时造成的另一个问题是帐本不能太大，至少不能超过区块链网络中最小结点的存储以及处理能力。所以，这制约了总交易数据（下文为方便概念介绍，统称为帐本ledger）的条数，进而也影响了能写入区块链的单条交易数据的大小。

图1 区块链分布式帐本示意图

什么是区块链呢？我很喜欢《区块链技术进阶与实战》一书中对它的定义：区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构。如果觉得有点抽象，那么我们再来看看下面的图2。

图2-区块链数据结构示意

图2中就是账本，它由多个区块构成了一个有时序的链表，而每个区块里含有多条交易trasaction（缩写为tx）构成的链表。图2下方有一个WorldState世界状态，这其实是为了提升性能用的。比如，key1共交易了10000次，为了获取它的当前状态值，需要正向执行这10000次交易，这就得不偿失了。如果这1万次交易里，每次新交易执行完，都同步更新一个数据库（在fabric里用的是levelDB），这样查询当前状态时，只需要查询该数据库即可，如图3所示。

图3-fabric levelDB状态数据库

图3中，区块链帐本是在FileSystem文件系统中保存的，而Level DB存放世界状态。

1.2 智能合约smart contract

区块链的发展过程中，一般1.0时代就是数字货币时代，代表是比特币，而2.0时代就是智能合约（现在是3.0时代，各种联盟链即为代表）。

智能合约是运行在区块链上的模块化、可重用的自动执行脚本，有了它我们就可以完成复杂的业务逻辑，例如同一个区块链上有多份合约，而每份合约可以约定不同的参与者（企业或者相关方）。也可以指定每份合约里每个子命令做一批特定的事，大家可以把它想象成关系数据库里的事务。如图4所示，我们可以在合约里指定允许哪些企业的节点可以参与到交易流程中来（在fabric里这叫共识策略）。

图4-智能合约图示

在fabric中，智能合约叫做chaincode，它有6个状态，如下所示：

• Install → Instantiate → invocable → Upgrade → Deinstantiate → Uninstall.

实际上智能合约就是一段代码，fabric官方认可的是GO语言。首先我们需要把合约代码上传到区块链上，这一步的状态就叫Install。

接着，需要做初始化操作。比如，现在的数据是存放在mysql中的，那么上线时需要用Instantiate把数据迁移至链上，这也算初始化。初始化后，chaincode就进入invocable可调用状态了。

通用我们可以通过CLI命令行或者程序里用SDK调用合约（v1.1前还有RestApi调用，现已放弃）。

联盟链由于跨多家企业、多个地区甚至国家，很难使得合约保持一致的版本，因此，每个合约都有版本号。而版本升级时，就是Upgrade状态。

最后两个状态对应着合约下链。

智能合约可以在供应链等较复杂的业务场景下起到很大的作用，如下面的图5所示：

图5-智能合约技术的应用示意

1.3 数据一致性（共识算法）

既然区块链是一个去中心化的分布式系统，那么自然只能通过投票来决定一致性了：少数服从多数。当然，多少算多数呢？不同的共识算法下，结果并不相同。比如paxos算法（参见笔者的《paxos算法如何容错的–讲述五虎将的实践》）就是超过一半，而PBFT则需要三分之二以上。

这里有一个拜占庭将军问题需要注意，如何理解该问题可以参见这份翻译过的The_Part-Time_Parliament(Paxos算法中文翻译)文档。简言之，就是投票的拜占庭将军（服务器）们有2种不可靠的形式。第一是迟钝（数据包延迟）、失忆（数据包丢失以及数据包重发）、失踪（服务器宕机）等不含背叛的行为，第二则是有将军是间谍（服务器被攻破）。如paxos这样的算法属于第一种，Fault-tolerance，它不能容忍服务器上有恶意代码；而如PBFT(Practical Byzantine Fault Tolerance)这样的算法是第二类，Byzantine-Fault-tolerance，它能够容忍一定数量的拜占庭将军节点存在，如PBFT、SBFT、RBFT算法等。

第二类Byzantine-Fault-tolerance共识算法虽然看上去很美，但并不成熟，特别是性能低下，比如PBFT是一个多项式复杂度的算法O(N^2)，节点过多时（大于100）性能急骤下降。第一类通常是O(N)复杂度，在某些场景下使用效果还不错，比如fabric v1.1的kafka共识机制就是这样的算法，下文我们会详述。

像比特币、以太坊等采用的共识算法又有所不同，例如比特币的POW工作量证明算法，它定义一小时内（通过调整运算难度实现，比如调整近似程度）有一个lucky node节点，该节点是通过证明自身的努力（hash值逆解）而幸运选出，选出后它就可以为这段时间的交易做决定（似乎挺像总统选举^_^）。详情参见我这篇文章：《区块链技术学习笔记》

1.4 非对称加密

区块链通过非对称加密技术实现身份验证与数据加密。其实就是我们日常在用的SSL技术。

为了方便理解，我们需要先介绍PKI(Public Key Infrastructure)，它是一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。有一个CA（Certificate Authority）权威机构负责向用户（包括服务提供者与使用者）提供数字证书，包括公钥与私钥，同时CA机构还需要提供一个CRL（Certificate Revocation List）证书吊销列表，如下面的图6所示。

图6-CA机构颁发数字证书以及提供CAL

这样，区块链可以通过PKI体系实现安全认证。PKI有三个关键点，我们下面详述。

1.4.1 数字证书 Digital Certificate

比如Mary Morris符合X.509规范的数字证书里，其Subject属性里就含有她的信息，包括国家C=US、所属的州或者省份ST=Michigan、所在城市L=Detroit、所属单位O=Mitchesll Cars、其他信息OU=Manufacturing、公用信息CN=Mary Morris/UID=123456等，也含有其他信息，如下面的图7所示。

图7-PKI数字证书

1.4.2 公钥与私钥

CA颁发了两个证书：公钥与私钥，其中，私钥仅服务提供者保存，而公钥则可被所有人（服务使用者）保存。

所谓非对称加密，就是公钥加密的消息仅私钥可以解密；同理，私钥加密的消息，仅公钥可以解密。对应于前者，可以实现客户端访问服务器时加密消息，例如访问安全级别高的页面时提交的表单信息都需要用公钥加密，确保只有服务器才能解密网络报文。对应于后者，则可实现签名功能，如下面的图8所示。

图8-PKI中私钥签名后用公钥验签名

图8中Mary Morris用私钥对一段信息的内容（若内容过大则可先HASH后获得小点的字符串）加密后，生成签名附加在消息中。接收者可从CA机构获取到公钥，用公钥解密签名后，再与内容比对，以确定消息是否来自MaryMorris及内容是否被篡改。对于文件来说也是一样，小文件直接加密，大文件先生成hash再对hash加密，如下面的图9所示。

图9-对文件的签名

1.4.3 证书信任链

CA证书分为两类：RCA(Root CA)根证书以及ICA（Intermediate CA）中间证书。这些证书由RCA开始构成一个证书信任链，如下面的图10所示。

图10-CA证书信任链条

有许多CA证书权威机构，各自有其RCA。如果RCA得不到信任，那么其下的ICA也无法认证通过。

当然，自己的服务器也可以生成RCA。

在Fabric里，允许不同的企业使用不同的RCA，也可以使用相同的RCA和不同的ICA。这与下文中的MSP密切相关。

1.5 小结

我们来总结下区块链，它主要是为了解决社会上的信任问题而存在的，为此，它付出了沉重的性能、可用性代价。它怎么做到的呢？通过4点实现：1、数据到处存放；2、操作记录不可更改；3、传输数据可信；4、业务脚本约束。

那么，这个信任问题的解决，带来了2个非功能性的约束：数据一致性和可用性。其中可用性包括两点：1、交易在可接受的时间内达成。比如比特币的分叉就会造成严重问题。2、吞吐量达标。而比特币每秒只能有7次交易，这显然太低了。

2、fabric核心概念

hyperledger fabric符合上面说过的区块链的所有特性。我们必须先了解它的一些概念，才能进一步理解其架构设计。由于英文资料居多，所以这些概念我都以英文描述为准：

• chaincode：智能合约，上文已提到。每个chaincode可提供多个不同的调用命令。
• transaction：交易，每条指令都是一次交易。
• world state：对同一个key的多次交易形成的最终value，就是世界状态。
• endorse：背书。金融上的意义为：指持票人为将票据权利转让给他人或者将一定的票据权利授予他人行使，而在票据背面或者粘单上记载有关事项并签章的行为。通常我们引申为对某个事情负责。在我们的共识机制的投票环节里，背书意味着参与投票。
• endorsement policy：背书策略。由智能合约chaincode选择哪些peer节点参与到背书环节来。
• peer：存放区块链数据的结点，同时还有endorse和commit功能。
• channel：私有的子网络，事实上是为了隔离不同的应用，一个channel可含有一批chaincode。
• PKI：Public Key Infrastructure，一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。
• MSP：Membership Service Provider，联盟链成员的证书管理，它定义了哪些RCA以及ICA在链里是可信任的，包括定义了channel上的合作者。
• org：orginazation，管理一系列合作企业的组织。

2.1 开发概念

fabric联盟链的开发人员主要分为三类：底层是系统运维，负责系统的部署与维护；其次是组织管理人员，负责证书、MSP权限管理、共识机制等；最后是业务开发人员，他们负责编写chaincode、创建维护channel、执行transaction交易等，如下面的图11所示。

图11-fabric技术人员的分层

fabric大致分为底层的网络层、权限管理模块、区块链应用模块，通过SDK和CLI对应用开发者提供服务，如下面的图12所示。

图12-fabric开发模块图

我们的开发流程主要包括写智能合约，以及通过SDK调用智能合约，及订阅各类事件，如图13所示。

图13-开发环节

2.2 MSP

每个管理协作企业的ORG组织都可以拥有自己的MSP。如下图14所示，组织ORG1拥有的MSP叫ORG1.MSP，而组织ORG2业务复杂，所以维护了3个MSP。

图14-ORG可管理自己的MSP

MSP出现在两个地方：在channel上有一个全局的MSP，而每个peer、orderer、client等角色上都维护有本地的局部MSP，如图15所示。

图15-在channel上的Global MSP以及在参与角色上的Local MSP

本地MSP只保存有Global MSP上的子集，内容保存在本地文件系统上，而全局MSP可在逻辑上认为是配置在系统上的，它实际也在每个参与者上保存一份拷贝，但会维持一致性。

MSP也分级，如图16中所示，底层的network MSP负责网络层的准入，其MSP由ORG1拥有，而上面的某个channel的MSP则由ORG1和ORG2共同管理。

图16-MSP是分级的

一个MSP下含有以下结构，如图17所示。

图17-MSP结构

可见，MSP结构包括：

• RCA根证书
• ICA中间证书
• OU组织单位
• 管理员证书
• RCL吊销证书列表
• 结点上的具体证书
• 存储私钥的keystore
• TLS的根证书与中间证书

3、fabric交易提交流程

3.1 peer结点的部署

peer结点上保存有账本ledger以及智能合约，如下图所示：

channel是一个逻辑概念，可以通过MSP隔离全网不同组织的参与者，如下图所示：

当有多方参与者时，例如4个org组织、8个peer结点时，其中channel连接了P1、P3、P5、P7、P8这五个节点，其他3个节点加入了其他channel，其部署图如下所示：

加入MSP来管理身份时，如P1和P2由ORG1.MSP管理，而P3和P4的证书则由ORG2.MSP管理，他们共同使用一个channel，则如下图所示：

3.2 交易的执行流程

去中心化的设计，必然需要通过投票（多数大于少数）来维持数据一致性，而任何投票都必须经历以下三个过程：

1. 有一方先提出议案proposal，该议案有对应的一批投票者需要对该结果背书，这些投票者依据各自的习惯投票，并将结果反馈；
2. 统计投票结果，若获得多数同意，才能进行下一步；
3. 将获得多数同意的议案记录下来，且公之于众。

而这三步fabric当然也少不了，当然它的称法就有所不同，其对应的三步如下：

1. 由client上的CLI或者SDK进行proposal议案的提出。client会依据智能合约chaincode根据背书策略endorse policy决定把proposal发往哪些背书的peer节点，而peer节点进行投票，client汇总各背书节点的结果；
2. client将获得多数同意的议案连同各peer的背书（包括其投票结果以及背书签名）交给orderring service，而orderer会汇总各client递交过来的trasaction交易，排序、打包。
3. orderer将交易打包成区块block，然后通知所有commit peer，各peer各自验证结果，最后将区块block记录到自己的ledger账本中。

我们看一个具体的例子，若channel上有三个peer背书者，client提交流程如下图所示：

详细解释下上图的流程：

1. 首先，client发起一个transaction交易，含有<clientID, chaincodeID, txPayLoad, timestamp, clientSig>等信息，指明了3W要素：消息是谁who在什么时间when发送了什么what。该消息根据chaincode中的背书策略，发向EP1、EP2、EP3这三个peer节点。
2. 这三个peer节点模拟执行智能合约，并将结果及其各自的CA证书签名发还client。client收集到足够数量的结果后再进行下一步。
3. client将含背书结果的tx交易发向ordering service。
4. ordering service将打包好的block交给committing peer CP1以及EP1、EP2、EP3这三个背书者，背书者此时会校验结果并写入世界状态以及账本中。同时，client由于订阅了消息，也会收到通知。
   如果我们从编程的角度来看，则流程会更清楚：

参见上图，A是我们的应用程序，其步骤如下：

1. A首先连接到peer。
2. A调用chaincode发起proposal；与此同时，P1收到后先模拟执行，再产生结果返回给A。
3. A收到各peer返回的结果。
4. A向O1发起交易；与此同时，O1产生区块后会通知peer，而peer会更新其账本。
5. 最后通过订阅事件A收到了结果。

最后再细看下这三个阶段。

3.2.1 proposal提案阶段

可以看到，A1发出的<T1, P>，收到了<T1, R1, E1>和<T1, R2, E2>两个结果。

3.2.2 package打包阶段

O1在一个channel上会收到许多T交易，它会将T排序，在达到block的最大大小（一般应配1M以下，否则性能下降严重，kafka擅长处理小点的消息）或者达到超时时间后，打成区块P2。

3.2.3 验证阶段

O1将含有多条交易T打成区块的B2发往各peer节点，而P1和P2将B2加入各自的L账本中。

4、小结

本文偏重于概念的解释，由于篇幅所限，未涉及fabric的系统搭建（请参考笔者的这篇文章《区块链开源实现fabric快速部署及CLI体验》），也未描述共识算法在异常情况下如何维持一致性，这留待下一篇文章解决。fabric的许多思想是值得我们进一步研究的，其优秀的实现可以帮助我们通过fabric获得区块链在信任创新上的思路。

（转载本站文章请注明作者和出处 陶辉笔记 ，请勿用于任何商业用途）

一、前言

本教程在ubuntu20版本下运行，请在执行操作前先部署ubuntu20环境，所有部署都按照官方文档hyperledger fabric进行，在运行过程中遇到的问题，我也会逐个说明，如果你对于区块链还不太了解，请先查阅区块链概念，文中若有理解不对的地方，欢迎批评指正。

二、hyperledger fabric介绍

Hyperledger Fabric 是 Hyperledger （超级账本）中的区块链项目之一，也是经典的联盟链之一。它有一个账本，使用智能合约，由参与者管理交易的系统，但它又不完全去中心化，即想要加入联盟的成员们需要从可信赖的成员服务提供者（MSP）注册，以下是一些相关概念的介绍。

下图为Fabric的结构：

下图为Hyperledger Fabric 的结构,详解见区块链网络：

三、测试网络示例

3.1 搭建开发环境

1.安装git

sudo apt-get install git

2.安装curl

sudo apt-get install curl

3.安装docker

# 安装并检查版本
sudo apt-get -y install docker-compose
docker --version
docker-compose --version
# 提示，以后只要碰到docker有关的错误，先执行2.3.1步骤
#1.重启docker
sudo systemctl start docker
#设置系统启动时docker启动，可选
sudo systemctl enable docker
#2.将用户添加到docker组，确保在用户命令下可以执行
sudo gpasswd -a $USER docker
#3.更新用户组
newgrp docker   
# docker信息
docker info
# 测试docker，若报错详见文末附加问题1
docker run hello-world 

4.安装go

安装并解压：

mkdir ~/download
cd ~/download
# 下载
wget https://studygolang.com/dl/golang/go1.13.linux-amd64.tar.gz
# 解压
sudo tar -C /usr/local -xzf go1.13.linux-amd64.tar.gz

创建go目录并配置环境：

mkdir $HOME/go
#用vi打开~./bashrc，配置环境变量
vi ~/.bashrc
# 在最下方插入
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
#使配置的环境变量生效
source ~/.bashrc
#检查是否配置正确
go version
# 配置goproxy环境变量加速国内下载
go env -w  GOPROXY=https://goproxy.io

3.2 安装示例、二进制和 Docker 镜像

1.克隆 hyperledger/fabric-samples 仓库

mkdir -p $GOPATH/src/github.com/hyperledger
cd $GOPATH/src/github.com/hyperledger
# 获取fabric-samples源码
git clone https://github.com/hyperledger/fabric-samples.git

2.选择适当的版本标签，进入目录，切换分支

cd fabric-samples
# 可自行选择版本
git checkout release-2.2
#查看版本
git branch

3.将指定版本的 Hyperledger Fabric 平台特定二进制文件和配置文件安装到 fabric-samples 下的 /bin和 /config 目录中，下载指定版本的 Hyperledger Fabric docker 镜像
先配置镜像源：

sudo vi /etc/docker/daemon.json
#把以下代码加进去
{
"registry-mirrors":["https://registry.docker-cn.com"]
}

#如果你想要最新的生产发布版本，忽略所有的版本标识符。
# curl -sSL https://bit.ly/2ysbOFE | bash -s
# curl -sSL https://bit.ly/2ysbOFE | bash -s -- <fabric_version> <fabric-ca_version> <thirdparty_version>
# 若报错详见文末附加问题2
curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.2.0 1.4.7 0.4.18
# 若不行试试下面这个
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s  2.2.0 1.4.7 0.4.18

多试几次会成功的！

我们可以看到全部下载完毕了

cd chaincode-go
sudo vi go.mod
# 进入文件发现是1.14 自己把改成1.13 ，要与你下载的go版本匹配

环境变量设置

vi ~/.bashrc
# 添加下面的变量
export PATH=$PATH:$GOPATH/src/github.com/hyperledger/fabric-samples/bin
# 使之生效
source ~/.bashrc
# 检验成功否
fabric-ca-client version

3.3 使用Fabric测试网络

温馨提示：在你看到这里的时候，说明你的环境已经部署完毕，接下来要使用测试网络，需要注意的是一定要在一个完整的时间段操作，不要断断续续地执行下述操作，否则可能会出现大堆新手难解决的问题！

比较重要的一点，遇到问题时
开启debug模式！
开启debug模式！
开启debug模式！

export FABRIC_LOGGING_SPEC=debug

1.启动测试网络
进入fabric-samples下的test-network
先来分析一下network.sh脚本

# 脚本有500多行，在这讲解脚本里的一些方法
function clearContainers()# 清除容器
function removeUnwantedImages() # 清除不想要的镜像
# 大家仔细看看都能读懂，下面挑几个关键且常用的讲
#创建组织
function createOrgs() {
# 这里包含一些业务逻辑比如
# Create crypto material using cryptogen or Fabric CA
if [ "$CRYPTO" == "cryptogen" ];then...
if [ "$CRYPTO" == "Certificate Authorities" ]; then..
}
# 创建联盟
function createConsortium()
# 开启网络
function networkUp()
# 创建channel
function createChannel()
# 开启链码
function deployCC()
# 最后给出了一些确定操作模式并打印出我们所要求的内容
if [ "$MODE" == "up" ]; then
  infoln "Starting nodes with CLI timeout of '${MAX_RETRY}' tries and CLI delay of '${CLI_DELAY}' seconds and using database '${DATABASE}' ${CRYPTO_MODE}"
elif [ "$MODE" == "createChannel" ]; then
  infoln "Creating channel '${CHANNEL_NAME}'."
  infoln "If network is not up, starting nodes with CLI timeout of '${MAX_RETRY}' tries and CLI delay of '${CLI_DELAY}' seconds and using database '${DATABASE} ${CRYPTO_MODE}"
elif [ "$MODE" == "down" ]; then
  infoln "Stopping network"
elif [ "$MODE" == "restart" ]; then
  infoln "Restarting network"
elif [ "$MODE" == "deployCC" ]; then
  infoln "deploying chaincode on channel '${CHANNEL_NAME}'"
else
  printHelp
  exit 1
fi

if [ "${MODE}" == "up" ]; then
  networkUp
elif [ "${MODE}" == "createChannel" ]; then
  createChannel
elif [ "${MODE}" == "deployCC" ]; then
  deployCC
elif [ "${MODE}" == "down" ]; then
  networkDown
else
  printHelp
  exit 1
fi 

执行以下命令以执行脚本network.sh

./network.sh up

执行完毕后看到，我们创建了排序组织orderer、联盟成员org1的peer0节点和联盟成员org2的peer0节点以及相应的镜像image。

2.测试网络的组成部分
执行docker ps -a
可以看到创建的三个节点和之前测试的hello-world

Fabric网络成员的所有组织称为联盟，此测试网络有两个联盟成员org1、2，一个维护网络排序服务的组织orderer，每个组织各运营一个对等节点，peer0.org1.example.com和peer0.org2.example.com。
peer节点是fabric网络的基本组件，最常见的peer节点就是背书节点，对等节点存储区块链账本进行交易之前的验证。
该示例网络使用单节点Raft排序服务，以前的版本有solo模式和kafka模式，此测试仅使用单节点排序服务，但一个真实的网络将有多个排序节点，由一个或多个排序者组织。

3.创建一个channel

使用./network.sh createChannel 在org1和org2之间创建通道并加入他们的对等节点，如下有几种方法：

# 1.不输入自定义名称通道，默认为mychannel
./network.sh createChannel
# 2.输入自定义名称，可以创建多个不同名称通道
./network.sh createChannel -c channel1
./network.sh createChannel -c channel2
# 3.也可以建立网络创建通道一起
./network.sh up createChannel

4.在通道启动一个链码
在fabric 中，链码就是指的智能合约。
在创建通道后，开始部署链码与通道账本交互，链码包含区块链账本上资产的业务逻辑，用的go语言编写，后面会详细介绍。由成员运行的应用程序网络可以在账本上调用只能合约创建，更改和转让资产。
为确保交易有效，使用智能合约创建的交易需要多个组织签名才能提交到账本，也就是背书，而智能合约也定义了背书策略，比如需要成员2/3同意便通过，一半成员同意通过等等。
创建完通道，现在开始启动链码：

./network.sh deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -ccl go
# 出错详见附加问题3

如下图就是链码启动成功了

5.与网络交互
把fabric-samples的bin文件下的二进制文件添加到CLI路径：

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"
#CORE_PEER_TLS_ROOTCERT_FILE和CORE_PEER_MSPCONFIGPATH环境变量指向Org1的organizations文件夹中的的加密材料。
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

接下来可以调用链码（Go）的 InitLedger 方法来赋予一些账本上的初始资产，运行如下命令，用一些资产来初始化账本：

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":"InitLedger","Args":[]}'

如图，初始化成功！

接下来可以用CLI工具查询账本：

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

还可以转账或改变资产所有者（也就是数据库中的改操作）：

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"]}'

执行完后，我们再查询一下，发现ID为asset6的拥有者已经变成了Christopher，如图：

接下来我们可以通过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

再查询一下

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

结果和org1一样asset6转给了名叫Christopher的人

至此测试完毕，我们关闭网络./network.sh down

3.4 使用认证机构建立网络

Hyperledger Fabric使用公钥基础设施(PKI)来验证所有网络参与者的行为。 每个节点，网络管理员和用户提交的交易需要具有公共证书和私钥以验证其身份。 这些身份必须具有有效的信任根源，该证书是由作为网络中的成员组织颁发的。
在测试网络中，network.sh在创建节点之前就使用cryptogen工具创建了这些加密材料，现在让我们试试：

./network.sh up -ca

可以看到脚本启动了三个CA，分别是orderer、org1和org2。感兴趣的朋友在启动后查看一下脚本都做了些什么，在这里不做赘述。
下面我们还可以查看一下org1的MSP文件夹，其中包含了每个身份的证书和私钥：

tree organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/
# 如果没有tree请按照提示安装

#关闭网络
./network.sh down

四、汽车生产应用

4.1 搭建开发环境

安装python2.7，make，gcc，npm，开启远程服务以查看文档

sudo apt-get install python2.7
sudo apt-get install make
sudo apt-get install gcc
sudo apt install npm
# 安装
sudo apt-get install openssh-server
# 查看，存在sshd说明已启动
sudo ps -e |grep ssh
# 启动
sudo service ssh start

进入fabric-samples仓库下的fabcar，通过javasript版本的脚本来启动智能合约：

cd fabric-samples/fabcar
./startFabric.sh javascript
# 启动若报错，查看附加问题4

启动成功如图

4.2 注册登记等操作使用

本教程用 javascript 为nodejs编写的示例，先进入javascript文件夹：

cd javascript

该目录包含使用Node.js对应的Fabric SDK 开发的示例程序。运行以下命令安装应用程序依赖项：

npm install

完成后通过命令ls看一眼示例javaScript的应用文件：

在我们创建网络时，证书授权服务器（CA）将创建一个管理员用户（admin），第一步使用enroll.js生成私钥、公钥和x.509证书：

node enrollAdmin.js

创建完之后，CA管理员的证书保存在wallet目录，可以再admin.id找到证书和私钥。接下来再创建一个新的应用程序用户，它将被用于与区块链交互。 运行以下命令注册和记录一个名为 appUser 的新用户：

node registerUser.js

接下来我们来查询账本，最常用的查询是查询账本当前值（世界状态），我们先使用query.js来看看:

node query.js

如图为输出结果，我们可以看到查询数据为键值对，也就是json格式，当然我们也可以通过配置使用数据库（如CouchDB）来使用富查询。
感兴趣的朋友可以把query.js分析一下，里头都是一些定义很容易看懂。

4.3 智能合约

导航到 fabric-samples 仓库里 JavaScript版本的FabCar智能合约：

cd fabric-samples/chaincode/fabcar/javascript/lib

打开fabcar.js，里面描述了智能合约如何使用 Contract 类定义的

现在我们更改一下query.js的查询范围代码：

const result = await contract.evaluateTransaction('queryAllCars');
#改为
const result = await contract.evaluateTransaction('queryCar', 'CAR4');

这样保存后返回到fabcar/javascrip再执行：

node query.js

我们可以看到查询结构只变成了查询这一个车的数据

Wallet path: ...fabric-samples/fabcar/javascript/wallet
Transaction has been evaluated, result is:
{"color":"black","docType":"car","make":"Tesla","model":"S","owner":"Adriana"}

4.4 更新账本

刚才我们已经完成了一些账本的查询并添加修改查询，现在我们来更新账本（也就是数据库中的“增”）
我们打开invoke.js

好了，现在我们知道原理后开始执行

node invoke.js

执行完毕后把query.js修改为之前的查询世界状态的代码，再查看

node query.js

如图，我们可以看到CAR12已经被添加进了

还有修改功能：

# 这就是invoke.js中的submitTransaction功能，
# 把方法由createCar修改为changeCarOwner
await contract.submitTransaction('changeCarOwner', 'CAR12', 'Dave');

再查询一下node query.js，就可以看到车主已经变成"Dave"了。
至此，结束，返回到fabcar目录，清除数据，关闭测试网络：

./networkDown.sh

五、商业票据应用

本应用包含MagnetoCorp和DigiBank两个组织，它们使用区块链网络PaperNet相互交易商业票据，如图：

流程是这样的：
我是MagnetoCorp 的员工 Isabella，她将代表公司发行商业票据，然后转换角色，担任 DigiBank 的员工 Balaji，他将购买此商业票据，持有一段时间，再向 MagnetoCorp 赎回该商业票据，以获取小额利润。

5.1 运行网络

进入到fabric-samples中的commercial-paper目录，然后启动网络:

cd fabric-samples/commercial-paper
./network-starter.sh

注意这里的测试网络名称为fabric_test，官方教程写的net_test，注意下

通过docker ps命令查看Fabric节点在本地机器上的运行情况：

还可以通过docker network inspect fabric_test命令查看：

peer0.org1.example.com将属于DigiBank组织
peer0.org2.example.com将属于MagnetoCorp组织
启动的网络称为PaperNet
启动后将有八个容器产生，对应八个不同的IP地址，可以通过docker network inspect net_test命令查看：
1.Org1的peer——peer0.org1.example.com
2.Org2的peer——peer0.org2.example.com
3.Org1的peer对应的CouchDB数据库——couchdb0
4.Org2的peer对应的CouchDB数据库——couchdb1
5.排序服务节点——orderer.example.com
6.Org1的CA——ca_org1
7.Org2的CA——ca_org2
8.排序服务Org的CA——ca_orderer

5.2 以MagnetoCorp身份

管理员身份

先切换到MagnetoCorp目录：

cd commercial-paper/organization/magnetocorp

在MagnetoCorp目录下，运行下列命令以运行monitordocker.sh脚本， 并为运行在fabric_test上的与PaperNet相关联的容器 启动logspout工具:

# 如果是非最高权限用户，请在下列命令前加上sudo
./configuration/cli/monitordocker.sh fabric_test
#如果 monitordocker.sh 中的默认端口已经在使用，可以传入一个端口号
#./monitordocker.sh net_test <port_number>
./monitordocker.sh net_test 8079

开发人员身份

检查商业票据智能合约：
issue（发行），buy（购买），redeem（赎回）是PaperNet智能合约的三个核心功能。
打开一个新的终端代表MagnetoCorp开发人员：

cd commercial-paper/organization/magnetocorp

在contract/lib下的papercontract.js查看智能合约，其中包含了商业票据智能合约，定义了发行、购买、赎回和查询等交易方法。

将智能合约部署到通道：
在应用程序调用papercontract之前，必须将合约安装到测试网络中合适的peer节点上，接着在通道上使用Fabric链码生命周期定义它，因此需要以MagnetoCorp和DigiBank的管理员的身份来安装和审批同意链码。

一个链码中可以定义一个或多个智能合约，安装链码就使得PaperNet中不同组织可以使用其中的智能合约，同时也意味着只有管理员需要关注链码，其他人只需要关注智能合约。
以 MagnetoCorp 的身份安装和批准智能合约：
再打开一个命令端到cd commercial-paper/organization/magnetocorp下，管理员可以通过使用peer容器与PaperNet交互，还需要在命令窗口中设置一些环境变量，以使用正确的peer二进制文件，向MagneoCorp的peer节点的地址发送命令和使用正确的加密资料对请求进行签名：

# 打印完整环境变量并使用生效
source magnetocorp.sh

现在开始以管理员身份与网络交互：

1.安装papercontract智能合约
使用peer lifecycle chaincode package将智能合约打包成链码

# 创建链码包
peer lifecycle chaincode package cp.tar.gz --lang node --path ./contract --label cp_0

使用peer lifecycle chaincode install命令在MagnetoCorp的peer节点上安装链码

peer lifecycle chaincode install cp.tar.gz
# 若报错，见附加问题6

2.同意（验证）链码定义
先查询一下在peer上的链码的packageID：

peer lifecycle chaincode queryinstalled

接下来，需要把packageID保存为一个环境变量

export PACKAGE_ID=cp_0:ddca913c004eb34f36dfb0b4c0bcc6d4afc1fa823520bb5966a3bfcf1808f40a

再使用如下命令同意链码定义：

peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name papercontract -v 0 --package-id $PACKAGE_ID --sequence 1 --tls --cafile $ORDERER_CA

为了使用链码定义，通道成员需要同意最重要的链码参数之一是背书策略，背书策略描述了在确定交易有效之前必须背书的组织集合。通过不指定–policy标志而同意papercontract链码，我们在这里同意了使用通道的默认Endorsement策略——要求通道上大多数组织来背书交易，所有的交易无论有效与否都会被记录在区块链账本上，但只有有效的交易才会更新世界状态。

5.3 以 DigiBank 的身份

1.以 DigiBank 的身份安装和批准智能合约
基于mychanner的LifecycleEndorsement策略，Fabric链码生命周期将要求通道上大多数组织将链码提交到通道之前同意链码的定义，即两者都同意（MagnetoCorp和DigiBank）。切换到digibank环境部署：

cd commercial-paper/organization/digibank/
source digibank.sh

现在以DigiBank的身份安装和同意papercontract，操作方法同MagnetoCorp相同：

# 打包链码
peer lifecycle chaincode package cp.tar.gz --lang node --path ./contract --label cp_0
# 安装链码
peer lifecycle chaincode install cp.tar.gz
# 查询安装链码的packageID
peer lifecycle chaincode queryinstalled
# 将id保存为环境变量
# export PACKAGE_ID=cp_0: <packageID>
export PACKAGE_ID=cp_0:ddca913c004eb34f36dfb0b4c0bcc6d4afc1fa823520bb5966a3bfcf1808f40a
# Digibank管理员同意papercontract的链码定义：
peer lifecycle chaincode approveformyorg --orderer localhost:7050 --ordererTLSHostnameOverride orderer.example.com --channelID mychannel --name papercontract -v 0 --package-id $PACKAGE_ID --sequence 1 --tls --cafile $ORDERER_CA

至此，两个组织都同意了papernet链码，这也意味着通道上的客户端应用程序就可以调用papercontract链码中的ConmmercialPaper智能合约。在这里我们继续使用DigiBank管理员的身份操作，使用peer lifecycle chaincode commit命令 将papercontract的链码定义提交到mychannel：

peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --peerAddresses localhost:7051 --tlsRootCertFiles ${PEER0_ORG1_CA} --peerAddresses localhost:9051 --tlsRootCertFiles ${PEER0_ORG2_CA} --channelID mychannel --name papercontract -v 0 --sequence 1 --tls --cafile $ORDERER_CA --waitForEvent

可以看到两个peer节点上启动了papercontract容器，至此已经将papercontract代码部署到通道，接下来使用MagnetoCorp应用程序来发行商业票据。

5.4 应用结构

包含在 papercontract 中的智能合约由 MagnetoCorp 的应用程序 issue.js 调用，我们来看看cd commercial-paper/organization/magnetocorp/application，在这个目录下有个issue.js

从上图中看到代码前面定义了一些引入，现在我们把这些引入的包先安装下来：

# 切换目录
cd commercial-paper/organization/magnetocorp/application/
# 安装依，这个命令会把当前包下所有js文件中引入的依赖下载
npm install
# 查看目录
ls

我们查看node_modules会发现已经安装了很多包，这是因为js-yaml 和 fabric-network 本身都被搭建在其他 npm 包中！package-lock.json 文件能准确识别已安装的版本。

5.5 钱包

因为 issue.js 代表 Isabella，所以也就代表 MagnetoCorp， issue.js 将会使用 Isabella 钱包中反应以上事实的身份。现在我们需要执行这个一次性的活动，向 Isabella 的钱包中添 X.509 证书。
运行node enrollUser.js把身份信息添加到她的钱包中：

我们再通过ls ../identity/user/isabella/wallet/查看钱包里有什么：

Isabella可以在她的钱包中存储多个身份， 但在我们的示例中，她只使用一个。 wallet文件夹里有一个isabella.id文件， 该文件提供Isabella连接到网络所需的信息。

5.6 发行应用

Isabella 现在可以用 issue.js 来提交一项交易，该交易将发行 MagnetoCorp 商业票据 00001：

node issue.js

Process issue transaction response.
{“class”:“org.papernet.commercialpaper”,
“currentState”:1,
“issuer”:“MagnetoCorp”,
“paperNumber”:“00001”,
“issueDateTime”:“2020-05-31”,
“maturityDateTime”:“2020-11-30”,
“faceValue”:5000000,
“mspid”:“Org2MSP”,
“owner”:“MagnetoCorp”}

5.7 DigiBank应用

现在我们使用DigiBank的身份来使用buy和redeem操作：

cd commercial-paper/organization/digibank/application/

详细看看这个目录下的两个文件

操作过程和MagnetoCorp一样：

# 安装依赖
npm install
# 注册用户
node enrollUser.js

与Isabella一样，这里添加了一个balaji的身份信息到DigiBank的钱包中，用于买和赎交易，接下来我们来试试买和赎吧！

# 购买
node buy.js
# 赎回
node redeem.js

最后别忘了把这些数据都清理掉：

cd fabric-samples/commercial-paper
sudo ./network-clean.sh

如果你需要第二次执行，需要手动删除一些文件夹，比如digibank和magnetocorp下的identity文件夹，npm install的包node_moudle，
只有删除了，第二次执行这些代码才能成功，又或者不再执行安装依赖的代码也可以。

附加问题

1. Got permission denied while trying to connect to the Docker daemon socket at…
   解决办法：
   执行指令的账户没有权限，我在执行指令所使用的账户是普通账户，没有root权限,要么切换成root用户，要么把现在的用户加进来，一定要记得更新用户组！

   	#将用户添加到docker组，确保在用户命令下可以执行
   	sudo gpasswd -a $USER docker
   	#更新用户组
   	newgrp docker
   

2. curl: (7) Failed to connect to raw.githubusercontent.com port 443: 拒绝连接
   解决办法：
   打开网站: https://www.ipaddress.com/
   查询一下 raw.githubusercontent.com对应的IP 地址
   
   
   到命令行输入sudo vi /etc/hosts

   #添加一行：
   #【查询到的任一 ip 】raw.githubusercontent.com，我这里是：
   185.199.108.133 raw.githubusercontent.com
   

   可能会失败，多试几次，我大概下载命令重复执行了6-8次才成功！

3. Chaincode installation on peer0.org1 has failed
   超过执行的最后日期了 context deadline exceeded，可能其他操作也会造成这个，注意进行这些操作的时候一定要一气呵成，不要挂起虚拟机或者中断操作，否则会有一大堆问题，另一个，记住要备份，快照，这样就可以退回到上一个节点，避免重新删除改来改去。

4. Error: chaincode install failed with status: 500 - failed to invoke backing implementation of ‘InstallChaincode’: could not build chaincode: docker build failed: docker image build failed: docker build failed: Error returned from build: 1 "+ INPUT_DIR=/chaincode/input
   错误：链码安装失败，状态：500 - 无法调用“InstallChaincode”的支持实现：无法构建链码：docker构建失败：docker映像构建失败：docker构建失败：从构建返回错误：1 “+ INPUT_DIR=/chaincode/input
   这个问题就是docker构建出问题了，因为我之前挂起了虚拟机，docker容器没有重新启动，重新启动试试看：

   systemctl restart docker
   

5. Could not resolve host: github.com
   拉取镜像发现这个问题，可能是网络没了，看看你右上角的网络图标还在吗？如果不在了，请执行以下命令：

   sudo service network-manager stop
   sudo rm /var/lib/NetworkManager/NetworkManager.state
   sudo gedit /etc/NetworkManager/NetworkManager.conf
   

   

   #把false改成true，再重启网络
   sudo service network-manager restart
   

6. peer lifecycle chaincode install cp.tar.gzError: chaincode install failed with status: 500 - failed to invoke backing implementation of ‘InstallChaincode’: could not build chaincode: docker build failed: docker image build failed: docker build failed: Error returned from build: 1 "+ INPUT_DIR=/chaincode/input+ OUTPUT_DIR=/chaincode/output+ cp -R /chaincode/input/src/. /chaincode/output+ cd /chaincode/output+ ‘[’ -f package-lock.json -o -f npm-shrinkwrap.json ]+ npm install --production
   npm ERR! code EAI_AGAIN
   npm ERR! errno EAI_AGAIN
   npm ERR! request to https://registry.npmjs.org/fabric-shim failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org
   npm ERR! A complete log of this run can be found in:
   npm ERR! /root/.npm/_logs/2022-05-24T06_09_07_419Z-debug.log
   
   查了很多外网资料，都说是go的版本问题，换到go1.13即可，我之前用的是go1.18。

结语

以上就是所有官方示例的解析与操作，本人已经把官方教程的坑基本踩完，供各位新接触hyperledger fabric的朋友参考，后续学习以及本人即将要部署的区块链项目还会更新在区块链专题中。如有不对之处，欢迎指正；如有其他问题欢迎留言，如对您有帮助的话，请帮我点个赞！

1. 编写Node.js应用程序

应用程序开发人员使用composer-clientnpm模块以编程方式连接到已部署的业务网络，创建，读取，更新和删除资产和参与者并提交事务。如果应用程序需要能够部署或管理业务网络，则composer-admin可以使用npm模块。

样本landregistry.js文件包含代表土地登记处的类别，并包含列出土地标题，添加默认标题和提交交易的方法。这已使用JavaScript类实现; 但是你可以自由地构建你的代码，只要你愿意。

值得强调的是API的风格是使用承诺。通常，Hyperledger Composer API将返回在操作成功完成时解决的承诺，或者返回操作结果（如果适用）。

如果您不熟悉基于Promise的开发，那么值得在线查看一些教程以获取想法。除此之外，在节点8中，现在支持async / await，这使得开发异步应用程序变得更加容易。这里显示的示例使用await并假定代码包含在具有async属性的函数中

需要模块

const BusinessNetworkConnection = require('composer-client').BusinessNetworkConnection;

对于Hyperledger Composer客户端应用程序，这是唯一需要的npm模块。

连接到Hyperledger Composer运行时

BusinessNetworkConnection实例已创建，然后用于连接到运行时：

this.bizNetworkConnection = new BusinessNetworkConnection();

我们要在这里创建的第一个Hyperledger Composer API调用是connect（）API，用于在Hyperledger Fabric上建立与Hyperledger Composer运行时的连接。需要提供适当的cardName用于连接，例如admin@digitalproperty-network可能是有效的卡名称，具体取决于数字资产网络的部署方式。如果成功，此API将对商业网络定义返回一个承诺：

let this.businessNetworkDefinition = await this.bizNetworkConnection.connect(cardName);

对于客户端应用程序来说，这是所有必需的必要设置，从这一点上来看应用程序想要做什么来调用哪些API。

将资产添加到注册表

Hyperledger Composer运行时将为每种建模资产创建一个默认注册表。所以在这个例子中，一个LandTitle注册表已经被创建。我们在这里要做的是访问该注册表，然后添加一些资产。该getAssetRegistry()方法采用CTO模型文件中定义的完全合格资产名称（即名称空间加上资产类型的名称）。它返回一个与资产注册表一起解决的承诺：

this.titlesRegistry = await this.bizNetworkConnection.getAssetRegistry('net.biz.digitalPropertyNetwork.LandTitle');

下一步是创建一些资产（_bootstrapTitles在代码中查找方法）

工厂样式模式用于创建资产。工厂从businessNetworkDefinition获得，用于创建业务网络中定义的所有类型的实例。请注意使用名称空间和资产名称。然后我们可以设置这个资产的属性。这里的标识符（firstName lastName）与模型中定义的属性匹配。

let factory = this.businessNetworkDefinition.getFactory();
owner = factory.newResource('net.biz.digitalPropertyNetwork', 'Person', 'PID:1234567890');
owner.firstName = 'Fred';
owner.lastName = 'Bloggs';

我们现在有一个人！现在我们需要一个土地所有权。请注意业主如何被指定为我们刚创建的人。（在实际的示例代码中，我们通过两次代码创建landTitle1和landTitle2）。

let landTitle2 = factory.newResource('net.biz.digitalPropertyNetwork', 'LandTitle', 'LID:6789');
landTitle2.owner = owner;
landTitle2.information = 'A small flat in the city';

我们现在创建了一个需要存储在注册表中的土地所有权。

await this.titlesRegistry.addAll([landTitle1, landTitle2]);

这是使用API​​添加多个标题，这会返回在添加资产时解决的承诺。我们需要做的最后一件事是添加Person，Fred Bloggs。由于这是“参与者”，因此使用getParticipantRegistry API。

let personRegistry = await this.bizNetworkConnection.getParticipantRegistry('net.biz.digitalPropertyNetwork.Person');
await personRegistry.add(owner);

将资产列入注册表中

在示例应用程序中，这是以不同的方法处理的list()。与放置资产相同的设置是必需的，所以在我们需要获取资产注册表之前，我们称之为getAll（）API。这将返回一个对象数组。

let registry = await this.bizNetworkConnection.getAssetRegistry('net.biz.digitalPropertyNetwork.LandTitle');
let aResources = await registry.getAll();
let table = new Table({
    head: ['TitleID', 'OwnerID', 'First Name', 'Surname', 'Description', 'ForSale']
});
let arrayLength = aResources.length;
for (let i = 0; i < arrayLength; i++) {
    let tableLine = [];
    tableLine.push(aResources[i].titleId);
    tableLine.push(aResources[i].owner.personId);
    tableLine.push(aResources[i].owner.firstName);
    tableLine.push(aResources[i].owner.lastName);
    tableLine.push(aResources[i].information);
    tableLine.push(aResources[i].forSale ? 'Yes' : 'No');
    table.push(tableLine);
}
  // Put to stdout - as this is really a command line app
return table;

其中大部分不是Hyperledger Composer API代码 - 但它显示了如何访问已返回的对象的详细信息。在这一点上，值得再看看这个模型。

asset LandTitle identified by titleId {
  o String   titleId
  o Person   owner
  o String   information
  o Boolean  forSale   optional
}

participant Person identified by personId {
  o String personId
  o String firstName
  o String lastName
}

您可以看到如何以非常简单的方式访问所有者和标题信息。

提交交易

我们需要做的最后一件事是提交交易。这是模型文件中事务的定义：

transaction RegisterPropertyForSale identified by transactionId{
  o String transactionId
  --> LandTitle title
}

该交易在这里有两个字段，一个trandsactionId，以及对应该提交出售的土地所有权的引用。第一步是访问登陆注册地的标题，并找回我们要提交出售的具体土地所有权。

let registry = await this.bizNetworkConnection.getAssetRegistry('net.biz.digitalPropertyNetwork.LandTitle');
await registry.get('LID:1148');

getAssetRegistry调用现在应该看起来有点熟悉，get API用于获取特定的土地标题。下一步是创建我们想要提交的事务。

let serializer = this.businessNetworkDefinition.getSerializer();

let resource = serializer.fromJSON({
  '$class': 'net.biz.digitalPropertyNetwork.RegisterPropertyForSale',
  'title': 'LID:1148'
});

await this.bizNetworkConnection.submitTransaction(resource);

我们需要做的是创建一个'序列化器'。这是能够创建一个资源 - 这个资源然后传递给submitTransaction API。请注意，事务JSON与模型文件中指定的结构匹配。

2. 编写Web应用程序

要与已部署的业务网络进行交互，Web应用程序应该创建REST API调用。要为业务网络创建自定义REST API，请使用该composer-rest-server命令。

要创建可与REST API交互的骨架Angular应用程序，请使用该yo hyperledger-composer命令。

请按照开发者教程中关于如何使用composer-rest-server和Angular生成器的例子。

从业务网络存档（.BNA）生成Angular应用程序

构建Angular应用程序的流程如下所示：

如果您已经拥有Business Network Archive并希望构建骨架Angular应用程序，请使用以下参考说明，如果您想全面了解如何从头开发BNA并从此构建应用程序，请参阅开发人员教程。

先决条件

• 您将需要Hyperledger Composer 开发工具才能运行Angular生成器。
• 您想要部署的业务网络存档（.BNA）。

1.启动在本地机器上运行的Hyperledger Fabric

如果您已经安装了开发工具，则将安装Hyperledger Fabric。

前往fabric-dev-servers目录并启动Hyperledger Fabric。如果您使用了我们的开发工具安装指南，以下代码是一个示例：

cd ~/fabric-dev-servers
./startFabric.sh
./createPeerAdminCard.sh

这也将创建一个PeerAdmin.card文件，它需要修改在部署的同位体上运行的代码。

您可以随时通过运行以下命令列出您已安装的所有卡：

composer card list

2.准备Hyperledger Fabric对等体

为了将业务网络存档安装到Hyperledger Fabric网络上，您需要将业务网络安装到对等设备上。建议您从一个干净的目录开始。将您的BNA移入该目录并将终端目录更改为该目录。

您需要拥有业务网络存档才能执行此操作，下面您可以看到一个示例tutorial-network以及用于部署的“PeerAdmin”卡。

composer network install --card PeerAdmin@hlfv1 --archiveFile tutorial-network@0.0.1.bna

3.在Hyperledger Fabric上启动您的业务网络

我们将使用该composer network start命令启动业务网络，我们将需要使用我们的PeerAdmin卡来完成此操作。我们还需要在我们的网络上创建用户，我们将使用“管理员”用户名和密码开始。

以下是使用tutorial-networkBNA 的示例。

composer network start --networkName tutorial-network --networkVersion 0.0.1 --networkAdmin admin --networkAdminEnrollSecret adminpw --card PeerAdmin@hlfv1

这将为业务网络创建一个“管理员”卡，在前面的例子中就是这样 admin@tutorial-network.card

请注意：admin用户名和adminpw密码是针对为开发者教程中部署的Hyperledger Fabric实例配置的特定Hyperledger Fabric标识。如果您已从头开始配置Hyperledger Fabric实例，则这些身份详细信息将有所不同。

4.安装“管理员”卡准备好使用

接下来我们将采用我们刚刚制作的管理卡，并将其导入以用于您的业务网络。

composer card import --file admin@tutorial-network.card

5.启动REST服务器并生成Swagger API文档

导航到您的目录并运行该composer-rest-server命令。

composer-rest-server

• 输入admin @ tutorial-network作为卡片名称。确保不要添加.card扩展名。
• 询问是否在生成的API中使用名称空间时，请选择不使用名称空间。
• 当询问是否保护生成的API时选择否。
• 当询问是否启用事件发布时，选择是。
• 当被问及是否启用TLS安全时，请选择否。

剩下的服务器将在http：// localhost：3000 / explorer上生成并可用

6.生成Angular应用程序

Angular应用程序需要运行其他服务器才能连接到Fabric实例。确保您在执行此操作时已在后台运行REST服务器。运行Yeoman生成器时，您还需要与.BNA文件位于同一目录中。

yo hyperledger-composer

按照下面的内容输出匹配。

Welcome to the Hyperledger Composer project generator
? Please select the type of project: Angular
You can run this generator using: 'yo hyperledger-composer:angular'
Welcome to the Hyperledger Composer Angular project generator
? Do you want to connect to a running Business Network? Yes
? Project name: [insert]
? Description: Hyperledger Composer Angular project
? Author name: [insert]
? Author email: [insert]
? License: Apache-2.0
? Name of the Business Network card: admin@tutorial-network
? Do you want to generate a new REST API or connect to an existing REST API?  Connect to an existing REST
 API
? REST server address: http://localhost
? REST server port: 3000
? Should namespaces be used in the generated REST API? Namespaces are not used
Created application!

生成的应用程序将位于Project name上面输入的子目录内。

最后进入这个目录并运行应用程序，运行：

npm start

它将在http：// localhost：4200上可用

3. 订阅活动

Node.js应用程序可以通过使用composer-client.BusinessNetworkConnection.onAPI调用来订阅来自业务网络的事件。事件在业务网络模型文件中定义，并由事务处理函数文件中的指定事务处理。有关发布事件的更多信息，请参阅发布事件。

在你开始之前

在应用程序可以订阅事件之前，您必须已经定义了一些事件以及将发出它们的事务。业务网络也必须部署，并且您必须具有可连接到它的连接配置文件。

程序

1. 应用程序必须发送特定的API调用以订阅业务网络中事件发出的事务。目前，订阅事件的应用程序将接收所有发出的事件。API调用应采用以下格式：

businessNetworkConnection.on('event', (event) => {
    // event: { "$class": "org.namespace.BasicEvent", "eventId": "0000-0000-0000-000000#0" }
    console.log(event);
});

这包括BasicEvent在发布事件文档中创建的一个事件。该eventId属性总是transactionId与发送事件的事务相同，并在表单中附加一个数字"transactionId": "<transactionId>#number"。