1。企业级区块链系统中常见的模块构成

1。Hyperledger Fabric 1.0是一种通用的区块链技术，其设计目标：

利用一些成熟的技术实现分布式账本技术（Distributed Ledger Technology,DLT）

2。超级账本采用模块化架构设计，复用通用的功能模块和接口。

3。模块化的方法带来了可扩展性，灵活性等优势，会减少模块修改，升级带来的影响，能很好地利用微服务实现区块链应用系统的开发和部署。

4。Hyperledger Fabric 1.0设计如下几个特点：

【1】。模块插件化

很多的功能模块（如：CA模块，共识算法，状态数据库存储，ESCC，VSCC，BCCSP等）都是可插拔的，系统提供了通用的接口和默认的实现。这满足了大多数的业务需求。这些模块也可以根据需求进行扩展，集成到系统中。

【2】。充分利用容器技术

不仅节点使用容器作为运行环境，链码也默认运行在安全的容器中。应用程序或者外部系统不能直接操作链码，必须通过背书节点提供的接口转发给链码来执行。容器给链码运行提供的是安全沙箱环境，把链码的环境和背书节点的环境隔离开，链码存在安全问题也不会影响到背书节点。

简略图：

应用程序/外部系统-》背书节点（提供接口）-》链码（智能合约）

【3】。可扩展性

Hyperledger Fabric 1.0在0.6版本的基础上，对peer节点的角色进行了拆分，有背书节点（Endorser），排序服务节点（Orderer），记账节点（Committer）等。不同角色的节点有不同的功能。节点可以加入到不同的通道（channel）中，链码可以运行在不同的节点上，这样可以更好的提升并行执行的效率和吞吐量。

peer节点拆分为：

A。背书节点(Endorser)    B。排序服务节点（Orderer）  C。记账节点（Committer） D。其他。

【4】。安全性

Hyperledger Fabric 1.0提供的是授权访问的区块链网络，节点共同维护成员信息，MSP（Membership Service Provider）模块验证，授权了最终用户后才能使用区块链网络的功能。多链和多通道的设计容易实现数据隔离，也提供了应用程序和链码之间的安全通道，实现了隐私保护。

2。系统逻辑架构

Hyperledger Fabric 1.0设计的系统逻辑架构图：

对照英文架构图：

说明：上述Hyperledger Fabric 1.0设计的系统逻辑架构图是从不同角度划分的。

上层从应用程序角度，提供了标准的gRPC接口。

在API基础上封装了不同语言的SDK，包括：Golang，Node.js，java，Pyhon等。开发人员可利用SDK开发基于区块链的应用。

区块链强一致性要求，各个节点之间达成共识需较长时间，也是采用异步通信的模式进行开发的。

事件模块可在触发区块事件或链码事件时，执行预先定义的回调函数。

【1】。应用程序角度（关注要素）

（一）。身份管理

用户注册/登录系统--》获取用户注册证书（ECert）。其他所有操作均需与“用户证书关联的私钥”进行【签名】

消息接收方：首先：签名验证   -》  再进行：消息处理

网络节点同样会用到颁发的证书，如系统启动和网络节点管理等都会对用户身份进行认证和授权。

（二）。账本管理

授权的用户可以查询账本数据（ledger），可通过多种方式查询：

【1】。根据区块号查询区块

【2】。根据区块哈希值查询区块

【3】。根据交易号查询区块

【4】。根据交易号查询交易

【5】。可根据通道名称获取查询到的区块链信息

（三）。交易管理

账本数据只能通过交易执行才能更新。

应用程序通过“交易管理提交交易提案（Proposal）”并获取到“交易背书（Endorsement）”后，再给“排序服务节点提交交易”，然后“打包生成区块”。

SDK提供接口，利用用户证书本地生成“交易号”，“背书节点”和“记账节点”都会校验是否存在重复交易。

（四）。智能合约

实现“可骗程的账本”（Programmable Ledger），通过链码执行提交的交易，实现基于区块链的智能合约业务逻辑。

