Hyperledger fabric V1.0 架构解析

       Hyperledger是被业界非常看到的联盟链的实现，包括IBM、Intel、R3、各个大型商业银行等都参与其中，带给我们关于区块链技术与软件工业、金融、保险、物流等领域碰撞结合的想象空间；在这个联盟中，有超过1/4的成员都来自中国，这更是我们对于它的一举一动都非常关注。很大程度上，Hyperledger和它背后的联盟体系就代表着区块链在产业环境中的未来。

做架构解析之前，我们先了解一些Fabric中的组件/术语：

1、Channel：是一种数据隔离机制，保证交易信息只有交易参与方可见，每个channel是一个独立的区块链，这使得多个用户可以共用同一个区块链系统而不用担心信息泄露问题。 

2、Chaincode：也叫智能合约，将资产定义和资产处理逻辑封装成接口，当其被用户调用的时候，改变账本的状态。

3、Ledger：区块链账本，保存交易信息和智能合约代码。

4、Network：交易处理节点之间的P2P网络，用于维持区块链账本的一致性。

5、Ordering service：利用kafka（1.0正式使用）、SBTF（0.6使用）、Solo（1.0测试使用）等共识算法对所有交易信息进行排序并打包成区块，发给committing peers节点，写入区块链中。

6、 World state：显示当前资产数据的状态，底层通过LevelDB和CouchDB数据库将区块链中的资产信息组织起来，提供高效的数据访问接口。

7、Membership service provider（MSP）：管理认证信息，为client和peers提供授权服务。（1.0版本后成为CA组件）

Hyperledger Fabric Network中的角色

• Client：应用客户端，用于将终端用户的交易请求发送到区块链网络；
• Peers：负责维护区块链账本，分为endoring peers和committing peers，其中，endorser为交易做背书（验证交易并对交易签名），committer接收打包好的区块，然后写入区块链中。Peers节点是一个逻辑的概念，endorser和committer可以同时部署在一台物理机上。

• Ordering Service：接收交易信息，并将其排序后打包成区块，放入区块链，最后将结果返回给committer peers。

   作为最重要的子项目，我们分析一下Fabric最新版本（1.0）的总体架构。

      采用区块链好处有1、分布式数据存储；2、点对点传输；3、共识机制；4、加密算法；5、去中心化等优点。但是我觉得，采用区块链最大的优点是将企业内的信息化治理提升到企业间的信息化治理。为我们的数字资产跨企业间交易实现提供了技术保障。

Hyperledger fabric总体架构分析：

我们可以借鉴Hyperledger fabric官方给出的架构图我们分析一下，如下图：

 

我们分析一下，这个架构总体上分为4个部分；

1、   Membership部分，主要为成员服务模块，包括会员注册，身份保护、内容保密、交易审计等功能。但是在1.0中单独将他列为可插拔的CA模块。

2、   区块服务部分，负责节点间共识管理、账本的分布式计算、账本的存储及节点间的P2P协议功能的实现，是区块链的核心组成部分，为区块链的主体功能提供了底层技术支撑。

3、   ChainCode部分，提供了一些列接口，为智能合约实现提供了方便。还有安装、运行、部署提供了环境。

4、   Event部分，贯穿于其他各个组件中间，为各个组件间的异步通讯提供了技术支持。

V0.6版本运行架构分析，我们可以借鉴官方提供的运行架构图分析如下图：

 

V0.6版本的架构特点是：

结构简单：应用-成员管理-Peer的三角形关系，主要业务功能全部集中于Peer节点；架构问题：由于peer节点承担了太多的功能，所以带来扩展性、可维护性、安全性、业务隔离等方面的诸多问题，所以V0.6版本在推出后，并没有大规模被行业使用，只是在一些零星的案例中进行业务验证；针对上述问题，V1.0版本做了很大的改进和重构：

这是最新的V1.0运行时架构：

 

V1.0架构特点：

分拆Peer的功能，将Blockchain的数据维护和共识服务进行分离，共识服务从Peer节点中完全分离出来，独立为Orderer节点提供共识服务；基于新的架构，实现多通道（channel）的结构，实现了更为灵活的业务适应性（业务隔离、安全性等方面）支持更强的配置功能和策略管理功能，进一步增强系统的灵活性和适应性；

备注：最新的1.0版本中，上图中的Membership服务已经改名为fabric-ca。

V1.0版本的架构目标：

从Fabric的新架构设计的建议文档看，1.0版本的设计目标如下：

Chaincode信任的灵活性：1.支持多个ordering服务节点，增强共识的容错能力和对抗orderer作恶的能力2. 扩展性： 将endorsement和ordering进行分离，实现多通道（实际是分区）结构，增强系统的扩展性；同时也将chaincode执行、ledger、state维护等非常消耗系统性能的任务与共识任务分离，保证了关键任务（ordering）的可靠执行保密性：新架构对于chaincode在数据更新、状态维护等方面提供了新的保密性要求，提高系统的业务、安全方面的能力共识服务的模块化：支持可插拔的共识结构，支持多种共识服务的接入和服务实现。

我们现在看看 V1.0版本的关键架构：

多链与多通道

Fabric1.0 的重要特征是支持多chain和多channel；

所谓的chain（链）实际上是包含Peer节点、账本、ordering通道的逻辑结构，它将参与者与数据（包含chaincode在）进行隔离，满足了不同业务场景下的”不同的人访问不同数据“的基本要求。

