Hyperledger Fabric是区块链中联盟链的优秀实现，主要代码由IBM、Intel、各大银行等贡献，目前v1.1版的kafka共识方式可达到1000/s次的吞吐量。本文将分为上、中、下三篇我们依次讨论：

上篇主要讲:Fabric与区块链的共通特性;

中篇主要讲:Fabric逻辑架构、Fabric运行时架构、Fabric共识算法

下篇主要讲:Fabric的开发模型、Fabric的交易流程

一、区块链解决方案的特性

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个状态，如下所示：

实际上智能合约就是一段代码，fabric官方认可的是GO语言。首先我们需要把合约代码上传到区块链上，这一步的状态就叫Install。

接着，需要做初始化操作。比如，现在的数据是存放在mysql中的，那么上线时需要用Instantiate把数据迁移至链上，这也算初始化。初始化后，chaincode就进入invocable可调用状态了。

通用我们可以通过CLI命令行或者程序里用SDK调用合约（v1.1前还有RestApi调用，现已放弃）。

联盟链由于跨多家企业、多个地区甚至国家，很难使得合约保持一致的版本，因此，每个合约都有版本号。而版本升级时，就是Upgrade状态。

最后两个状态对应着合约下链。

智能合约可以在供应链等较复杂的业务场景下起到很大的作用，如下面的图5所示：

图5 智能合约技术的应用示意

1.3 数据一致性（共识算法）

既然区块链是一个去中心化的分布式系统，那么自然只能通过投票来决定一致性了：少数服从多数。当然，多少算多数呢？不同的共识算法下，结果并不相同。比如paxos算法（分布式一致性算法）就是超过一半，而PBFT则需要三分之二以上。

这里有一个拜占庭将军问题需要注意，如何理解该问题可以参见之前的（paxos算法原理与推导）文档。简言之，就是投票的拜占庭将军（服务器）们有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次交易，这显然太低了。

(未完待续）下一篇：一文详解Hyperledger Fabric架构及原理（中）