区块链和HyperLedger Fabric（五）共享账本

peer ledger：存储在背书节点和记账节点

orderer ledger:存储在order service node

Chaincode是无状态的。Chaincode存储在节点上，账本只会存储hash值

账本的隔离和隐私性用多通道（Multiple Channels）技术来保护

Query System Chaincode(QSCC)

背书节点需提前设定，也作为记账节点

transaction事务处理流1X

• client应用(向一个或多个Peer节点（背书节点）)发送交易请求(对事务的背书请求)；

• 背书节点模拟执行ChainCode，但并不将结果提交到本地账本（World state,不会修改底层账本），只是将结果（读写集）加密签名返回给client应用；

• 应用收集所有背书节点的结果后，验证背书策略是否满足和模拟执行结果是否一致（去除不确定无效的交易，10未实现）将结果广播给Orderers；

• Orderers执行共识过程，并生成Block，通过消息通道批量的将Block发布给Peer节点（记账节点）；

• 各个Peer节点验证交易，并提交到本地账本中通知client端处理结果

记账节点Committing Peer：维护账本和状态

合约部署都需要指定背书策略。AND,OR,OutOf

背书策略在chaincode实例化时指定

ESCC

VSCC

账本保存Blockchain和World state（维护当前状态，方便应用快速查询）

Block（s）：Block header（Block number，当前区块hash，前区块hash），Block data，Block Metadata（写入时间，写入人，签名）

transactions：header（名字，version），签名，proposal（input参数），Pesponse（执行结果前后的数据），Endorsements（背书节点返回的结果list）

World State：kv形式。维护账本当前信息

Smart Contract：业务角度。定义组织的业务规则，创建交易，记录到账本，打包进chaincode。 *** 作World state DB：get，put，delete（put和delete会增加新的记录，block。只会删除world state的数据，在账本里新增记录）

chaincode可以包含多个合约，实现打包的角度

Chaincode Lifecycle

打包（签名，）--安装（peer）--实例化--运行

更新--运行

一个peer可以安装多个chaincode

System Chaincode

运行在peer上，LSCC(Lifecycle)，CSCC（配置），QSCC（查询）

Peer

Leader Peer：连接order推送新的区块，随机传播其它记账节点。选举方式（静态指定，动态生成）。一个分区一个leader。

Anchor Peer：（Gossip协议，降低order负担）节点相互认识。

共识：读写集

网络搭建：

1配置启动order Service

2配置启动peer

3安装chaincode

4创建channel

5加入channel

6实例化chaincode

configtxyaml是Hyperledger Fabric区块链网络运维工具configtxgen用于生成通道创世块或通道交易的配置文件，configtxyaml的内容直接决定了所生成的创世区块的内容。

configtxyaml主要用到了以下YAML语法：

当byfnsh脚本执行networkUp启动网络时，会调用generateChannelArtifacts创建Orderer通道的创世区块，应用通道配置配置交易文件channeltx。根据不同的共识机制，传入不同的profile参数。

Profiles配置段用来定义用于configtxgen工具的配置入口。包含consortium的配置入口，可以用来生成排序节点的创世区块。如果在排序节点的创世区块中正确定义了consortium 的成员，那么可以仅使用机构成员名称和委员会的名称来生成通道创建请求。

Capabilities段定义了fabric程序要加入网络所必须支持的特性。通过定义通道的能力，就明确了不满足该能力要求的fabric程序，将无法处理 交易，除非升级到新的版本。

Organizations配置段用来定义组织机构实体，以便在后续配置中引用。

Fabric主要通过策略(Policy)来控制各种场景下访问这些资源的权限限制。Fabric实现了两种类型的Policy来满足不同的场景需求：

Orderer配置段用来定义要编码写入创世区块或通道交易的排序节点参数。

Channel配置段用来定义要写入创世区块或配置交易的通道参数。

Application配置段用来定义要写入创世区块或配置交易的应用参数。

coreyaml配置文件是Peer节点的示例配置文件，该coreyaml示例配置文件中共指定了六大部分内容。

Fabric是联盟链，Peer代表一系列组织，Peers是整个区块链网络的基础，因为它是账本和智能合约的载体。通过智能合约，账本通过不可篡改的方式记录了交易的全过程。

