Hyperledger Fabric 1.0架构浅析

[gph753]

最近学习研究Hyperledger Fabric
1.0（以下简称Fabric），看了一遍官方文档，做了一些实验，在此记述一下对Fabric架构的初步认识与理解。

Fabric 1.0被设计成功能模块可插拔的区块链系统框架，在这个框架内，功能模块可以很容易被替换。比如，完成共识排序算法功能的Ordering service，可以是一个中心化的单节点、HA双节点，也可以是执行PBFT算法的由多个节点构成的分布式集群或较大规模的P2P网络。如果实际应用场景需要其他形式的共识排序功能，系统设计者可以引入新的交易及区块排序系统，执行PoW、PoS共识算法等，当然，这有可能要改写Fabric的小部分源代码，这些改造工作量在很多情况下是可以被接受的。Fabric
1.0的智能合约执行环境是Docker容器环境，智能合约可由Go语言编写，后续其他语言也会被支持，将来也有可能在容器中运行一个专用的智能合约语言解释器或虚拟机，进而支持专用的智能合约语言。

Fabric网络节点从功能上分为三类：Client，Peer，Orderer。因为Fabric节点加入网络都涉及身份问题，因此，Fabric网络也引入了CA节点，当然，CA节点也是可以按照实际应用场景进行替换的。Fabric-CA负责对系统接入机构、成员、用户进行身份认证、发行数字证书。按照实际用途，数字证书可分为注册证书和交易证书，分别用于成员接入网络和用户发起交易。节点的分类只是从功能的角度来看，实际应用中，可能一台服务器即运行Peer进程，又运行Orderer进程,这是可以的。网络拓扑结构示意图如下：




通过网络拓扑图，不难想到,共识排序系统既然已经被剥离为独立的系统，那么这个系统就可以为多套区块链账本服务了，因而Fabric的设计者采纳了多通道设计，用一套共识排序系统服务多套区块链账本，为多套逻辑上分离的、由Peer和Client构成的应用系统提供排序服服务。交易中的敏感数据可以被加密，对Orderer不可见，隐私可以受到保护。


Fabric的共识排序系统分离设计引发的思考：在将来，会不会出现某个共识网络，执行着多种共识算法，为不同的通道（账本）提供不同的交易顺序与区块生成策略，或进一步演化出一个全球通用的纯粹的共识排序云服务呢？这样的系统如果出现，区块链应用系统的设计与实现工作就会减轻不少工作量。应用系统节点只需申请接入云服务，并关注签名、验签、身份与权限控制、账本与状态更新及维护工作即可，只需指定所需要的算法，而无需关心具体的排序工作实现。比如Intel的某些CPU中集成了支持PoET的功能，采用这类CPU可较为容易地构建出一个共识排序网络，为多套账本提供交易区块生成服务。

Client、Peer、Orderer通过网络互相收发数据消息，示意图如下：（见下页）