深度探索区块链/超级帐本系统架构(3)

《深度探索区块链》

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的设计原则和思路。