对于不能的公司来说，是有不同的业务的，不同的业务又与不同的公司相关联，需要创建多个联盟链，因此就需要创建多个channel，channel是多个特定成员之间以机密交易为目的建立的私网，一个peer可以加入多个channel，每个channel维护自己的账本，账本和账本之间是隔离的，每个channel可以维护一个或多个账本。所以为了满足复杂的交易需求，每个peer上可以安装不同的智能合约，当peer交易完成时，会发送事件通知Client。peer上还有一个Local MSP（成员服务提供器）服务，提供身份认证和加密签名等功能。

WorldState 以key-value的形式，维护着当前账本的当前信息。

智能合约（Smart Contract）是区块链的核心，定义了各个不同组织间的业务规范，创建交易并记录在账本里。多个智能合约可以打包到一个链码中。只有链码（Chaincode）部署之后，智能合约才能被应用使用。

不同于一般的链码运行在一个独立的容器，系统链码运行在peer进程上，实现了一些系统行为。

Fabric为了优化网络性能，提高安全性和可扩展性，将每个交易分到 Endorsing Peer 、 Ording-Service 和 Committting Peer 三个部分，这就需要一种安全的，可信的和可扩展的数据传输协议——Gossip Protocol。 Gossip 传输协议以随机的方式将信息散播到网络中，主要执行三个功能：

在Hyperledger Fabric中，共识机制是通过Peer节点之间的通信和协作来完成的，而不是像传统的区块链系统一样在所有节点上扫描区块。

在共识过程中，Peer节点会将自己持有的交易打包成区块，并将该区块发送给其他参与共识的Peer节点。这些节点会对区块进行验证，并使用共识算法（如Raft、Kafka等）达成一致，最终确定该区块是否可添加到区块链中。如果达成共识，该区块将被添加到区块链中，并广播到网络中的所有节点。

在这个过程中，并不需要对整个区块链进行扫描，因为共识只需要验证最新区块即可。因此，Peer节点只需要保留区块链中的最新区块，并使用共识算法来确保该区块的完整性和正确性，从而避免了全网扫描区块的需要，提高了系统的性能和可扩展性。

设置网络结构配置

    节点的类型：

    Peer(做校验的，执行交易更新账本的)

    Order（构造区块和排序）

    客户端（有SDK， java/go,）-> 客户端就是执行链码 生成交易

联盟链： 网络中运行多条链，比如很多机构，各自数据是隔离的

2个机构，各自有两个节点， order可共享

Crypto-configyamlfabric-tools(网络结构配置 生成证书等等)

docker run --rm -v `pwd`:/data  hyperledger/fabric-tools:x86_64-110 \

        cryptogen generate --config=/data/crypto-configyaml --output=/data/crypto-config

生成证书

配置创世链块configtxyaml -> 生成genesisblock（创世区块）

docker run -v `pwd`:/data -e FABRIC_CFG_PATH=/data --rm  hyperledger/fabric-tools:x86_64-110 \

        configtxgen -profile TwoOrgsOrdererGenesis -outputBlock /data/configtx/genesisblock

目前只有系统链（testchainid）

所以要创建自己的链，需要两种数据块，一是链的数据块，二是锚节点配置数据块（一条链上的每一个节点都有个锚节点，互相通信，每个组织都有一个数据配置块）

docker run -v `pwd`:/data -e FABRIC_CFG_PATH=/data --rm  hyperledger/fabric-tools:x86_64-110 \

        configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate /data/configtx/Org1MSPanchors_hellotx -channelID hello -asOrg Org1MSP

docker run -v `pwd`:/data -e FABRIC_CFG_PATH=/data --rm  hyperledger/fabric-tools:x86_64-110 \

        configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate /data/configtx/Org2MSPanchors_hellotx -channelID hello -asOrg Org2MSP

创建区块（链的区块）

docker run -v `pwd`:/data -e FABRIC_CFG_PATH=/data --rm  hyperledger/fabric-tools:x86_64-110 configtxgen -profile TwoOrgsChannel -outputCreateChannelTx /data/configtx/hellotx -channelID hello

