星云研究院:Hyperledger Fabric论文分析

本文作者：星云研究院资深研究院汤载阳博士。华中科技大学计算机博士，日本会津大学和法国南巴黎国立电信学院访问学者，研究方向包括分布式系统、无线网络和区块链共识，在TPDS、ICDCS等顶级期刊会议上发表过论文。

前言

最近部门开始了Survey的计划，从Cryptology，Consensus和传统分布式系统三个方向调研目前业内关于Blockchain的最新进展。在寒冷的冬天，能窝在被窝里看论文也算是不幸中的万幸。本来一直也有想写专栏的计划，刚好借此机会整理下看过的论文。

既然是系列开头，第一篇论文选择还是比较慎重的，我们最终选择了发表于EuroSys18的论文《Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains 》，该论文介绍了IBM在联盟链方向的最新研究成果。

话不多说，开始正文。

Fabric

Fabric是属于Hyperledger的一个子项目，后者是由Linux基金会发起面向区块链技术的开源项目，主要成员包括IBM、R3、Intel等等。Hyperledger实际上还有很多子项目，其中另一个比较著名的是Sawtooth Lake，由Intel主导，包含了一种全新的共识机制Proof-of-Elapsed Time（PoET），该共识策略支持Intel的SGX技术（以后再详细介绍）。

Fabric v0.6在2016年九月发布，当时的Fabric和其他联盟链没有太大区别，采用PBFT共识。这篇论文介绍的是最新v1.0 Fabric（目前GitHub上最新版本为v1.4，后文如果没有特别说明都特指v1.0），主要对上述若干问题进行了较大改进，从节点架构上来看，取消了原来的Validating和Non-Validating节点，取而代之的是Endorser节点、Committer节点和全新的Orderer模块。

专有名词解释：

BFT：Byzantine-fault tolerant 拜占庭容错，即有恶意节点情况下的容错

CFT：crash fault tolerant 无恶意节点情况下的容错

SMR：state-machine replication 状态机复制 ，分布式系统中最重要概念

MSP：membership service provider 成员管理模块，负责Fabric中三类节点的认证管理

PTM：peer transaction manager 更新最新的交易的状态，以

VSCC：validation system chaincode 验证chaincode，后文会详细介绍

ESCC：endorsement system chaincode 背书chaincode，后文会详细介绍

Basics

关于区块链的划分，通常包括公链、联盟链和私有链（个人认为私有链就是一个伪命题）。最近几年学术圈给出了更为严谨的定义，即permissionless（or public）chain和permissioned chain。

在本文中，作者给出public blockchain和permissioned blockchain的定义如下：

Public blockchains typically involve a native cryptocurrency and often use consensus based on “proof of work”(PoW) and economic incentives.

A permissioned blockchain provides a way to secure the interactions among a group of entities that have a common goal but which do not fully trust each other.

可以看出来两者最主要的区别在于参与节点的身份是否确定以及是否引入了经济激励机制。

当然无论public chain还是permissioned chain，其本质仍然都是状态机复制（SMR），但由于智能合约的出现产生了新的变化。如果我们将智能合约看做一种分布式应用，blockchain和传统SMR的区别在于：

• 多个智能合约可以同时运行；

• 任何人都可以随时部署智能合约；

• 智能合约代码不可信，甚至可能产生恶意后果

  
  

Order-execute

大部分区块链（也包括公链）所采用的流程是：将transactions排序打包然后同步到每个节点（通常采用广播的方式），每个节点再按顺序执行（或者称之为验证）这些交易。在论文中，这种架构被称之为“order-execute architecture”，即先“order”再“execute”。如下图所示：

这样的架构存在一些问题，

首先所有节点按照顺序执行交易会限制性能（例如TPS），通常将不相关的操作并发执行可以提升性能，但是对智能合约很难做到并发，因为代码之间的依赖关系很难确定。此外，order-execute最大的限制是，所有节点所执行的交易必须满足确定性（must be deterministic）。类似以太坊这样采用Solidity这样的编程语言可以一定程度上保证代码确定性，但对于更流行的语言（例如Go，Java，C/C++），则很难保证确定性（比如Go中的map iterator就无法保证确定性）。

在联盟链中，一种可行的做法是，仅让部分节点运行代码，然后同步最终状态（state）至全网。这样子一方面通过选择运行代码的节点从而保证代码运行的一致性，并且减少了验证节点数也提升了性能。

但论文中也指出现有的联盟链存在一些问题，例如：