只有智能合约才能更新账本数据，其他模块是不能直接修改状态数据（world state）的。

【2】。底层角度（关注要素）

从Hyperledger Fabric 1.0底层角度，如何实现“分布式账本技术”，给应用程序提供区块链服务。

（一）。成员管理

MSP（Membership Service Provider）对成员管理进行了抽象。

每个MSP都会建立一套“根信任证书”（Root of Trust Certificate）体系，

利用PKI(Public Key Infrastructure)对成员身份进行认证，验证成员用户提交请求的签名。

结合Fabric-CA/第三方CA系统，提供成员注册功能，并对成员身份证书进行管理（如：证书新增/撤销）

注册的证书分为：

【1】注册证书（ECert）：用于用户身份

【2】交易证书（TCert）：用于交易签名

【3】TLS证书（TLS Cert）：用于TLS传输

（二）。共识服务

在分布式节点环境下，实现同一个链上不同节点区块的一致性，且要确保区块里的交易有效和有序。

共识机制由3个阶段完成：

【1】。客户端向背书节点提交提案进行签名背书（客户端-》背书节点）

【2】。客户端将背书后的交易提交给排序服务节点进行交易排序，生成区块和排序服务（客户端-》背书后的交易-》排序服务节点）

【3】。排序服务节点广播给记账节点验证交易后写入本地账本（排序服务节点-》区块数据-》记账节点）

网络节点的p2p协议采用的是基于Gossip的数据分发，以同一组织为传播范围来同步数据，提升网络传输效率。

（三）。链码服务

智能合约的实现依赖于安全的执行环境，确保安全的执行过程和用户数据隔离。

采用Docker管理普通链码，提供安全的沙箱环境和镜像文件仓库。

好处：

    容易支持多种语言链码，扩展性好。

不足：

    对环境要求高，占用资源多，性能不高。实现过程也存在kubernetes,Rancher等平台的兼容性问题。

（四）。安全和密码服务

【1】。BCCSP（BlockChain Cryptographic Service Provider）：（是一个抽象的接口，默认实现国标算法）

          实现密钥生成，哈希运算，签名验签，加密解密等基础功能。 

【2】。国密算法和HSM（Hardware Security Module）

3。网络节点架构

说明：

节点是区块链通信的主体，是一个逻辑概念。

多个不同类型的节点可运行在同一物理服务器上。

有多种类型节点：客户端，Peer节点，排序服务节点，CA节点。

（一）。网络节点架构图

说明：

主节点：代表是和排序服务节点通信的节点。负责从排序服务节点处获取最新的区块并在组织内部同步。

            可强制设置主节点也可动态选举产生。

上述节点类型：

【1】。客户端节点

客户端/应用程序：是最终用户操作的实体，它必须连接到某一个Peer节点/排序服务节点上与区块链网络进行通信。

客户端 向 背书节点（Endorser）提交“交易提案”（Transaction Proposal），当收集到足够背书后，向排序服务广播交易，进行排序，生成区块。

【2】。peer节点

所有的Peer节点都是记账节点（Committer）。

主要负责：

A。验证排序服务节点区块里的交易

B。维护状态数据和账本的副本

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

“背书节点”是动态角色，是与具体链码绑定的。

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

【3】。排序服务节点（Order）

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

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

C。排序服务的多通道（Multichannel）实现了多链的数据隔离，保证只有同一个链的peer节点才能访问链上的数据，保证用户数据的隐私。

D。排序服务可采用集中式服务，也可采用分布式协议。可实现不同级别的容错处理。

     目前正式发布的版本只支持Apache Kafka集群，提供交易排序的功能。

     只实现CFT（Crash Fault Tolerence，崩溃故障容错），不支持BFT（Byzantine Fault Tolerance，拜占庭容错）

【4】。CA节点

CA节点是Hyperledger Fabric 1.0的证书颁发机构（Certificate Authority），由服务器和客户端组件组成。