启动节点容器（docker-compose）

把数据加到链上去

docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/crypto-config/peerOrganizations/org1 fireflycim/users/Admin@org1fireflycim/msp \

            -e CORE_PEER_LOCALMSPID="Org1MSP" \

            cli peer channel create -o ordererfireflycim:7050 -c hello -f /opt/configtx/hellotx

docker exec cli mv /helloblock /opt/configtx/

Build Your First network提供了一个 fabric 的示例网络。该示例网络中由两个组织构成，每个组织维护两个 peer 节点，演示了基于链码查询2个账户余额与转账 *** 作。

first-network 中有一个启动脚本 byfnsh，利用构建的 Docker 镜像快速启动网络。该脚本会启动一个 orderer 节点和四个归属两个不同组织的 peer 节点，还将启动一个cli运行脚本，它将 peer 节点加入通道（Channel）、部署和实例化链码，并根据已部署的链码驱动交易执行，以下是byfnsh的帮助文档。

执行/byfnsh up -o etcdraft启动脚本，指定使用raft共识算法

通过cryptogen工具生成组织成员关系和身份z书、密钥等文件。调用configtxgen工具生成节点与通道配置文件，包括Orderer节点上系统通道的创世区块文件genesisblock，新建应用通道的配置交易文件channeltx、组织锚节点配置更新交易文件Org1MSPanchorstx与Org2MSPanchorstx等。

用户执行network_setupsh脚本启动Fabric网络，该脚本调用networkUp函数，该命令会检查网络实体的证书是否生成，如果没有则首先生成相关证书目录。

generateCerts主要执行了cryptogen generate --config=/crypto-configyaml

根据crypto-configyaml生成网络成员组织结构和对应的身份z书、签名私钥等文件，并保存到默认的crypto-config目录，身份z书等文件在对应的目录msp/ 中，TLS证书与密钥文件保存到tls/ 中。

crypto-configyaml主要包含的fabric排序节点证书配置以及fabric组织证书配置。

Template 模板定义节点的配置模式

Specs 另外一种配置模式

Count 节点总数

Hostname 全限定域名 命名格式

Domain 域名

Users 添加到管理员的用户帐户数

采用Specs模式配置了5个排序节点

采用Template模式配置了两个组织，每个组织2套公私钥和证书，包含普通User数量为1

ordererOrganizations目录 ：包含Orderer组织类型的身份z书pem文件、签名私钥文件 _sk文件、TLS证书（证书crt文件和密钥key文件）

peerOrganizations目录 ：包含Peer组织类型的身份z书pem文件、签名私钥文件 _sk文件、TLS证书（证书crt文件和密钥key文件）

这些文件通过docker-compose工具，基于docker-compose-cilyaml、docker-compose-baseyaml等配置文件，将目录作为挂载卷到容器的指定目录。

调用replacePrivateKey基于docker-compose-e2e-templateyaml文件创建新的配置文件docker-compose-e2eyaml。进入Org1组织的CA目录，获取私钥文件名作为PRIV_KEY，替换docker-compose-e2eyaml文件的CA1_PRIVATE_KEY。同理替换CA2_PRIVATE_KEY。

执行generateChannelArtifacts函数，使用configtxgen工具基于configtxyaml创建节点与通道配置文件，包括Orderer通道的创世区块，应用通道配置配置交易文件channeltx，锚节点配置更新交易文件Org1MSPanchorstx和Org2MSPanchorstx

Orderer系统通道的创世区块

执行configtxgen命令，创建Orderer创世区块文件genesisblock

新建应用通道的配置交易文件

执行configtxgen命令，创建应用通道的配置交易文件channeltx，后续执行peer channel create读取文件。

锚节点配置更新交易文件

执行configtxgen命令，创建锚节点配置更新交易文件Org1MSPanchorstx和Org2MSPanchorstx，后续执行peer channel update进行更新。

返回到network_setupsh脚本，判断是否启用了CouchDB标志位（默认关闭），使用docker-Compose工具执行docker-Compose-cilyaml文件，启动Fabric网络。

