Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains

出处：arvix 17 Apr 2018

下载链接：https://arxiv.org/pdf/1801.10228.pdf

Abstract

Introduction

Background

Architecture

不足

优势

Fabric Components

Evaluation

思考

Abstract

Fabric是一个可以部署和操作许可区块链的模块化、可扩展的开源系统。

Fabric是第一个运行去中心化程序的可扩展区块链系统，它支持模块化的共识机制，允许系统针对特定的场景和信任模型进行定制，Fabric使用标准通用编程语言编写去中心化程序，不需要系统依赖本机的加密货币。不像一些区块链平台，智能合约的编写只能使用特定的编程语言、依赖加密货币。

Fabric使用灵活的成员身份概念来实现许可模型，该成员身份与行业标准身份管理集成在一起。基于此，Fabric介绍了一种新的区块链设计理念，并改进了区块链处理不确定性、资源浪费和性能攻击的方法。

在这篇论文中，介绍了Fabric的结构、设计决策的基本原理、它最突出的实现和去中心化程序编程模型。通过Bitcoin电子货币的基准测试和实现来评估Fabric，证明了在一些流行的部署配置中，fabric实现了超过每秒3500个交易的端对端吞吐量，在亚秒级的延迟可以扩展到超过100多个peers。

Introduction

区块链在设计弹性应用方面和状态机复制（SMR），当在一些方面存在拜占庭问题：（1）区块链不仅一个，它是多个去中心化应用并行运行；（2）区块链应用是动态部署的（3）程序代码是不受信任的，甚至是恶意的，针对这些问题需要一种新的设计。

order-execute框架：已有的智能合约区块链实现了主动复制，它就是一个共识协议或原子传播，一、对交易排序并传播给所有节点；二、每个结点按序执行交易。每个结点都执行每笔交易，并且交易是确定的。order-execute框架存在于现有的所有区块链系统，如公有链Ethereum（基于POW共识），私有链Tendermint、Chain、Quorum.

在此之前的许可链（私有链）存在许多缺陷，它来源于它未许可的关系或order-execute框架。（1）共识机制被硬编码到平台中；（2）交易验证的信任模型需要共识机制确认，并且不能适应智能合约的要求；（3）智能合约被不标准或特定场景的语言编写，阻碍了它的广泛适用性；（4）所有对等方按序执行交易限制了性能，采取复杂的操作阻止平台的DOS攻击；（5）每个智能合约运行在所有对等点，这与机密性不符。

本篇论文提出的Hyperledger Fabric是第一个去中心化的操作系统，Fabric的结构是一个新型的execute-order-validate范式，可以在不信任环境中去中心化的执行不信任代码。它将交易流分为三步，运行在系统的不同实体（1）执行一个交易并检查它的正确性，从而确定他（对应于其他区块链中的交易验证）；（2）通过一个共识机制排序，而不管交易本身；（3）根据每一个特定应用的信任假设来进行交易验证，并且可以阻止由于并发导致的竞争。

这个设计与order-execute范式不同，Fabric在达成最终订单协议之前执行交易，他有两种复制方式：被动和主动。一、Fabric使用被动或主备复制的方式，这在分布式数据库中很常见，但是具有基于中间件的非对称更新处理，并移植到具有拜占庭错误的不受信任的环境。二、Fabric结合主动复制，即交易对账本状态的影响只有在他们总的顺序达成共识后才被写入，每一个对等方单独执行确定的验证步骤。总的来说，这个hybrid复制设计在拜占庭模式中混合了被动和主动复制，execute-order-validate范式，代表了Fabric框架中的主要创新，这些解决了前面提出的问题。

为了实现这个框架，Fabric包含以下组件的模块化构建块：（1）排序服务（Ordering Service），原子化的广播状态更新到对等点，建立交易顺序的共识；（2）成员关系服务提供者（MSP），负责使用加密的身份认证关联对等点，保持Fabric的许可特性；（3）点对点聊天服务（Gossip）（可选），通过排序服务传播块输出给所有对等点。（4）智能合约，在容器环境内运行以进行隔离，用标准的编程语言编写但不能直接访问账本状态；（5）每个对等点以仅附加区块链的形式本地维持一个账本，并作为最新状态的快照以键值存储。

Background

所有的区块链系统，不管是私有还是共有，都使用order-execute框架。区块链网络先使用共识机制排序交易，然后在所有节点顺序执行交易。比如基于Pow的区块链Ethereum，order-execute框架如图所示：