同时，一个peer节点也可以参与到多个chain中（通过接入多个channel）；如下图所示

 

 

 

关于通道：通道由共识服务（ordering）提供的一种通讯机制，类似于消息系统中的发布-订阅（PUB/SUB)中的topic；基于这种发布-订阅关系，将peer和orderer连接在一起，形成一个个具有保密性的通讯链路（虚拟），实现了业务隔离的要求；通道也与账本（ledger）-状态（worldstate）紧密相关；如下图所示：

 

 

 

共识服务与（P1、PN）、（P1、P2、P3）、（P2、P3）组成了三个相互独立的通道，加入到不同通道的Peer节点能够维护各个通道对应的账本和状态；也其实也对应现实世界中，不同业务场景下的参与方，例如银行、保险公司；物流企业、生产企业等实体结构；我们可以看到channel机制实际上是的Fabric建模实际业务流程的能力大大增强了，大家可以发挥想象力去找到可能的应用领域。

交易（数据）流程说明

新版本的架构变化导致新的交易流程的变化，我们简述如下：

总体流程如下图所示：

 

应用程序通过SDK发送请求到Peer节点（一个或多个）peer节点分别执行交易（通过chaincode），但是并不将执行结果提交到本地的账本中（可以认为是模拟执行，交易处于挂起状态），参与背书的peer将执行结果返回给应用程序（其中包括自身对背书结果的签名）应用程序收集背书结果并将结果提交给Ordering服务节点，Ordering服务节点执行共识过程并生成block，通过消息通道发布给Peer节点，由peer节点各自验证交易并提交到本地的ledger中（包括state状态的变化）

我们这里详细解释一下，交易的处理逻辑。

1. 客户端通过SDK接口，向endorsing peer节点发送交易信息：

   2.每个endorsing peer节点模拟处理交易，此时并不会将交易信息写入账本。然后，endorser peer会验证交易信息的合法性，并对交易信息签名后，返回给client。此时的交易信息只是在client和单个endorser peer之间达成共识，并没有完成全网共识，各个client的交易顺序没有确定，可能存在双花问题，所以还不能算是一个“有效的交易”。同时，client需要收到“大多数”endorser peer的验证回复后，才算验证成功，具体的背书策略由智能合约代码控制，可以由开发者自由配置。

3.client将签名后的交易信息发送给order service集群进行交易排序和打包。Order service集群通过共识算法，对所有交易信息进行排序，然后打包成区块。Order service的共识算法是以组件化形态插入Hyperledger系统的，也就是说开发者可以自由选择合适的共识算法。

4.ordering service将排序打包后的区块广播发送给committing peers，由其做最后的交易验证，并写入区块链。ordering service只是决定交易处理的顺序，并不对交易的合法性进行校验，也不负责维护账本信息。只有committing peers才有账本写入权限。

 

上述过程对应的执行序列图如下：

 

 

 

在新的架构中，Peer节点负责维护区块链的账本（ledger）和状态（State），本地的账本称为PeerLedger，其结构如下：

 

 

 Hyperledger Fabric Network的共识算法

在所有peers中，交易信息必须按照一致的顺序写入账本（区块链的基本原则）。例如，比特币通过POW机制，由最先完成数学难题的节点决定本次区块中的信息顺序，并广播给全网所有节点，以此来达成账本的共识。而Hyperledger Fabric采用了更加灵活、高效的共识算法，以适应企业场景下，对高TPS的要求。目前，Hyperledger Fabric有三种交易排序算法可以选择。

• SOLO：只有一个order服务节点负责接收交易信息并排序，这是最简单的一种排序算法，一般用在实验室测试环境中。Sole属于中心化的处理方式。

• Kafka：是Apache的一个开源项目，主要提供分布式的消息处理／分发服务，每个kafka集群由多个服务节点组成。Hyperledger Fabric利用kafka对交易信息进行排序处理，提供高吞吐、低延时的处理能力，并且在集群内部支持节点故障容错。

• SBFT：简单拜占庭算法，相比于kafka，提供更加可靠的排序算法，包括容忍节点故障以及一定数量的恶意节点。目前，Hyperledger Fabric社区正在开发该算法。

我们可以看到，整个区块结构分为文件系统存储的Block结构和数据库维护的State状态，其中state的存储结构是可以替换的，可选的实现包括各种KV数据库（LEVELDB，CouchDB等）；

我们分析了Hyperledger fanbic基本架构分析，通过我们分析后，我们规划我们的系统设计。传统的系统从架构上分析，一般都是经典的四层架构：

1、     呈现层：主要接入层，无论是手机，PC，APP 或者浏览器都可以，包括登录界面交易界面；

2、     服务层：主要提供应用服务。

3、     业务层：主要企业内部一些业务逻辑，在业务层介入区块链服务，当发生这笔业务逻辑的时候，启动区块链服务，将需要共享的数据写入链上。

4、     数据层：传统的数据库如SqlServer DB2oracle等等。在区块链上数据层主要是文件系统的Block数据块和WorldState当前状态。

 

我们分析那些数据需要上链。根据业务需求分析，简单来说就是需要共享给链上所有企业都知道的数据，都要上链。

在区块链上线之初，第一阶段，我们建议将上链数据也同样写一份到传统数据库中，因为传统数据库可以很好的实现灾备。第二阶段已经完成上线后，链上的数据需要备份到传统数据库的要求可以弱化。

2017-12-12 深夜