继续分析network_setupsh脚本，默认COMPOSE_FILES是docker-compose-cliyaml文件，当设置了kafka共识或者raft共识，则使用对应的yaml文件。

Orderer节点继承了docker-compose-baseyaml中的ordererexamplecom配置属性，Orderer节点容器启动时执行如下命令

docker-compose-cilyaml文件

继续追踪base/docker-compose-baseyaml，找到ordererexamplecom服务，挂载目录和暴露7050端口。

orderer的配置还是引入peer-baseyaml中的orderer-base服务

4个Peer节点继承了docker-compose-baseyaml中对应容器名称的配置属性，Peer节点容器启动时执行如下命令

docker-compose-cilyaml文件中Peer节点配置。

docker-compose-baseyaml文件中Peer节点的配置。

引入peer-baseyaml中的peer-base服务

docker-compose-cilyaml文件中CLI客户端配置。启动完 orderer 节点、peer 节点和 CLI 容器之后，实际是调用 scriptsh 脚本，该脚本是在 CLI 容器中执行，CLI 容器其实就是用户客户端，只不过是命令行客户端，运行在容器中。默认情况下CLI 的身份是 adminorg1，连接 peer0org1 节点，执行 scriptsh 脚本

scriptsh脚本顺序执行默认的测试流程，包括创建新的应用通道、添加节点、更新锚节点、安装链码、实例化链码、调用链码、查询链码等 *** 作。

Fabric要求创建、加入与更新通道的权限必须具有通道组织的管理员身份。调用setGlobals设置全局环境变量，CLI客户端能够灵活切换指定容器的管理员角色，可以直接连接并 *** 作指定的Peer节点，先切换到Peer0/Org1节点。

接着采用Org1管理员身份执行peer指令，将通道配置文件Channeltx发送给Orderer节点，创建mychananel的应用通道。如果创建成功，则返回一个创世区块block，它会存储在 peer 节点的文件系统中，包含 channeltx 指定的通道配置信息。

遍历所有节点，调用setGlobals切换指定节点，执行peer指令，将Org1组织包含的Peer0/Org1和Peer1/Org1节点加入mychananel应用通道，将创世区块mychananelblock设置成命令行参数。Org2组织类似。

joinChannelWithRetry 函数中的 setGlobals 是设置 CLI 容器的环境变量的函数。例如：setGlobals 1 2 设置 CLI 的身份为 adminorg2，连接 peer1org2 节点。

使用 peer channel join 命令让节点加入通道，$CHANNEL_NAMEblock 就是前面创建通道成功时返回的区块，该区块在上面 org1peer0 创建通道时保持在 CLI 容器内，所以能直接使用。节点成功加入通道后会创建 CHANNEL_NAMEblock 开头的链。

一个组织只能有一个锚节点，节点加入通道后才能进行更新，连续两次调用updateAnchorPeers，更新两个组织的锚节点配置，用Org1管理身份更新Peer0/Org1的配置，并指定锚节点配置更新文件Org1MSPanchorstx，Org2组织同理。

连续两次调用installChaincode分别在Peer0/Org1和Peer2/Org2中安装chaincode_example02链码，并将链码命名为“mycc”且版本10，如果链码安装成功，在指定安装目录/var/hyperledger/production/chaincodes下存在nameversion的链码文件。

实例化链码必须在安装过链码的节点上进行，同一个通道内所有节点上相同的实例化数据在通道账本中是共享的，用户只需要在任意一个Peer节点上成功执行一次实例化链码 *** 作，并通过排序打包后将实例化数据广播到其他节点上，通道内所有合法节点都可以访问该链码的实例化数据。

实例化将链码添加到通道上，启动目标节点的容器，初始化与链码相关的初始值，这里的初始值为 ["a","100","b","200"]。”实例化“ 过程会产生链码的容器，例如： dev-peer0-org1examplecom-mycc-10 。实例化过程需要指定背书策略，通过 -P 参数设置，这里的策略定义为 AND ('Org1MSPpeer','Org2MSPpeer') ，表示任何交易必须要有 org1 和 org2 节点的共同背书。

Peer0/Org1上调用链码查询函数chaincodeQuery和链码调用函数chaincodeQuery。查看A的余额，并从账户A中向账户B中转账10元。

