星云研究院：IBM 联盟链最新成果，Hyperledger Fabric 全方位分析

摘要：《Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains 》，该论文介绍了 IBM 在联盟链方向的最新研究成果。

作者：星云研究院资深研究院汤载阳博士。华中科技大学计算机博士，日本会津大学和法国南巴黎国立电信学院访问学者，研究方向包括分布式系统、无线网络和区块链共识，在 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，

—-

编译者/作者：链闻研究院

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。