CA节点接收客户端注册申请-》返回“注册密码”，用于用户登录（以便获取身份证书）。

在区块链网络上所有的操作都会验证用户的身份。CA节点为可选，可用其他成熟的第三方CA颁发证书。

4。Hyperledger Fabric 1.0 典型交易流程

上述，假定各节点已经提前颁发好证书 & 正常启动 & 已加入创建好的通道。

下述，介绍在已实例化的链码通道上从发起一个调用交易-》最终记账的全过程 如下所示：

（一）。创建交易提案并发送给背书节点

使用应用程序构造交易提案，SignedProposal的结构如下所示：

上述结构说明：

SignedProposal是封装了Proposal的结构，添加了调用者的签名信息。

背书节点会根据签名信息验证其是否是一个有效的消息。

Proposal由两部分组成：

【1】消息头

       A。通道头（ChannelHeader）

　　      通道头包含了与通道和链码调用相关的信息。（如：在哪个通道上调用哪个版本的链码）

            txid是应用程序本地生成的交易号，跟调用者的身份证书相关，可以避免交易号的冲突。

            背书节点和记账节点都会校验是否存在重复交易。

       B。签名头（SignatureHeader）

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

            应用程序（构造好交易提案请求）-》选择-》背书节点（执行&进行背书签名）

            背书节点是链码背书策略里指定的节点。

        （有一些背书节点是离线的，其他背书节点可以拒绝对交易进行背书，也可以不背书。）

        （应用程序可尝试使用其他可用的背书节点来满足策略）

　　  （应用程序以何种顺序给背书节点发送背书请求是没有关系的，正常情况下背书节点执行后的结果是一致的，只有背书节点对结果的签名不一样）

【2】消息结构

（二）。背书节点模拟交易并生成背书签名

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

【1】。交易提案的格式是否正确

【2】。交易是否提交过（重复攻击保护）

【3】。交易签名有效（通过MSP）

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

验证通过后，“背书节点”会根据“当前账本数据”模拟“执行链码中的业务逻辑”并生成“读写集（RwSet）”，

其中包含“响应值”，“读写集”等。

在模拟执行时账本数据不会更新-》背书节点对这些读写集进行签名成为“提案响应”（Proposal Response）-》返回给应用程序

ProposalResponse结构如下：

 

说明：

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

（三）。收集交易的背书

应用程序收到ProposalResponse-》对背书节点签名进行验证 （所有节点收到任何消息后都要先验证消息合法性）

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

若：链码对账本进行Invoke操作，则需（判断背书策略是否满足）提交交易-》排序服务（账本更新）

注：若应用程序没有收集到足够的背书就提交交易，记账节点在提交验证阶段会发现交易不能满足背书策略，标记为无效交易。

如何选择背书节点？

目前fabric-sdk-go默认实现是把配置文件选项“channels.mychannel.peers”里的节点全部添加为背书节点，需要等待所有背书节点的背书签名。

应用程序等待每个背书节点执行的超时时间是通过配置文件选项“client.peer.timeout.connection”设置，配置文件示例3秒，可调整，未设置默认5秒。

（四）。构造交易请求并发送给排序服务节点

应用程序接收到所有背书节点签名-》根据背书签名调用SDK生成交易-》广播给排序服务节点

生成交易过程较简单：

      先确认所有背书节点的执行结果完全一致，

      再交易提案，提案响应，背书签名打包生成“交易”

交易结果如下所示：

（五）。排序服务节点以对交易进行排序并生成区块

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

排序服务要做的很简单：

A。先是接收网络中所有通道发出的交易信息

B。读取交易信封Envelope.Payload.Header,.ChannelHeader.Channelid以获取通道名称

C。按各个通道上交易的接收时间顺序对交易信息进行排序，生成区块

详细流程参见第4章《基于Gossip的P2P数据分发》

（六）。排序服务节点以广播给组织的主节点

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

主节点：代表的是和排序服务节点通信的节点。负责从排序服务节点处获取最新的区块并在组织内同步。