Peer3/Org2上安装链码，执行查询A的余额，检查余额是否为90元，如果是说明转账成功。

节点示意图

1 客户端节点

      客户端或应用程序代表由最终用户 *** 作的实体，它必须连接到某一个Peer节点或者排序服务节点上与区块链网络进行通信。客户端向背书节点（Endorser

Peer）提交交易提案(Proposal)，当收集到足够背书后，向排序服务节点广播交易，进行排序，生成区块。

2 CA节点

      CA节点是fabric的证书颁发节点(Certificate Authority)，由服务器(fabric-ca-server)和客户端(fabric-ca-client)组成。

      CA节点接收客户端的注册申请，返回注册密码用于登录，以便获取身份z书。在区块链网络上所有的 *** 作都会验证用户的身份。

      CA节点是可选的，也可以用其他成熟的第三方CA颁发证书。

3 Peer节点

      从上图中可以看出每个组织可以拥有一到多个Peer节点。每个Peer节点可以担任如下多种角色：

Endorser Peer（背书结点）

Leader Peer（主节点）

Committer Peer（记账节点）

Anchor Peer（锚节点）

注：每个Peer节点必定是一个记账节点，除记账节点外，它也可以担任其它一到多种角色，即某个节点可以同时是记账节点和背书节点，也可以同时是记账节点、背书节点、主节点，锚节点。

31 Endorser Peer（背书结点）

      部分节点会执行交易并对结果进行签名背书，充当背书节点的角色。

      所谓背书(Endorsement)，就是指特定peer执行交易并向生成交易提案( proposal )的客户端应用程序返回YES/NO响应的过程。

      背书节点是动态的角色，是与具体链码绑定的。每个链码在实例化的时候都会设置背书策略(Endorsement policy)，指定哪些节点对交易背书才有效。

      也只有在应用程序向节点发起交易背书请求时才成为背书节点，其他时候是普通的记账节点，只负责验证交易并记账。

在实例化链码时指定的：

peer chaincode instantiate -o

ordererexamplecom:7050 -C mychannel -n mychannel -c '{"Args":["init","A","10","B","10"]}' -P "OR ('Org1MSPmember')"-v 10

-P注明了只有Org1的成员才可以进行背书

32 Leader Peer（主节点）

      从图中可以看出，主节点负责和Orderer排序服务节点通信，从排序服务节点处获取最新的区块并在组织内部同步。可以强制设置，也可以选举产生。

配置路径：

/opt/gopath/src/githubcom/hyperledger/fabric/aberic/docker-peeryaml

33 Committer Peer（记账节点）

      负责验证从排序服务节点接收的区块里的交易，然后将块提交（写入/追加）到其通道账本的副本。记账节点还将每个块中的每个交易标记为有效或无效。

34 Anchor Peer（锚节点）

      在一个通道(

channel )上可以被所有其他peer发现的peer，通道上的每个成员都有一个Anchor Peer(或多个Anchor peer 来防止单点故障)，允许属于不同成员的peer发现通道上的所有现有peer。

配置路径：

/opt/gopath/src/githubcom/hyperledger/fabric/aberic/configtxyaml

src/test/fixture/sdkintegration/e2e-2Orgs/configtxyaml

4 Orderer（排序服务节点）

     排序服务节点接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给Peer节点。

     排序服务提供的是原子广播，保证同一个链上的节点为接收到机同的消息，并且有相同的逻辑顺序。

     排序服务独立于peer进程存在并且以先来先服务的方式对网络上的所有信道进行排序交易。排序服务旨在支持超出现有的SOLO和Kafka品种的可插拔实现。排序服务是整个网络的公共绑定; 它包含绑定到每个成员的加密身份材料。

5 总结

     Fabric系统是通过组织来划分的，每个组织内都包含承担不同功能的Peer 节点，每个Peer节点又可以担任多种角色。所有的组织共用一个统一的Orderer集群。因此在设计基于Hyperledger Fabric的系统时需要考虑组织之间的业务关系，以及内部每个模块之间的联系，以此来进行统一的规划。