已有的私有链如Tendermint、Chain、Quorum，不管他们使用BFT共识还是其他的原子广播协议，它实际上还是使用的order-execute方法，和典型的主动SMR。

order-execute结构存在许多缺陷：（1）顺序执行，在所有节点上顺序执行交易限制了有效的吞吐量，DOS攻击损害了区块链的性能。为了解决这种问题，公有链对执行消费使用加密货币账户，比如Ethereum使用gas的概念，但这个对私有模型是不适用的，因为它没有本地加密货币账本。去中心化系统文献又提出了一个提高性能的方法，就是并行执行不相关的操作，但不幸的是，所有的方法仍然只能适用于有智能合约的区块链环境。（2）不确定性代码，另一个问题就是order-execute结构是一个不确定的交易。仅一个恶意目的创建的非确定性合约足够是整个区块链瘫痪。一个解决办法就是在区块链上过滤分散的操作，但他仍在被研究，实际用不太可能。（3）执行的机密性，根据公有链的构图，许多私有系统在所有节点运行所有智能合约，然而对私有链有特定使用场景要求私密性，虽然有加密技术实现了机密性，比如从数据加密到高级零知识证明和计算验证，但他带来了相当大的开销。已有的系统仍存在许多缺陷，如固定的信任模块、硬编码的共识机制等。我们认为区块链的关键属性是一致性、安全性和性能。

Architecture

Fabric是一个私有链的去中心化操作系统，他执行使用通用编程语言（如Go，Java，Node.js）编写的去中心化程序。他在仅追加复制的账本数据结构中安全的追踪执行历史，并且没有内置的加密货币。它的execute-order-validate区块链结构如图：

总而言之，Fabric的去中心化应用包含两个部分：（1）smart contract（智能合约)，也叫作chaincode，他是去中心化应用的核心部分，并且可能是被不受信任的开发者写的。（2）endorsement policy（背书策略），他不能被不信任的应用开发者选择或修改，只有设计管理员才有权利修改。

Fabric区块链由一组形成网络的节点组成，如图所示，所有的节点都有一个MSP提供的身份。其中，（1）Clients提交交易文案去执行，然后广播交易排序；（2）Peers执行交易并验证，所有的peers都维持一个区块链账本，以hash链的形式记录交易和状态。不是所有的peers执行所有的交易，只有endorsing peers才可以；（3）OSN是所有构成ordering service的节点，ordering service在Fabric中建立了所有交易的排序，每个交易都包含了在执行阶段的状态更新和扩展计算，和endorsing peers的加密签名。Fabric支持多个区块链连接相同的排序服务（ordering service），这样每个区块链叫做频道（channel）,并且它的成员可以有不同的对等点。

Fabric的交易流如图所示：

执行阶段（Execution Phase）：在执行阶段，客户端签名并发送交易方案给一个或多个背书者（endorsers）。每个chaincode都通过背书策略隐型指定了一系列的背书者。背书者通过执行特定chaincode的操作来仿真交易方案。区块链的状态被PTM（peers transaction manager）以键值存储版本的形式维持，这个状态不能被另外一个chaincode直接访问，如果给定许可，可以在相同频道中调用。仿真的结果是：每个背书者产生一个writeset和readset，仿真之后，背书者加密签名一个消息，叫做背书（endorsement），然后把它发送给client。Client收集背书直到满足chaincode的背书策略，然后client产生一个交易把它发送给ordering service。

排序阶段（Ordering Phase），在排序阶段，每个频道给所有提交的交易建立整体排序，即原子广播式的对背书进行排序，并在交易中建立了共识。排序服务给节点提供了两个功能调用：（1）broadcast(tx)，客户端调用该功能去广播一个任意的交易tx；（2）B<—deliver(s)：客户端调用该方法使用非负序列数s去获得区块B。区块中包含一系列的交易[tx1,……,txk]和哈希链值h（h=s-1）,即B=（[tx1,……,txk]，h）

验证阶段（Validation Phase），区块通过排序服务或者gossip传递给对等点。新区块验证阶段包含以下三步：（1）背书政策评估，并行出现在区块中所有交易。通过VSCC进行评估，如果不满足，则交易无效；（2）读写冲突检测，区块中的所有交易顺序执行，每个交易它比较readset中的键值版本，如果不匹配，则交易无效；（3）账本更新阶段，区块被附加到本地存储账本并且区块链状态改变。Frabric的账本包括所有的交易（也包括那些无效的）

