02-HyperLeger Fabric系统架构

1、企业级区块链常见模块

一些常用的功能模块有：应用程序、成员管理、智能合约 、 账本 、共识机制、事件机制、系统管理等 。 纵轴代表用户或者开发者更关心的内容，越往上代表用户更关注，比如应用程序和钱包等，越靠下是开发者更关注的模块，比如事件机制 。 而横轴则是从时间的维度来看的，左边是一开始关注的功能，直到完成所有的功能。

HyperLeger Fabric1.X是一种通用的区块链技术，其设计目标是利用一些成熟的技术实现分布式账本技术（Distributed Leger Technology,DLT)。超级账本采用模块化架构设计，复用通用的功能模块和接口。其设计具有主要特点：

①模块插件化： 很多模块功能可插拔（如CA模块、共识算法、状态数据库存储、ESCC、VSCC、BCCSP等）都是可插拔，系统提供了通用的接口和默认的实现。

②充分利用容器技术: 不仅节点使用容器作为运行环境，链码也默认运行在安全的容器中。应用程序或外部系统不能直接操作链码，必须通过背书节点提供的接口转发给链码来执行。

③可扩展性：Peer节点的角色有多种，背书节点（Endorser)、排序服务节点（Orderer)、记账节点（Committer)等。节点可以加入到不同通道（Channel)中，链码可以运行在不同的节点上。

④ 安全性：提供了授权访问的区块链网络，节点共同维护成员信息，MSP(Member Service Provider)模块验证、授权了最终用户后才能使用区块链网络功能。多链多通道设计容易实现隔离，提供了应用程序和链码之间的安全通道，实现隐私保护。

2、系统逻辑架构

上层从应用程序的角度，提供了标准的 gRPC 接口，在 API 的基础之上封装了不同语言的 SDK，包括 Golang 、 Node.js 、Java 、 Python 等，开发人员可以利用 SDK 开发基于区块链的应用 。

区块链强一致性要求，各个节点之间达成共识需要较长的执行时间，也是采用异步通信的模式进行开发的，事件模块可以在触发区块事件或者链码事件的时候执行预先定义的回调函数。 下面分别从应用程序和底层的角度分析应该关注的几个要素 。

2.1 应用程序角度：

身份管理	用户注册和登录系统后，获取到用户注册证书（ ECert），其他所有的操作都需要与用户 证书关联的私钥进行签名，消息接收方首先会进行签名验证，才进行后续的消息处理 。 网 络节点同样会用到颁发的证书，比如系统启动和网络节点管理等都会对用户身份进行认证 和授权 。
账本管理	授权的用户是可以查询账本数据（ ledger）的，这可以通过多种方式查询，包括根据区 块号查询区块 、 根据区块哈希查询区块、根据交易号查询区块、根据交易号查询交易，还 可以根据通道名称获取查询到的区块链信息
交易管理	账本数据只能通过交易执行才能更新，应用程序通过交易管理提交交易提案（ Proposal) 并获取到交易背书（ Endorsement）以后，再给排序服务节点提交交易，然后打包生成区 SDK 提供接口，利用用户证书本地生成交易号，背书节点和记账节点都会校验是否存在重 复交易 。
智能合约	实现“可编程的账本”（ Programmable Ledger），通过链码执行提交的交易，实现基于区 块链的智能合约业务逻辑 。 只有智能合约才能更新账本数据，其他模块是不能直接修改状 态数据（ World State ）的 。

2.2 底层角度：