超级账本是Linux基金会发起的项目，意在提供一套企业级区块链应用框架，便于大家开发基于区块链技术的应用。

Fabric的基本概念

最开始，应用程序会选出一组peer来生成账本更新提议。哪些peer会被选出来是依据的背书策略，这个背书策略决定了哪些组织需要在广播账本更新提议前对更新提议进行背书。这会影响到共识方式，任何一个关心更新提议是否背书的组织都会在广播给peer更新提议并被peer接受前确认提议是否有背书。

peer对一个提议响应进行背书，就是把自己的数字签名加入到响应中，并用自己的私钥对整个响应签名。背书内容随后可以被用于证明这个响应是某个组织的peer生成的。在我们的例子中，如果peer P1属于组织1(Org1)，那么背书E1就相当于可以证明L1上的交易T1和响应R1是由Org1的peer P1提供的。

当应用程序得到了足够多的签名的提议响应时，第一阶段就结束了。

我们注意到peer可能返回不同的信息，因此同一笔交易可能有不一致的返回信息。这可能由于响应是在不同时间，不同peer，在不同账本状态下生成的，大多数情况下应用程序可以多次请求更新的提议响应。另外更严重，但概率很小的原因是因为链码的不确定性导致的响应不一致。不确定性是链码和账本的大敌，如果这种情况发生了，对提议交易来说是很严重的，不一致的提议响应肯定不能提交到账本中。一个独立的节点是不可能知道交易结果是非确定性的交易，在检测到非确定性交易前，必须将交易汇总比较(严格地说，即使这还不够，但我们将此讨论推迟到交易部分，其中详细讨论了非确定性)。

在第一阶段结束时，如果应用程序希望如此的话，可以放心丢弃不一致的响应以提前结束交易流程。后面我们会看到如果应用程序使用不一致的响应提交到账本时，会被拒绝。

过程2 打包

第二个交易流程是打包。Orderer节点这个过程关键的点，它接收来自很多应用传来的背书过的提议交易响应。Orderer对交易进行排序，并将大量的交易打包进区块，并准备将区块分发到所有连接到Orderer的peer，包括背书peer。

orderer的第一个角色就是打包账本更新提议。在上图的例子中，应用A1发送给Orderer O1一个被E1和E2背书的交易T1。同时，应用A2发送给Orderer O1一个被E1背书的交易T2。O1将A1传来的交易和A2传来的交易以及其它交易共同打包进区块B2。我们可以看到区块B2里的交易排序是T1，T2，T3，T4，T6，T5，并不一定是按照到达orderer节点的顺序(这个例子展示了一个非常简单的orderer配置)。

Orderer节点会同时收到网络Channel中不同应用程序发送的账本更新提议。Orderer节点的任务就是按照事先定义好的顺序整理这些更新提议，并把它们打包进区块，为下一步的分发做准备。这些区块将构成区块链。一旦Orderer节点生成了期望大小的区块，或者超过最大等待时间，Orderer会向连接到它特定Channel的Peer发送区块。第三个过程会详述这个流程。

区块中的交易排列顺序和交易到达Orderer节点的顺序没有直接关系。交易在区块中可以是任意的排列顺序，这个次序就是交易执行的顺序。重点是有一个严格的交易排序，但具体是怎样的排序并不重要。

区块中的严格交易顺序排列使得Fabric与公链中一笔交易可以被打包进多个不同区块的情况不同。在Fabric中，这不可能发生，由多个Orderer生成的区块就是最终的区块，因为交易被写入区块后，交易的位置顺序就确定了。这意味着Fabric不会存在分叉。一旦交易被写入区块，以后就不能再重写了。

我们可以看到，peer是存储账本和链码的，orderer完全不会存储这些。每一笔交易到达orderer时，orderer只是机械的将交易打包进区块，而不会理会交易的价值，额度等。这是Fabric的一个重要特性，所有交易都会按照一个严格的顺序进行整理，没有交易会被抛弃掉。

到第二阶段结束时，我们可以了解到orderer的责任就是进行必要的，简单的收集交易更新提议，将他们排序，打包进区块，准备分发出去。

过程3 认证

