Hyperledger Fabric 1.0架构浅析
（2017年4月）最近学习研究Hyperledger Fabric 1.0（以下简称Fabric），看了一遍官方文档，做了一些实验，在此记述一下对Fabric架构的初步认识与理解。
Fabric 1.0被设计成功能模块可插拔的区块链系统框架，在这个框架内，功能模块可以很容易被替换。比如，完成共识排序算法功能的Ordering service，可以是一个中心化的单节点、HA双节点，也可以是执行PBFT算法的由多个节点构成的分布式集群或较大规模的P2P网络。如果实际应用场景需要其他形式的共识排序功能，系统设计者可以引入新的交易及区块排序系统，执行PoW、PoS共识算法等，当然，这有可能要改写Fabric的小部分源代码，这些改造工作量在很多情况下是可以被接受的。Fabric 1.0的智能合约执行环境是Docker容器环境，智能合约可由Go、Java编写，后续其他语言也会被支持，将来也有可能在容器中运行一个专用的智能合约语言解释器或虚拟机，进而支持专用的智能合约语言。
Fabric网络节点从功能上分为三类：Client，Peer，Orderer。因为Fabric节点加入网络都涉及身份问题，因此，Fabric网络也引入了CA节点，当然，CA节点也是可以按照实际应用场景进行替换的。Fabric-CA负责对系统接入机构、成员、用户进行身份认证、发行数字证书。按照实际用途，数字证书可分为注册证书和交易证书，分别用于成员接入网络和用户发起交易。节点的分类只是从功能的角度来看，实际应用中，可能一台服务器即运行Peer进程，又运行Orderer进程,这是可以的。网络拓扑结构示意图如下：
通过网络拓扑图，不难想到,共识排序系统既然已经被剥离为独立的系统，那么这个系统就可以为多套区块链账本服务了，因而Fabric的设计者采纳了多通道设计，用一套共识排序系统服务多套区块链账本，为多套逻辑上分离的、由Peer和Client构成的应用系统提供交易排序服务。交易中的敏感数据可以被加密，对Orderer不可见，隐私可以受到保护。
Fabric的共识排序系统分离设计引发的思考：在将来，会不会出现某个共识网络，执行着多种共识算法，为不同的通道（账本）提供不同的交易顺序与区块生成策略，或进一步演化出一个全球通用的纯粹的共识排序云服务呢？这样的系统如果出现，区块链应用系统的设计与实现工作就会减轻不少工作量。应用系统节点只需申请接入云服务，并关注签名、验签、身份与权限控制、账本与状态更新及维护工作即可，只需指定所需要的算法，而无需关心具体的排序工作实现。比如Intel的某些CPU中集成了支持PoET的功能，采用这类CPU可较为容易地构建出一个共识排序网络，为多套账本提供交易区块生成服务。
Client、Peer、Orderer通过网络互相收发数据消息，示意图如下：
Client可以与Peer、Orderer直接交互，但出于安全等角度考虑，也可以选择某些Peer节点做代理（Submitting Peer），通过代理节点与其他Peer及Orderer交互。Client发起交易，并对交易签名，发送给Peer，根据背书策略，Client可能需要向多个peer发送签名后的交易，这些Peer验证交易，并模拟执行交易所触发的智能合约，对执行结果等数据进行签名，发送给Client，由Client收集结果数据和签名，再发送给Order，由Order收集多笔交易，打包成区块，然后在发送给Peer，这时，Peer就会检查区块里的每一笔交易，以及模拟执行结果数据集，检查通过则交易合法，否则交易被标记为Invalid状态。下面是官方提供的交易顺序示意图：
该流程图对应的交易处理步骤如下：
1、Client发起交易，这个场景下的Client是通过Submitting Peer代理和其他Peer以及交易共识排序系统交互的，Client的接入合法性可由Submitting Peer来控制。主要看系统是如何设计的；
2、Submitting Peer按照背书策略，继续发送交易给其他节点（Endorsing Peer）,模拟执行智能合约（Chain Code），暂存合约执行结果（Key-Value读写集），但执行结果不会真正更新到本地账本和Key-Value 状态数据库中；
3、Endorsing Peer验证交易签名，验证读写集版本依赖关系是否有效，并将结果发送给Submitting Peer；
4、Submitting Peer收集Endorsing Peer的签名的执行结果和交易数据，发送到共识排序服务（Consensus
Service，又称Ordering Service）；
5、共识排序系统按特定的共识算法将多笔交易排序打包成区块，并将区块递交给同一通道内的全部Peer；
6、接收到区块的全部Peer检查验证区块里的每一笔交易，比对模拟执行读写集结果，根据比对结果设置交易是否生效，设定好标记，并更新本地账本和状态数据库，这时，交易才真正反映到区块链上；
7、补充一个步骤，图中没有画出来，Submitting Peer需将交易是否执行成功等信息反馈给Client,或者Client可以通过调用SDK接收Fabric“事件”（event）得知交易执行结果。