• Fixed trust model：即合约执行背书和共识机制绑定，这种紧耦合的架构不够灵活；

• Hard-coded consensus：共识机制通常为硬编码的形式固定，但实际上即便是BFT这一类的算法在不同场景下（节点信任度或者网络环境不同）表现也不尽相同

Execute-order-validate

Fabric采用了全新的交易架构，称之为execute-order-validate，如下图所示。

在上述架构中，智能合约这种分布式应用包括了两个部分：

• chaincode：即原来的smart contract code，在execute阶段可以运行，值得注意的是，还有一种特殊的system chaincodes，这类chaincodes定义了整个链的底层设置，包括validation system chaincode和endorsement system chaincode（和我们的NBRE非常相似）。

• endorsement policy：这个概念理解起来就有点绕了，可以理解为独立于共识模块的一种验证或者背书机制。传统consensus包括了验证节点是否作恶以及交易本身是否正确两个任务，而在Fabric中，将后者抽离成为endorsement policy。实际上这个模块也是可以替换的，比如“五个endorser节点中只要有三个执行结果一致则完成验证”这种策略完全可以换成“只需要XXX endorser节点完成执行则通过验证”。

如下图所示，在Fabric中有三类节点，包括：

• Clients：这类节点即发起交易或者调用智能合约的普通节点；

• Peers：执行验证交易的节点，这类节点需要有全量ledger数据，在这类节点中，只有一部分负责执行交易，即endorsing peers（或者叫endorsers）；

• OSNs（Ordering Service Nodes）：

上述所有节点都需要认证，由MSP统一发放，形式可以为offline也可以为online。

详细的交易流程如下图所示：

1.client发起交易，首先将交易信息（propose message）发给定义好的若干endorsers，注意此处的endorsers是由交易本身的chaincode和其中的 endorsement policy共同决定；此处propose message包括信息如下：

tx=

clientID:提交交易的client的ID
chaincodeID：交易所属的chaincode的ID
txPayload：交易本体信息
timestamp：时间戳
clientSig：client签名

1. endorser收到message后，用client公钥验证clientSig，然后运行交易并验证输出结果。如果该endorser被选择为背书节点，则把结果发回给提交的client；

2. 该client收集每个endorser返回的信息，当满足endorsement policy后，则进入ordering阶段，反之该交易失败；

3. client将通过endorsement的交易广播至所有orderers（表示为broadcast(tx)），后者通过某种共识机制对所有通过endorsement的交易进行排序，保证所有节点的数据满足时序一致性；

4. orderers再将排序后的交易广播至其他peers（包括了endorsing peers和non-endorsing peers），这里广播的实际上就是一个包含了若干交易的block和一个sequence number；

5. 所有peers验证block之后，更新自身的ledger，即完成上链。

当然上述流程中有一些较强的假设，比如对于P2P传输而言，需要满足liveness，即broadcast(tx)操作在有限的时间内一定可以到达所有其他节点。

关于ordering，可采用不同的共识机制，目前支持Kafka，BFT-SMaRt和Solo。Kafka是基于ZooKeeper的Paxos实现，可以实现50%的CFT；BFT-SMaRt则是PBFT的实现，可以实现33%的BFT；Solo是单order节点的ordering，主要用于开发测试。

P2P传输，采用的是epidemic multicast，包括了push和pull两种模式。

Chaincode

每一条链（channel）的配置位于特殊的configuration blocks中，包括了：

1. MSPs定义

2. OSNs地址

3. consensus和ordering的部分参数，例如batch size、timeouts

4. ordering中的基本操作定义（broadcast和deliver）

通过channel configuration update transaction可以更新channel的配置

每个application的chaincode包括了endorsement system chainco（ESCC）和validation system chainc（VSCC）。

Evaluation

为了测试，Fabric设计了一种UTXO模型的代币，简称Fabcoin。通过一个chaincode不断产生SPEND和MINT transactions，分别模拟Fabcoin的产生和销毁。

实验1：测试block size和Throughput关系，结论是在block size超过2MB之后TPS不再显著提升；不同transaction的size略有差别，比如MINT transaction因为需要带有CB验证所以更大。

实验2：性能测试，

结论是validation是主要瓶颈，但随着vCPU增加得到了缓解，但是endorsement由于很难并行因此提升有限。32-vCPU peers可以达到3560 tps（SPEND only）和3420 tps（MINT only）；

实验3：RAM disk，tmpfs相比SSD提升了9%；

实验4：Scalability，