成员管理	MSP (Membership Service Provider）对成员管理进行了抽象，每个 MSP 都会建立一套根信任证书（ Root of Trust Certificate ）体系，利用 PKI(Public Key Infrastructure ） 对成员身份进行认证，验证成员用户提交请求的签名 。 结合 Fabric-CA 或者第三方CA 系统，提供成员注册功能，并对成员身份证书进行管理，例如证书新增和撤销 。 注册的证书分为注册证书（ ECert ） 、 交易证书（ TCert）和 TLS 证书（ TLS Cert），它们分别用于用户身份、交易签名和 TLS 传输。
共识服务	在分布式节点环境下，要实现同一个链上不同节点区块的一致性，同时要确保区块里 的交易有效和有序 。 共识机制由 3 个阶段完成：客户端向背书节点提交提案进行签名背书， 客户端将背书后的交易提交给排序服务节点进行交易排序，生成区块和排序服务，之后广 播给记账节点验证交易后写入本地账本 。 网络节点的 P2P 协议采用的是基于 Gossip 的数据 分发，以同一组织为传播范围来同步数据，提升网络传输的效率。
链码服务	智能合约的实现依赖于安全的执行环境，确保安全的执行过程和用户数据的隔离 。 Hyperledger Fabric 采用 Docker 管理普通的链码，提供安全的沙箱环境和镜像文件仓库 。 其 好处是容易支持多种语言的链码，扩展性很好 。 Docker 的方案也有自身的问题，比如对环 境要求较高，占用资源较多，性能不高等，实现过程中也存在与 Kubernetes 、 Rancher 等平 台的兼容性问题。
安全和密码服务	全问题是企业级区块链关心的问题，尤其在关注国家安全的项目中 。 其中底层 的密码学支持尤其重要， Hyperledger Fabric 1.X 专门定义了一个 BCCSP ( BlockChain Cryptographic Service Provider），使其实现密钥生成、哈希运算、签名验签、加密解密等基 础功能 。 BCCSP 是一个抽象的接口，默认是软实现的国标算法，目前社区和较多的厂家都 在实现国密的算法和 HSM (Hardware Security Module ） 。

3、网络节点架构

节点是区块链的通信主体，是一个逻辑概念 。 多个不同类型的节点可以运行在同一物理服务器上 。有多种类型的节点：客户端 、 Peer 节点 、排序服务节点和 CA 节点 。

3.1 客户端节点

客户端或者应用程序代表由最终用户操作的实体，它必须连接到某一个 Peer 节点或者排序服务节点上与区块链网络进行通信 。客户端向背书节点（ Endorser）提交交易提案(Transaction Proposal），当收集到足够背书后，向排序服务广播交易，进行排序，生成区块 。

3.2 Peer节点

所有的 Peer 节点都是记账节点（ Committer），负责验证从排序服务节点区块里的交易，维护状态数据和账本的副本 。 部分节点会执行交易并对结果进行签名背书，充当背书节点的角色 。

①背书节点是动态的角色，是与具体链码绑定的 。每个链码在实例化的时候都会设置背书策略，指定哪些节点对交易背书后才是有效的 。 也只有在应用程序向它发起交易背书请求的时候才是背书节点，其他时候就是普通的记账节点，只负责验证交易并记账。

②Peer 节点还有一种角色是主节点（ Leader Peer），代表的是和排序服务节点通信的节点，负责从排序服务节点处获取最新的区块并在组织内部同步 。可以强制设置为主节点，也可以动态选举产生 。

③有的节点同时是背书节点和记账节点，也可以同时是背书节点、主节点和记账节点，也可以只是记账节点

3.3 排序服务节点

排序服务节点（ Ordering Service Node 或者 Orderer）接收包含背书签名的交易，对未打包的交易进行排序生成块，广播给 Peer 节点 。 排序服务提供的是原子广播（ Atomic Broadcast ） ，保证同一个链上的节点接收到相同的消息，并且有相同的逻辑顺序 。排序服务的多通道（ MultiChannel ）实现了多链的数据隔离，保证只有同一个链的 Peer节点才能访问链上的数据，保护用户数据的隐私 。

排序服务可以采用集中式服务，也可以采用分布式协议 。 可以实现不同级别的容错处理，目前正式发布的版本只支持 Apache Kafka 集群，提供交易排序的功能，只实现 CFT( Crash Fault Tolerence ，崩溃故障容错），不支持 BFT ( Byzantine Fault Tolerance ，拜占庭容错） 。

3.4 CA节点

CA 节点是 Hyperledger Fabric 1.X 的证书颁发机构（ Certificate Authority ），由服务器和客户端组件组成 。 CA 节点接收客户端的注册申请，返回注册密码用于用户登录，以便获取身份证书 。 在区块链网络上所有的操作都会验证用户的身份 。CA 节点是可选的，可以用其他成熟的第三方 CA 颁发证书 。

4、典型交易流程

假定各节点已经提前颁发好证书，且已正常启动，并加入已经创建好的通道 。 后面的步骤介绍在已经实例化了的链码通道上从发起一个调用交易到最终记账的全过程，如图：

4.1 创建交易提案并发送给背书节点

①交易提案（SignedProposal ）由消息头（Header）和消息结构（Payload）组成，并且添加了调用者的签名信息（Signature） ，背书节点会根据签名信息验证其是否是一个有效的消息。

消息头包括通道头（ChannelHeader）和签名头（SignatureHeader）两部分。

通道头：通道头包含了与通道（Channelid）和链码（Chaincode）调用相关的信息，比如在哪个通道上调用哪个版本的链码 。 Txld 是应用程序本地生成的交易号，跟调用者的身份证书相关，可以避免交易号的冲突，背书节点和记账节点都会校验是否存在重复交易。

签名头：签名头包含了调用者的身份证书和一个随机数，用于消息的有效性校验 。

消息结构在后面的章节再详细展开，主要包括调用链码ID，调用参数等。

②应用程序构造好交易提案请求后，选择背书节点执行并进行背书签名 。 背书节点是链码背书策略里指定的节点 。有一些背书节点是离线的，其他的背书节点可以拒绝对交易进行背书，也可以不背书 。应用程序可以尝试使用其他可用的背书节点来满足策略 。应用程序以何种顺序给背书节点发送背书请求是没有关系的 ，正常情况下背书节点执行后 的结果是一致的，只有背书节点对结果的签名不一样 。

4.2 背书节点模拟交易并生成背书签名

背书节点在收到交易提案后会进行一些验证，包括：

①交易提案的格式是否正确 ；

②交易是否提交过（重复攻击保护）；

③交易签名有效（通过 MSP );

④交易提案的提交者在当前通道上是否已授权有写权限。

验证通过后，背书节点会根据当前账本数据模拟执行链码中的业务逻辑并生成读写集 （ RwSet ），其中包含响应值 、 读写集等 。 在模拟执行时账本数据不会更新 。 而后背书节点对这些读写集进行签名成为提案响应 （ Proposal Response），然后返回给应用程序 。

返回的 ProposalResponse 中包含了读写集、背书节点签名以及通道名称等信息。

4.3 收集交易的背书

应用程序收到 ProposalResponse 后会对背书节点签名进行验证，所有节点接收到任何消息后都是需要先验证消息合法性的 。

如果链码只进行账本查询，应用程序会检查查询响应，但不会将交易提交给排序服务节点 。

如果链码对账本进行 Invoke 操作， 则须提交交易给排序服务进行账本更新，应用程序会在提交交易前判断背书策略是否满足 。 如果应用程序没有收集到足够的背书就提交交易了，记账节点在提交验证阶段会发现交易不能满足背书策略，标记为无效交易 。

4.4 构造交易请求并发送给排序服务节点

应用程序接收到所有的背书节点签名后，根据背书签名调用 SDK 生成交易，广播给排序服务节点 。 生成交易的过程比较简单，确认所有的背书节点的执行结果完全一致，再将交易提案 、 提案响应和背书签名打包生成交易 。

应用程序可以把生成的交易信封内容发送给任意选择的几个排序服务节点 。

4.5 排序服务节点以对交易进行排序并生成区块

排序服务要做得很简单，先是接收网络中所有通道发出的交易信息，读取交易信封的Envelope.Payload.Header.ChannelHeader.Channelld 以获取通道名称，按各个通道上交易的接收时间顺序对交易信息进行排序，生成区块。

排序服务不读取交易的内容，如果在生成交易信封内容的时候伪造了交易模拟执行的结果，排序服务节点也不会发现，但会在最终的交易验证阶段校验出来并标记为无效交易 。

4.6 排序服务节点以广播方式给组织的主节点

排序服务节点生成区块以后会广播给通道上不同组织的主节点。

4.7 记账节点验证区块内容并写入区块

记账节点接收到的是排序服务节点生成的区块，验证区块交易的有效性，提交到本地账本后再产生一个生成区块的事件，监听区块事件的应用程序可以进行后续的处理。 如果接收到的区块是配置区块，则会更新缓存的配置信息。

背书节点是动态角色，只要参与交易的背书就是背书节点，哪些交易选择哪些节点作为背书节点是由应用程序选择的，这需要满足背书策略才能生效 。 所有的背书节点都属于记账节点 。 所有的 Peer 节点都是记账节点，记录的是节点已加入通道的账本数据 。

具体记账流程我们在下一个学习章节详述。

4.8 在组织内部同步最新的区块

主节点在组织内部同步区块 。

（本节结束）

注：参考资料-《深度探索区块链：Hyperledger技术与应用》作者：张增骏，董宁，朱轩彤，陈剑雄 著 出版社：机械工业出版社

欢迎阅读其他章节，我会陆续更新，期待关注，共同学习提高。

01 -区块链概述
02-HyperLeger Fabric系统架构
03-详述HyperLeger Fabric 记账流程 （即将更新）