（可强强制设置主节点，也可动态选举产生）

详细流程参见第6章《集成共识机制的排序服务》

（七）。记账节点验证区块内容并写入区块

背书节点是动态角色，只要参与交易的背书就是背书节点。

  -》哪些交易选择哪些节点作为背书节点是由应用程序选择的，这需要满足背书策略才能生效。

所有背书节点都属于记账节点。

所有peer节点都是记账节点，记录的是节点已加入通道的账本数据。

记账节点：

【1】接收到的是“排序服务节点生成的区块”

【2】验证区块交易的有效性

【3】提交到本地账本后再产生一个生成区块的事件

【4】监听区块事件的应用程序可以进行后续的处理

若接收到的区块是配置区块，则会更新缓存的配置信息。

记账节点处理流程如图所示：

 

说明：

【1】。交易数据的验证

      区块数据的验证是以“交易验证”为单位，

　　每次对区块进行验证时都会生成一个交易号的位图TxValidationFlags，它记录每个交易号的交易验证状态，只有状态为TxValidationCode_VALID才有效。

      位图也会写入到区块的元数据BlockMetadataIndex_TRANSACTIONS_FILTER中

交易验证会检查如下内容：

A。是否为合法的交易：交易格式是否正确，是否有合法签名，交易内容是否被篡改。

B。记账节点是否加入了这个通道

上述基本验证通过后，提交给VSCC进行背书策略验证。

【2】。记账节点与VSCC

链码的交易是隔离的，每个交易的模拟执行结果集TxRwSet都包含了交易所属的链码。

为了避免错误地更新链码交易数据，在交易提交给系统链码VSCC验证交易内容前，还会对链码进行校验。

以下交易都是非法的：

【3】基于状态数据的验证和MVCC检查

交易通过VSCC检查后，进入“记账流程”

kvledger还会对读写集TxRwSet进行MVCC（Multi-Version Concurrency Control）检查

kvledger实现的是基于键值对（key-value）的状态数据模型，对状态数据键有3种操作：

A。读状态数据

B。写状态数据

C。删除状态数据

对状态数据读操作有2种形式：

A。基于单一键的读取

B。基于键范围的读取

【4】无效的交易处理

（八）。在组织内部同步最新的区块

详细流程参见第4章《基于Gossip的P2P数据分发》

5。消息协议结构

（一）。信封消息结构

信封消息是认证内容中最基本的单元。

它由一个消息负载（Payload）和一个签名（Signature）组成。

 

（二）。配置管理结构

 

（三）。背书流程结构

【1】。交易提案结构

一个提案消息包含：

A。头部（包含描述它的一些元数据，如：类型、调用者的身份、时间、链的ID、加密的随机数）

B。不透明的负载

一个提案发送给背书节点进行背书，该提案包含：

A。头部：可以解组为头部信息

B。负载：由头部的类型决定

C。扩展：由头部的类型决定

 

  

【2】。提案响应结构

【3】。背书交易结构

6。策略管理和访问控制

在Hyperledger Fabric 1.0 中，较多地方都使用策略进行管理，它是一种权限管理的方法。

包括：交易背书策略，链码的实例化策略，通道管理策略等。

（一）。策略定义及其类型

   

（二）。交易背书策略

交易背书策略是对交易进行背书的规则，是跟通道和链码相关的，在链码实例化的时候指定。

在链码调用的时候，需要从背书节点收集足够的签名背书，只有通过背书策略的交易才是有效的。

这是通过应用程序和背书节点之间的交互来完成的。

【1】。交易背书策略的验证

     

       

【2】。命令行的背书策略语法

【3】。给链码指定背书策略

（三）。链码实例化策略

     

（四）。通道管理策略

    

小结：

本章从逻辑结构，节点结构，典型交易流程，消息协议结构，策略管理等几个方面介绍了Hyperledger Fabric 1.0的架构。

通过这些内容介绍，能够基本了解Hyperledger Fabric 1.0的设计原则和思路。