Fabric是固定的信任错误模型，通常认为客户端是潜在的恶意者，节点都被放在一个组织内，同一组织内的所以节点互相信任，不同组织内节点不信任。

不足

在Fabric中，标准的背书策略是要求多个背书者产生相同的结果。如果在访问系统键时竞争激烈，客户端可能无法满足背书策略。

优势

在排序阶段（ordering phase）之前先执行交易是非常重要的，在Fabric中，一个不确定交易的chaincode只会影响他自己的操作，因为client没有获得足够多的背书（endorsement）。这是他区别于order-execute结构的一个优势，因为不确定操作会导致节点状态的不一致。并且容忍不确定执行也可以解决DOS攻击，因为背书者可以根据本地策略中止执行，如果他怀疑他是一个DOS攻击。

Fabric是第一个完全将共识从执行和验证中分离的区块链系统。

Fabric Components

Fabric使用Go语言编写，使用gRPC框架在clients、peers、orderers之间通信，一个对等点的组件如图所示：

成员关系服务提供者（MSP）维护系统中所有节点（clients、peers、OSNs）的身份标识，并发行证书用于认证和授权。构建区块链网络时，有两种模式：离线模式，CA生成身份标识并分配给所有节点，peers和orderers只能在离线模式中进行注册，client注册Fabric-CA提供在线模式，给他们提供加密证书。

排序服务（ordering service）管理多个channels（也就是区块链）。对每个频道，它提供以下服务：（1）原子广播在交易中建立排序；（2）频道重配置，当他的成员通过广播配置更新交易来修改频道；（3）访问控制（可选），配置使排序服务作为一个信任实体，限制交易广播和只能接收特定客户和对等点的区块。OSNs是对等点和原子广播中的一个代理。

节点通信（peer gossip），gossip组件的目标是：将状态转移到一个新加入的节点，以及长期断开的对等点。它利用组播方式来实现。gossip的通信层基于gRPC并且使用手动认证利用TLS。Gossip在系统中维护在线节点的最新成员关系视图，所有节点单独建立一个本地的关系视图。

账本（Ledger），ledger组件在每个节点长久维护一个账本和状态，存在于仿真、验证和账本更新阶段，同时它还包含一个区块存储和节点交易管理。Ledger的区块存储以仅附加文本的方式永久的存储交易区块。节点交易管理（PTM）以键-值版本的形式维护最新的状态信息。

链码执行（chaincode execution），链码在其他节点中被执行，并提供插件可以添加其他编程语言。链码和节点之间通过gRPC信息进行通信，节点不知道链码是用什么语言写的。但是系统链码可以直接运行在节点进程中。

配置和系统链码（configuration and system chaincode），Fabric通过频道配置和系统链码进行定制。配置区块维护频道的配置，它里面不存在交易。每个区块链开始于一个配置区块，这就是创世块，它用于启动频道。更新频道配置使用频道配置更新交易。应用链码使用ESCC和VSCC进行部署，选择则两个链码，可以验证ESCC的输出（背书）是VSCC输入的一部分。ESCC将交易提案和提案模拟结果作为输入，如果结果满足，ESCC做出响应（包括结果和背书）。VSCC将交易作为输入，并验证其是否有效。

Evaluation

由于没有标准的区块链测试标准，在该论文中，使用Fabric coin评估Fabric性能。

Fabric coin使用UTXO加密货币模式，并介绍了Fabcoin实现包含以下三个部分：（1）客户端钱包，每个Fabric客户端维护一个本地存储的钱包，对SPEND交易和MINT交易有不同的处理方式。（2）Fabcoin链码，每个对等点都运行Fabcoin的链码，对仿真进行交易并创建readset和writeset，这里只是对SPEND交易进行操作。（3）定制VSCC，使用该工具每个对等点可以验证Fabcoin交易，它在各自公钥下验证signs中的加密签名，并对SPEND和MINT交易分别进行验证，验证方法不同。但是VSCC验证不能解决双花问题，需要使用PTM验证解决双花问题，PTM验证进行read-write冲突检测。PTM验证中，当前版本信息存储在账本中，并匹配readset中的一个，因此，在第一个交易的货币状态版本已经改变后，第二个排序后的交易将会被认为无效。

思考

（1）Fabric是一个运行私有链的模块化、可扩展的去中心化操作系统，提出了一个新的区块链结构execute-order-validate，该结构与常用区块链结构相比，是将执行放在了交易排序之前，将共识机制模块化。