最后一个交易工作流程是分发和验证从orderer到peer的区块，如果验证成功，将会被提交到账本中。

特别的，在每个peer中，在区块中的每一笔交易在更新到账本之前都是验证过的，以保证所有交易都是由相关的组织背书过的。失败的交易会保留，作为日后审查用，并不会更新到账本中。

Orderer除了在过程2中的打包角色外，在过程3中还负责分发区块到peer节点。在这个例子中，O1分发区块到P1和P2。P1处理区块2，然后将区块2添加到P1的账本L1中。同时，P2处理区块2，然后将区块2添加到P2的账本L1中。一旦 *** 作完成，账本L1在P1和P2中都被更新了，每个Peer都可以向连接到他们的应用程序发送处理结果。

Orderer向连接到他的Peer分发区块是过程3的开始。连接到orderer节点的某个渠道的peer，会收到orderer生成的新区块的一份拷贝。每个peer节点都会独立的处理收到的区块，但所有peer处理区块的方式都是相同的。采用这种方式，不同peer中的账本可以达成共识。并不是所有的peer都必须连接到orderer节点，peer和peer之间可以通过gossip协议来传递区块，这样peer也可以独立的处理相同区块。

收到一个区块后，peer会按照交易在区块中出现的顺序依次处理。对于每一笔交易，peer会按照生成这笔交易的链码背书策略检查交易是否被与之相关组织的背书。例如，某些交易可能只需要一个组织背书，而另一些交易需要多个组织同时背书才有效。这个验证过程验证了所有相关组织产生的结果或者输出是否一致。同时请注意，第三阶段的验证和第一阶段不同，阶段一只是应用程序收到背书节点的响应，判断是否需要发送交易提议。如果应用程序发送错误的交易，违反了背书策略，在第三阶段的验证过程中peer还是可以拒绝本次交易。

如果交易背书正确，peer将尝试把交易提交到账本中。为了能写账本，peer必须进行账本一致性检查，保证当前账本的状态与账本更新后的状态一致。这个状态并不总会是一致的，即使交易拥有完整的背书。举个栗子，另外一笔交易可能已经更新了账本中的同一个资产，以至于我们正要更新的交易将永远不会被写入账本。这样的话，每个节点中的账本必须通过网络保持共识，每个节点的验证方式是一样的。

在peer验证完每笔独立交易后，将更新账本。失败的交易会保存下来作为审查资料。这意味着peer中的区块和从orderer中收到的区块一致，除了区块中指示交易成功或失败的标志。

我们也要注意到，第三阶段并没有执行链码，这一步只会在第一阶段完成，这很重要。这意味着链码只在背书节点可用，而不是整个网络中都可用，这保证了链码在背书组织中的安全及私密。这和收到链码的执行结果不同，执行结果会分享到所有在Channel里的peer，不论他是否能背书交易。背书节点的这种设计方式是为了方便扩展。

最后，每次区块被提交到peer的账本中时，这个peer会生成对应的事件。区块事件包含区块的所有内容，而区块交易事件只包含简要信息，比如每笔区块中的交易是否有效。由链码的执行而产生的链码事件也可以在这个时候发布。应用程序可以注册这些事件，当这些事件发生时，可以收到通知。这些通知在交易工作流程的第三阶段和最后阶段完成。

总的来说，我们可以知道第三阶段由orderer产生的区块被不断地同步到账本中。区块中交易的严格排序能让每个peer在区块链网络中始终如一地验证交易并提交到账本中。

Orderer和共识

整个交易工作流程被称为共识，因为所有peer都认同交易的排序和内容，在执行过程中由orderer节点来协调。共识是多步骤的过程，应用程序只会在共识过程结束时收到通知，但通知的时间在不同的peer上可能不同。

我们将会在后面更多的探讨orderer，现在，把orderer仅仅当做从应用程序收集、分发账本更新提议到peer，由peer进行验证及更新账本的过程。

以上就是关于区块链和HyperLedger Fabric（五）共享账本全部的内容，包括:区块链和HyperLedger Fabric（五）共享账本、Hyperledger Fabric 介绍几个关键配置文件（三）、初识Hyperledger Fabric等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！