区块链hyperledgerfabric架构详解
hyperledger fabric是区块链中联盟链的优秀实现，主要代码由IBM、Intel、各⼤银⾏等贡献，⽬前v1.1版的kafka共识⽅式可达到
1000/s次的吞吐量。本⽂中我们依次讨论：区块链的共通特性、fabric核⼼概念、fabric的交易执⾏流程。本⽂来源于笔者欲对公司部分业务上链⽽进⾏培训的PPT，故图多⽂字少，不要怕太长。
1、区块链解决⽅案的特性
1.1 分布式帐本
区块链核⼼概念是分布式帐本，就像下⾯的图1所⽰，同样的帐本（全量的交易数据，详见下节）在任意⼀台节点（不包括客户端）上都有。所以，其优点是数据很难造假，造假后也可以通过追溯记录来追究法律责任。⽽缺点就是极⼤的浪费，传统服务每份数据都尽量少存⼏份，即使存了三份拷贝都已经考虑到诸多异常，并使服务可⽤性达到N个9了。⽽区块链这种特性，同时造成的另⼀个问题是帐本不能太⼤，⾄少不能超过区块链⽹络中最⼩结点的存储以及处理能⼒。所以，这制约了总交易数据（下⽂为⽅便概念介绍，统称为帐本ledger）的条数，进⽽也影响了能写⼊区块链的单条交易数据的⼤⼩。
图1 区块链分布式帐本⽰意图
什么是区块链呢？我很喜欢《区块链技术进阶与实战》⼀书中对它的定义：区块链是⼀种按照时间顺序将数据区块以顺序相连的⽅式组合成的⼀种链式数据结构。如果觉得有点抽象，那么我们再来看看下⾯的图2。
图2-区块链数据结构⽰意
图2中就是账本，它由多个区块构成了⼀个有时序的链表，⽽每个区块⾥含有多条交易trasaction（缩写为tx）构成的链表。图2下⽅有⼀个WorldState世界状态，这其实是为了提升性能⽤的。⽐如，key1共交易了10000次，为了获取它的当前状态值，需要正向执⾏这10000次交易，这就得不偿失了。如果这1万次交易⾥，每次新交易执⾏完，都同步更新⼀个数据库（在fabric⾥⽤的是levelDB），这样查询当前状态时，只需要查询该数据库即可，如图3所⽰。
图3-fabric levelDB状态数据库
图3中，区块链帐本是在FileSystem⽂件系统中保存的，⽽Level DB存放世界状态。
1.2 智能合约smart contract
区块链的发展过程中，⼀般1.0时代就是数字货币时代，代表是⽐特币，⽽2.0时代就是智能合约（现在是3.0时代，各种联盟链即为代表）。
智能合约是运⾏在区块链上的模块化、可重⽤的⾃动执⾏脚本，有了它我们就可以完成复杂的业务逻辑，例如同⼀个区块链上有多份合约，⽽每份合约可以约定不同的参与者（企业或者相关⽅）。也可以指定每份合约⾥每个⼦命令做⼀批特定的事，⼤家可以把它想象成关系数据库⾥的事务。如图4所⽰，我们可以在合约⾥指定允许哪些企业的节点可以参与到交易流程中来（在fabric⾥这叫共识策略）。
图4-智能合约图⽰
在fabric中，智能合约叫做chaincode，它有6个状态，如下所⽰：
Install → Instantiate → invocable → Upgrade → Deinstantiate → Uninstall.
实际上智能合约就是⼀段代码，fabric官⽅认可的是GO语⾔。⾸先我们需要把合约代码上传到区块链上，这⼀步的状态就叫Install。
接着，需要做初始化操作。⽐如，现在的数据是存放在mysql中的，那么上线时需要⽤Instantiate把数据迁移⾄链上，这也算初始化。初始化后，chaincode就进⼊invocable可调⽤状态了。
通⽤我们可以通过CLI命令⾏或者程序⾥⽤SDK调⽤合约（v1.1前还有RestApi调⽤，现已放弃）。
联盟链由于跨多家企业、多个地区甚⾄国家，很难使得合约保持⼀致的版本，因此，每个合约都有版本号。⽽版本升级时，就是Upgrade状态。
最后两个状态对应着合约下链。
智能合约可以在供应链等较复杂的业务场景下起到很⼤的作⽤，如下⾯的图5所⽰：
图5-智能合约技术的应⽤⽰意
1.3 数据⼀致性（共识算法）
既然区块链是⼀个去中⼼化的分布式系统，那么⾃然只能通过投票来决定⼀致性了：少数服从多数。当然，多少算多数呢？不同的共识算法下，结果并不相同。⽐如paxos算法（参见笔者的《》）就是超过⼀半，⽽PBFT则需要三分之⼆以上。
这⾥有⼀个拜占庭将军问题需要注意，如何理解该问题可以参见这份翻译过的⽂档。简⾔之，就是投票的拜占庭将军（服务器）们有2种不可靠的形式。第⼀是迟钝（数据包延迟）、失忆（数据包丢失以及数据包重发）、失踪（服务器宕机）等不含背叛的⾏为，第⼆则是有将军是间谍（服务器被攻破）。如paxos这样的算法属于第⼀种，Fault-tolerance，它不能容忍服务器上有恶意代码；⽽如PBFT(Practical Byzantine Fault Tolerance)这样的算法是第⼆类，Byzantine-Fault-tolerance，它能够
容忍⼀定数量的拜占庭将军节点存在，如PBFT、SBFT、RBFT算法等。
第⼆类Byzantine-Fault-tolerance共识算法虽然看上去很美，但并不成熟，特别是性能低下，⽐如PBFT是⼀个多项式复杂度的算法
O(N^2)，节点过多时（⼤于100）性能急骤下降。第⼀类通常是O(N)复杂度，在某些场景下使⽤效果还不错，⽐如fabric v1.1的kafka共识机制就是这样的算法，下⽂我们会详述。
像⽐特币、以太坊等采⽤的共识算法⼜有所不同，例如⽐特币的POW⼯作量证明算法，它定义⼀⼩时内（通过调整运算难度实现，⽐如调整近似程度）有⼀个lucky node节点，该节点是通过证明⾃⾝的努⼒（hash值逆解）⽽幸运选出，选出后它就可以为这段时间的交易做决定（似乎挺像总统选举^_^）。详情参见我这篇⽂章：
1.4 ⾮对称加密
区块链通过⾮对称加密技术实现⾝份验证与数据加密。其实就是我们⽇常在⽤的SSL技术。
为了⽅便理解，我们需要先介绍PKI(Public Key Infrastructure)，它是⼀种遵循标准的利⽤公钥加密技术为电⼦商务的开展提供⼀套安全基础平台的技术和规范。有⼀个CA（Certificate Authority）权威机构负责向⽤户（包括服务提供者与使⽤者）提供数字证书，包括公钥与私钥，同时CA机构还需要提供
⼀个CRL（Certificate Revocation List）证书吊销列表，如下⾯的图6所⽰。
图6-CA机构颁发数字证书以及提供CAL
这样，区块链可以通过PKI体系实现安全认证。PKI有三个关键点，我们下⾯详述。
1.4.1 数字证书 Digital Certificate
⽐如Mary Morris符合X.509规范的数字证书⾥，其Subject属性⾥就含有她的信息，包括国家C=US、所属的州或者省份ST=Michigan、所在城市L=Detroit、所属单位O=Mitchesll Cars、其他信息OU=Manufacturing、公⽤信息CN=Mary Morris/UID=123456等，也含有其他信息，如下⾯的图7所⽰。
图7-PKI数字证书
1.4.2 公钥与私钥
CA颁发了两个证书：公钥与私钥，其中，私钥仅服务提供者保存，⽽公钥则可被所有⼈（服务使⽤者）保存。
所谓⾮对称加密，就是公钥加密的消息仅私钥可以解密；同理，私钥加密的消息，仅公钥可以解密。对应于前者，可以实现客户端访问服务器时加密消息，例如访问安全级别⾼的页⾯时提交的表单信息都需要⽤公钥加密，确保只有服务器才能解密⽹络报⽂。对应于后者，则可实现签名功能，如下⾯的图8所⽰。
图8-PKI中私钥签名后⽤公钥验签名
图8中Mary Morris⽤私钥对⼀段信息的内容（若内容过⼤则可先HASH后获得⼩点的字符串）加密后，⽣成签名附加在消息中。接收者可从CA机构获取到公钥，⽤公钥解密签名后，再与内容⽐对，以确定消息是否来⾃MaryMorris及内容是否被篡改。对于⽂件来说也是⼀样，⼩⽂件直接加密，⼤⽂件先⽣成hash再对hash加密，如下⾯的图9所⽰。
图9-对⽂件的签名
1.4.3 证书信任链
CA证书分为两类：RCA(Root CA)根证书以及ICA（Intermediate CA）中间证书。这些证书由RCA开始构成⼀个证书信任链，如下⾯的图10所⽰。
图10-CA证书信任链条
有许多CA证书权威机构，各⾃有其RCA。如果RCA得不到信任，那么其下的ICA也⽆法认证通过。
当然，⾃⼰的服务器也可以⽣成RCA。
在Fabric⾥，允许不同的企业使⽤不同的RCA，也可以使⽤相同的RCA和不同的ICA。这与下⽂中的MSP密切相关。
1.5 ⼩结
我们来总结下区块链，它主要是为了解决社会上的信任问题⽽存在的，为此，它付出了沉重的性能、可⽤性代价。它怎么做到的呢？通过4点实现：1、数据到处存放；2、操作记录不可更改；3、传输数据可信；4、业务脚本约束。
那么，这个信任问题的解决，带来了2个⾮功能性的约束：数据⼀致性和可⽤性。其中可⽤性包括两点：1、交易在可接受的时间内达成。⽐如⽐特币的分叉就会造成严重问题。2、吞吐量达标。⽽⽐特币每秒只能有7次交易，这显然太低了。
2、fabric核⼼概念
hyperledger fabric符合上⾯说过的区块链的所有特性。我们必须先了解它的⼀些概念，才能进⼀步理解其架构设计。由于英⽂资料居多，所以这些概念我都以英⽂描述为准：
chaincode：智能合约，上⽂已提到。每个chaincode可提供多个不同的调⽤命令。
transaction：交易，每条指令都是⼀次交易。
world state：对同⼀个key的多次交易形成的最终value，就是世界状态。
endor：背书。⾦融上的意义为：指持票⼈为将票据权利转让给他⼈或者将⼀定的票据权利授予他⼈⾏使，⽽在票据背⾯或者粘单上记载有关事项并签章的⾏为。通常我们引申为对某个事情负责。在我们的共识机制的投票环节⾥，背书意味着参与投票。
endorment policy：背书策略。由智能合约chaincode选择哪些peer节点参与到背书环节来。
peer：存放区块链数据的结点，同时还有endor和commit功能。
channel：私有的⼦⽹络，事实上是为了隔离不同的应⽤，⼀个channel可含有⼀批chaincode。
PKI：Public Key Infrastructure，⼀种遵循标准的利⽤公钥加密技术为电⼦商务的开展提供⼀套安全基础平台的技术和规范。
MSP：Membership Service Provider，联盟链成员的证书管理，它定义了哪些RCA以及ICA在链⾥是可信任的，包括定义了channel上的合作者。
org：orginazation，管理⼀系列合作企业的组织。
2.1 开发概念
fabric联盟链的开发⼈员主要分为三类：底层是系统运维，负责系统的部署与维护；其次是组织管理⼈员，负责证书、MSP权限管理、共识机制等；最后是业务开发⼈员，他们负责编写chaincode、创建维护channel、执⾏transaction交易等，如下⾯的图11所⽰。
图11-fabric技术⼈员的分层
fabric⼤致分为底层的⽹络层、权限管理模块、区块链应⽤模块，通过SDK和CLI对应⽤开发者提供服务，如下⾯的图12所⽰。
图12-fabric开发模块图
我们的开发流程主要包括写智能合约，以及通过SDK调⽤智能合约，及订阅各类事件，如图13所⽰。
图13-开发环节
2.2 MSP
每个管理协作企业的ORG组织都可以拥有⾃⼰的MSP。如下图14所⽰，组织ORG1拥有的MSP叫ORG1.MSP，⽽组织ORG2业务复杂，所以维护了3个MSP。
图14-ORG可管理⾃⼰的MSP
MSP出现在两个地⽅：在channel上有⼀个全局的MSP，⽽每个peer、orderer、client等⾓⾊上都维护有本地的局部MSP，如图15所⽰。
图15-在channel上的Global MSP以及在参与⾓⾊上的Local MSP
本地MSP只保存有Global MSP上的⼦集，内容保存在本地⽂件系统上，⽽全局MSP可在逻辑上认为是配置在系统上的，它实际也在每个参与者上保存⼀份拷贝，但会维持⼀致性。
MSP也分级，如图16中所⽰，底层的network MSP负责⽹络层的准⼊，其MSP由ORG1拥有，⽽上⾯的某个channel的MSP则由ORG1和ORG2共同管理。
图16-MSP是分级的
⼀个MSP下含有以下结构，如图17所⽰。
图17-MSP结构
可见，MSP结构包括：
RCA根证书
ICA中间证书
OU组织单位
管理员证书
RCL吊销证书列表
结点上的具体证书
存储私钥的keystore
TLS的根证书与中间证书
3、fabric交易提交流程
3.1 peer结点的部署
peer结点上保存有账本ledger以及智能合约，如下图所⽰：
channel是⼀个逻辑概念，可以通过MSP隔离全⽹不同组织的参与者，如下图所⽰：
当有多⽅参与者时，例如4个org组织、8个peer结点时，其中channel连接了P1、P3、P5、P7、P8这五个节点，其他3个节点加⼊了其他channel，其部署图如下所⽰：
加⼊MSP来管理⾝份时，如P1和P2由ORG1.MSP管理，⽽P3和P4的证书则由ORG2.MSP管理，他们共同使⽤⼀个channel，则如下图所⽰：
3.2 交易的执⾏流程
去中⼼化的设计，必然需要通过投票（多数⼤于少数）来维持数据⼀致性，⽽任何投票都必须经历以下三个过程：
1. 有⼀⽅先提出议案proposal，该议案有对应的⼀批投票者需要对该结果背书，这些投票者依据各⾃的习惯投票，并将结果反馈；
2. 统计投票结果，若获得多数同意，才能进⾏下⼀步；
3. 将获得多数同意的议案记录下来，且公之于众。
⽽这三步fabric当然也少不了，当然它的称法就有所不同，其对应的三步如下：
1. 由client上的CLI或者SDK进⾏proposal议案的提出。client会依据智能合约chaincode根据背书策略endor policy决定把
proposal发往哪些背书的peer节点，⽽peer节点进⾏投票，client汇总各背书节点的结果；
2. client将获得多数同意的议案连同各peer的背书（包括其投票结果以及背书签名）交给orderring rvice，⽽orderer会汇总各client
递交过来的trasaction交易，排序、打包。
3. orderer将交易打包成区块block，然后通知所有commit peer，各peer各⾃验证结果，最后将区块block记录到⾃⼰的ledger账本
中。
我们看⼀个具体的例⼦，若channel上有三个peer背书者，client提交流程如下图所⽰：
详细解释下上图的流程：
1. ⾸先，client发起⼀个transaction交易，含有<clientID, chaincodeID, txPayLoad, timestamp, clientSig>等信息，指明了3W要
素：消息是谁who在什么时间when发送了什么what。该消息根据chaincode中的背书策略，发向EP1、EP2、EP3这三个peer节点。
2. 这三个peer节点模拟执⾏智能合约，并将结果及其各⾃的CA证书签名发还client。client收集到⾜够数量的结果后再进⾏下⼀步。
3. client将含背书结果的tx交易发向ordering rvice。
4. ordering rvice将打包好的block交给committing peer CP1以及EP1、EP2、EP3这三个背书者，背书者此时会校验结果并写⼊
世界状态以及账本中。同时，client由于订阅了消息，也会收到通知。
如果我们从编程的⾓度来看，则流程会更清楚：
参见上图，A是我们的应⽤程序，其步骤如下：
1. A⾸先连接到peer。
2. A调⽤chaincode发起proposal；与此同时，P1收到后先模拟执⾏，再产⽣结果返回给A。
3. A收到各peer返回的结果。
4. A向O1发起交易；与此同时，O1产⽣区块后会通知peer，⽽peer会更新其账本。
5. 最后通过订阅事件A收到了结果。
最后再细看下这三个阶段。
3.2.1 proposal提案阶段
可以看到，A1发出的<T1, P>，收到了<T1, R1, E1>和<T1, R2, E2>两个结果。
3.2.2 package打包阶段
O1在⼀个channel上会收到许多T交易，它会将T排序，在达到block的最⼤⼤⼩（⼀般应配1M以下，否则性能下降严重，kafka擅长处理⼩点的消息）或者达到超时时间后，打成区块P2。
3.2.3 验证阶段
O1将含有多条交易T打成区块的B2发往各peer节点，⽽P1和P2将B2加⼊各⾃的L账本中。
4、⼩结
本⽂偏重于概念的解释，由于篇幅所限，未涉及fabric的系统搭建（请参考笔者的这篇⽂章《》），也未描述共识算法在异常情况下如何维持⼀致性，这留待下⼀篇⽂章解决。fabric的许多思想是值得我们进⼀步研究的，其优秀的实现可以帮助我们通过fabric获得区块链在信任创新上的思路。
