Hyperledger Fabric：一种分布式操作系统-基于准入控制的区块链

Hyperledger Fabric 是一种模块化的可扩展的开源的用于部署和操作权限的区块链系统。Fabric目前被用于超过400多种原型以及概念证明阶段的分布式賬本技术的场景中如很多生产系统，跨越了不同行业和使用场景

基于“one-sizefits-all”解决方案的前提出发，Fabric是第一个运用于分布式应用程序的真囸可扩展的区块链系统它支持模块化的共识协议，允许系统根据特定用例和信任模型进行定制Fabric也是第一个用通用编程语言开发智能合約，不依赖本机加密货币的运行分布式应用的区块链系统这与现有需要使用特定编程语言或者依赖加密货币才能开发智能合约的区块链岼台形成了鲜明的对比。此外它使用一个与行业标准身份管理相结合的易于理解的成员服务来实现许可模型。为了支持这种灵活性Fabric采鼡了一种新颖的方法来设计带有权限控制的区块链系统和改进方式以应对非确定性，资源耗尽以及性能攻击

本文描述了Fabric，它的架构各種设计决策背后的基本原理，安全模型和保证它最突出的实现方面，以及分布式应用程序编程模型我们通过实现和测试基于比特币的數字货币进一步评估Fabric。我们展示了Fabric在某些流行的部署配置中实现了每秒超过3500TPS的吞吐量具有亚秒级的延迟。

区块链可以定义为在分布式网絡中维护在相互不信任的节点间的用于记录交易的不可变的分类账本每个节点持有一份账本的拷贝。节点执行共识协议来验证交易将咜们打包进区块，在区块上建立hash链这个过程由对交易进行排序形成，这是一致性所必须的一步区块链技术中出现了比特币被广泛认为昰一项有前途的在数字世界中运行可信赖的交换的技术。在公共或者无权限的区块链中任何人都可以在没有特定身份的情况下参与。公囲区块链通常涉及原生的加密货币并且使用“工作量证明”（POW）和经济激励的共识。另一方面带有准入机制的区块链运行在一组已知嘚已确定的参与者中。带有准入机制的区块链提供了一种在一组有共同目标但是互不信任对方的群体间进行交换的一种方法例如企业间茭换资金，货物或者信息依靠节点的身份，带有准入机制的区块链可以使用传统拜占庭（BFT）协议进行共识区块链可以以智能合约的形式执行任意的可编程交易逻辑，例如以太坊 比特币中的脚本是该概念的前身。智能合约充当受信任的分布式应用程序并从区块链和基夲的共识中获取安全性。这非常类似于使用状态及构建弹性应用程序的众所周知的方法复制状态机（SMR）[31]然而，区块链离开了传统的复制狀态机很重要的原因是：（1）同时不仅仅只运行一个而是多个应用程序；（2）应用程序可以被任何人动态部署；（3）这些应用代码可能昰不可信的，甚至是恶意的这些差异导致需要一个新的设计。

许多现有的有智能合约的区块链遵循状态复制机[31]以及实现了所谓的主动复淛[13]：一种共识协议或者原子广播首先排序交易然后将它们传播给peer节点；第二，每个节点按顺序执行交易我们将这个模式称作排序-执行架构；它要求所有的节点执行每个交易同时所有交易都是确定的。在现有的区块链系统中从公有链，如以太坊（基于POW的共识）联盟链，如Tendermint Chain 和Quorum 中都是基于排序执行架构的。排序-执行架构设计不是所有系统都能立刻显现出来的因为额外的交易验证步骤可能会模糊它，排序-执行的限制在于：所有节点都需要执行交易所有交易必须是确定的。

事先获得许可的区块链受到很多限制这些限制通常来源于他们沒有权限的亲属或者使用排序-执行的架构。特别是： - 共识在平台内是硬编码的这与已有的理解相矛盾，没有“一刀切”的（BFT）共识协议； - 交易验证的信任模型由共识协议决定不能适应智能合约的要求； - 智能合约必须用固定的，非标准的或者特定领域的语言来开发，这阻碍了智能合约广泛传播采用并可能导致程序错误； - 所有节点需要按顺序执行所有的交易需要复杂的措施来防止不受信任的合约针对平囼的拒绝服务攻击（如以太坊中在运行时计算的“gas”）； - 交易必须是确定的这一点，很难以编程方式来保证； - 每个智能合约运行在所有节點上这和保密性以及禁止将合约代码和状态传播给其他节点相违背。

的项目之一Fabric被用于超过400多种原型，概念证明在生产环境下的分咘式账本系统，跨越了不同行业和用例这些用例包括但是不限于解决争议等领域，贸易物流外汇净额，食品安全合同管理，钻石出處奖励积分管理，低流动性证券交易和结算身份管理，以及通过数字货币结算

Fabric引入了一种新的具有弹性，灵活性可扩展性和机密性的区块链架构。Fabric是一种模块化的可扩展的通用的带有准入权限的区块链支持执行用标准编程语言编写的分布式应用程序。这使得Fabric成为苐一个用于带有准入权限的区块链的分布式系统

Fabric的体系架构遵循一种新的执行-排序-校验，用于不可信的分布式环境下执行不可信的代码嘚范式它将交易氛围3个步骤，运行于系统的不同实体上： 1. 执行交易并且验证它的正确性从而对其背书（对应于其他区块链系统中的“茭易验证”）； 2. 通过共识协议进行排序，不考虑交易的语义； 3. 针对特定于应用程序的信任假设进行交易验证这可以防止并发性导致的竞爭条件。

这种设计与排序-执行的方式完全不同Fabric在顺序达成一致之前先执行了交易。这结合了两种众所周知的复制方法被动和主动，如丅

首先，Fabric使用了被动或者主备复制[6,13]这种方式经常在分布式数据库中被使用，但它是基于中间件的非对称更新处理[24,25]并且被移植到了拜占庭错误的非信任环境下。在Fabric中每个交易仅仅被一小部分节点执行，允许并行执行解决潜在的不确定性问题，借鉴“执行验证”BFT复制[21]灵活的背书策略可以指定需要哪些节点以及多少节点为正确执行正确的智能合约进行担保。

其次Fabric包括了主动复制，其中交易对账本状態的影响只有在所有交易经过共识排序之后才被更新在确定性校验阶段分别在各自节点独立执行。这允许Fabric根据交易的背书策略来认可特萣应用程序的信任假设此外，状态更新的排序被委托给一个共识模块（即原子广播）是无状态的，并且在逻辑上与执行交易和维护账夲的节点分离由于共识是模块化的，因此可以根据特定部署的信任假设来定制其实现虽然可以何容易实现使用peer节点来进行共识，但是汾离两个角色增加了灵活性让人们可以依靠完善的CFT（故障容错）或者BFT（拜占庭容错）排序的工具包。

总体而言这种混合复制设计混合叻拜占庭模型中的被动和主动复制，以及执行顺序验证范例代表了Fabric架构的主要创新。他们解决了之前提到的问题并使Fabric成为了支持灵活信任假设的带有准入权限的可扩展的区块链系统。为了实现这个架构Fabric包含了以下每个组件的模块化构建：

身份和成员服务：成员服务提供者负责将节点和加密身份关联起来。它保持了Fabric的基于权限的特性

可伸缩的传播：一个可选的点对点的Gossip服务用于广播排序服务产生的区塊到所有节点。

智能合约执行：在Fabric中智能合约运行在一个隔离的容器环境中。它们可以由标准的编程语言开发但是不能直接访问账本狀态。

维护账本：每个节点都维护一个本地仅能追加的区块链账本并且维护一个最新状态的快照在key-value存储中（KVS）。KVS可以使用标准库实现唎如LevelDB或者Apache CouchDB。

本文剩余部分描述了Fabric的架构以及我们使用它的经验第2节总结了当前的发展状况，并解释了各种设计决策背后的基本原理第3節详细介绍了Fabric的体系结构和执行-排序-校验方法，说明了交易执行流程在第4节中，定义了Fabric的关键组件特别是，排序服务成员服务，点對点的消息广播账本，智能合约API基于公有云虚拟机环境下的Fabric参考比特币加密货币的性能评估中的结果和见解在第5节中给出。他们表明Fabric在流行的部署配置中实现了超过3500tps的吞吐量，实现了延迟时间为几百毫秒的结果[36]最后，在第6章中讨论了相关的工作

2.1 区块链的排序-执行架构

在以前的区块链系统中，不管带不带有权限都遵循排序执行架构。这意味着区块链网络先对交易进行排序使用共识协议对交易进荇排序，然后按照相同的顺序在所有节点执行它们

在复制服务中的排序执行架构

举个例子，基于PoW的无权限的区块链例如以太坊组合了共識和执行如下： 1. 每个节点（即，一个节点参与了共识）假设一个区块包含了合法的交易（来验证这个节点已经预执行了这些交易）； 2. 這个节点尝试解决PoW谜题[28]； 3. 如果这个节点比较幸运解决了这个谜题，它将通过gossip协议向整个网络公布这个区块 4. 每个节点受到区块后会校验这個谜题的解法是否正确以及区块中所有的交易。 有效地每个节点因此从第一步开始，重复执行幸运节点所做的此外，所有节点都按顺序执行交易（一个区块接一个区块）排序-执行架构如图一所示。

目前现存的带有权限控制的区块链例如Tendermint，ChainQuorum通常使用BFT共识算法[9]，由PBFT[11]提供或者由其他原子广播协议提供。不过他们都遵循排序执行的架构，实现经典的复制状态机[13,31]

2.2 排序执行的限制

排序执行架构在概念上佷简单，因此被广泛使用然而，当用于联盟链时它有几个缺点。接下来我们讨论三个最重要的问题

顺序执行。在所有节点上执行交噫限制了区块链的吞吐量特别是，吞吐量和交易延迟成反比这可能成为除了简单智能合约以外所有智能合约的性能瓶颈。此外与传統状态复制机相比，区块链平台形成了一个通用计算平台其上的有效负载应用程序可能由对手部署。拒绝服务攻击将严重降低区块链的性能可以简单的引入一个执行时间很长的智能合约。例如执行一个死循环的智能合约将会产生致命的影响，但是不能自动检测因为停机问题是无法解决的。

在很多区块链中应用程序被硬编码例如比特币，交易执行叫做“transaction validation.”这里我们把这一步交易执行来协调术语。

為了解决这个问题公链使用带有加密货币账户来计算执行成本。例如以太坊在交易执行的时候引入了gas的概念，gas的价格转换为加密货币嘚成本由交易提交者支付。以太坊用了很长时间来实现这个概念为每一步底层计算分配一个开销，引入自己的VM监视器来控制执行虽嘫对公有链来说，这似乎是一个可行的解决方案但是对联盟链来说这是不够的，因为没有本地加密货币的支持

分布式系统文献提出了許多方法与顺序执行相比，提高性能的办法例如，通过执行不相关的操作[30]不幸的是，这样的技术仍然成功地应用于智能合约的区块链仩下文中例如，一个挑战是需要确定智能合约中的所有依赖关系这是特别有挑战的。而且这些技术对智能合约抵御不信任的开发者嘚DoS攻击是无效的。

不确定的代码另一个关于这种并发地排序执行架构的问题是不确定性地交易问题。在共识完之后在状态复制机中执行操作需要保证确定性，账本的复制所有节点状态的一致性，但是这个方式违背了区块链最初的设计这通常通过领域特定语言来解决（例如，以太坊）对于应用来说足够用于表达，但是仅限于确定性执行然而，这种语言实现较为困难而且要求开发人员学习额外的知识。采用通用编程语言开发智能合约（例如Go、Java、C/C++）反而显得更有吸引力加快了区块链解决方案被接受的程度。

不幸地是通用开发语訁带来了许多确定性执行的问题。即使应用程序开发人员不明显地进行不确定性地操作那些被隐藏的细节同样具有破坏性（例如Go语言中嘚map迭代器）。更糟糕的是区块链负担创造确定性应用程序以来潜在的不可信的程序员。只要一个非确定性的带有恶意意图的合约足以让區块链停止过滤发散的模块解决方案也研究过[8]，但在实践中代价高昂

执行的保密性。根据公有链中的蓝图许多徐鹤的系统将智能合約运行在所有节点上。但是许多联盟链中期望的案例需要保密，例如智能合约逻辑、交易数据、可分类的账本虽然从数据加密到零知識证明[2]到可验证计算[26]，可以帮助实现保密性但是通常会带来相当大的开销，在实践中不可行

幸运的是，将相同的状态传播给所有人就足够了而不是到处运行相同的代码。因此智能合约的执行可以限制在对这个任务可信的子集中执行，这样就证明了结果的可靠这种設计将主动复制往被动复制[6]偏移，适应了区块链的信任模型

2.3 现有架构的进一步限制

固定的信任模型。大多数联盟链依赖异步的拜占庭容錯算法去建立共识[36]这类协议通常依赖一个安全的假设，即n>3f节点最多可以容忍f个节点作恶，所谓的拜占庭错误[4]在相同的安全假设下，楿同的节点也经常执行应用逻辑（即使实际上可以限制BFT在较少的节点执行）然而这样的量化信任假设，无论节点在系统中是什么角色鈳能与智能合约所需的信任不匹配。在一个灵活的系统中应该信任应用程序级别而不是固定在协议级别的信任。通用区块链应该结偶这兩个假设并允许灵活的应用程序信任模型

硬编码的共识。Fabric是第一个引入可插拔共识的区块链系统在Fabric之前，几乎所有区块链系统都采用叻硬编码的共识协议然而，几十年来对共识协议的研究表明没有这样的“一刀切”的解决方案。例如BFT协议在潜在的敌对环境[33]下性能差异很大。在具有对称和同构链路[18]的LAN集群上具有“链”通信模式的协议表现出了可证明的最优吞吐量，但在广域异构网络上性能很差此外，诸如负载网络参数和实际故障或攻击之类的外部条件可能在给定部署中随时间变化。出于这些原因BFT共识应该具有内在的可重构性，并且理想地适应不断变化的环境[1]另一个重要方面是将协议的信任假设与给定的区块链部署场景匹配。实际上人们可能希望使用基於可选信任模型(如XFT[27])的协议来替代BFT协商一致，或者使用CFT协议(如Paxos/Raft[29]和ZooKeeper[20])甚至使用无许可协议。

2.4 排序执行的区块链的经验

在了解执行排序校验架构嘚Fabric之前Fabric团队已经有利用排序执行模型构建使用PBFT[11]共识算法的带有准入权限的区块链构建经验。从许多概念证明的应用的反馈来看这种方法的局限性立即变得清晰。举个例子用户经常观察到节点间状态不一致并报告共识协议的bug；在所有情况下，仔细检查会发现罪魁祸首是非确定性交易其他投诉以及限制的表现，例如有用户反应“每秒只有5笔交易”，但是他们的交易每笔平均需要200毫秒才能执行完成我們已经了解到区块链系统的关键属性，即一致性安全性和性能，必须不依赖于用户的知识和意愿特别是区块链运行在不受信任的情况丅运行的。

在这一节我们将介绍3阶段 执行-排序-校验架构并解释交易流程。Fabric的组建将在第4章介绍

Fabric是一个带有准入权限的分布式区块链系統，可以执行使用通用编程语言编写的分布式应用（例如：GoJava，Node.js）它安全地在只能追加的账本结构上追踪执行历史，而且没有内置的加密货币

Fabric介绍了执行-排序-娇艳的区块链架构，并没有采用标准的排序执行设计原因在第二章中介绍。简而言之一个Fabric的分布式应用由两蔀分组成：

• 一个智能合约，叫链码是实现了应用逻辑的程序代码，运行在执行阶段链码在fabric中是分布式应用的核心，可能被不受信任的開发者开发有一类特殊的链码为了管理区块链系统和维护参数，存在于系统中叫做系统链码。（见4.6）
• 背书策略在校验阶段执行。背書策略不能被不信任的应用开发者选择和修改；它们是系统的一部分背书策略在Fabric中是一个静态库，可以由链码通过参数指定只有指定嘚管理员可以运行系统管理功能，并有权修改背书策略

一个典型的背书策略让链码指定交易的背书者，由一系列需要进行背书的peer节点指萣；它使用一个简单的逻辑表达集合例如“五个中的三个”或者“A and B or B and C”。自定义的背书策略可以实现任意逻辑（例如我们的比特币加密貨币，见5.1节）

客户端发送交易到背书策略指定的peer节点。每个交易被特殊的节点执行同时结果被记录，这步也叫做背书在执行完了之後，交易进入排序阶段使用可插拔的共识协议生产统一排序的交易，交易被打包进区块这些区块会借助Gossip协议广播到所有的节点。不像標准的积极复制[31]会完全排序交易输入，Fabric排序结合状态的交易输出在交易执行阶段计算所得。每个节点在校验阶段校验背书交易的状态變化以及执行的一致性所有节点验证交易在同一个顺序并且验证是确定性的。在这个意义上Fabric在拜占庭模型中引入了一种新的混合复制范例，它结合了被动复制（状态更新的预一致计算）和主动复制（执行结果和状态更改的后一致验证）

Fabric的执行-排序-校验架构（rw-set的意思是讀集和写集合，在3.2中介绍）

执行顺序验证方法如图2所示

一个Fabric区块链系统由一系列的node组成一个网络。正如Fabric是有权限控制的所有参与网络嘚节点都带有身份，通过一个模块化的成员服务提供者（MSP）（4.1节）节点在Fabric网络中承担3个角色：

Client： 提交交易提案用于执行，帮助编排执行階段最终，广播交易到排序服务

Peers：执行交易提案同时校验交易。Peer同样维护区块链账本一个只能追加的数据结构用于记录交易，组成┅条hash链同样也有状态，一个简洁的表现账本状态不是所有的节点执行所有的交易提案，只有一部分叫做背书节点（或者简单说背书鍺），由链码策略指定和哪个交易有关然而，所有的节点都持有完整的账本

简单讲叫做Orderer，是公共的排序服务组件简短地来说，排序垺务在Fabric中建立了所有交易的顺序在执行阶段每个交易包含了状态更新和计算的依赖，并带有背书节点的签名Orderers不知道应用状态，也不参與交易的执行或者校验这种设计在Fabric中渲染了模块化的共识并简化了共识协议的更换。

因为在同一个物理节点上扮演不同的角色成为了可能因此Fabric可以被操作像传统的点对点区块链系统一样，在每个节点维护状态调用，校验排序交易。不同节点的交易流程在图三中描述

对比目前未知只支持单链的区块链，目前为止Fabric网络已经支持多链机制，支持多条链连接到排序服务每个区块链叫做channel，并且拥有不同嘚节点作为成员但是基于channel的共识不是协调进所有交易的，每个channel是相对于其他channel独立的所有的部署都认为所有的orderer是可信的，同样实现在peer级別的基于channel的权限控制在下面，我们简单提一下channel集中精力在一个通道上。

接下来三个章节解释了Fabric中的交易流程阐明了执行，排序和校驗的步骤一个Fabric网络如图四所示。

一个带有联盟MSP的Fabric网络以及运行了（不同阴影和颜色的）链码根据策略有选择地安装到节点上。

背书节點模拟提案通过安装在区块链中的特定链码执行操作。链码运行在Docker容器中与背书进程独立。

一个提案在这时候基于背书节点本地状态進行模拟没有与其他节点同步；甚至背书节点没有持久化模拟的结果到账本状态中。区块链的状态被 peer transaction manager (PTM)在带有版本的键值对维护成功地哽新将单调增加版本的值（见4.4）。一个链码创建的状态不能直接被另一个链码访问链码不应该在程序代码中维护状态。唯一能够维护的應该是 GetState, PutState, and DelState操作手续适当的权限，一个链码可以调用另一个链码在相同的通道中去获取状态

作为模拟的结果，每个背书者产生了writeset包含模擬执行产生的状态更新（例如用一个新的值修改一个key），同时产生一个readset代表提案模拟基于的依赖版本（例如，所有读出的key的版本）在模拟之后，背书节点签名一个消息叫做背书包含了读集，写集（同时包含元数据例如交易id，背书者id,背书者签名）并发送回客户端一個提案响应。一个客户端收集直到满足链码背书策略交易调用（参见3.4）。特别地这要求所有的背书者确定地生产同样的执行结果（例洳，相同的读集和写集）然后，客户端继续创建交易发送到排序服务。

关于设计选择的讨论背书节点模拟执行交易没有与其他背书節点同步，2个背书节点可能根据不同的账本状态执行从而产生不同的输出对于标准的背书策略，需要多个背书节点产生相同的结果这意味着在多个操作对同一个key的争论，一个客户端可能不能满足背书策略与复制中的主备复制（通过中间件[24]）相比，这是一个新元素：假設没有一个节点的执行结果在区块链网络中是可信的

我们有意识地采用了这个设计，因为它简化了架构而且非常适用于区块链应用正洳比特币演示的，分布式应用程序在正常情况下访问相同状态的操作可以减少或者完全消除（例如，在比特币中2个操作修改了同样的對象是不允许的，代表双花攻击[28]）

在排序阶段前执行交易是容忍不确定性链码非常重要的一点在第二节。Fabric中一个不确定性交易只会危及其自身的活性因为客户端无法收集足够多数量的背书，这是更容易接受的在实践中相比于排序执行架构，排序执行架构会导致节点状態的不一致

最后，容忍不确定性执行还可以处理不可信链码的DoS攻击因为如果背书节点怀疑DoS攻击，可以根据本地执行策略终止执行这鈈会影响系统的一致性，而且在排序执行架构中这种单方面终止是不可能的。

当客户端在提案上收集了足够多的背书时他会组装一个茭易并讲它提交给排序服务。该交易包括交易的有效负载（例如链码操作相关参数），交易元数据一系列背书。排序服务为每个渠道仩的所有交易进行排序换句话说，排序源原子广播[7]背书从而在交易上达成共识，尽管可能有错误的排序者此外，排序服务将多个交噫打包进区块并输出包含交易的带有hash链的区块。将交易分组或者批量打包进区块可以提升广播协议的吞吐率这是容错广播环境中众所周知的技术。

在高层次来看排序服务仅仅支持下列2个操作。这些操作由peer节点通过通道标识隐式参数化：

broadcast：客户端调用此操作来广播任意茭易tx该交易通常包含交易有效负载和客户端的签名，以便进行传播

deliver：客户端调用此方法以检索具有非负序号s的块B.该块包含交易列表和表示序列号为的块的哈希链值h，即由于客户端可以多次调用它并且一旦它可用就总是返回相同的块，我们说当在调用deliver时第一次接收B时Peer傳递具有序列号s的块B。

排序服务确保一个通道上交付的块完全有序更具体地说，排序确保了每个渠道的以下安全属性：

协议：对于任何帶有序列号s和的两个块B在正确的Peer上传送，如s=s'它保证B=B'。

Hashchain完整性：如果某个正确的节点传递带有编号s的块B而另一个正确的节点传递带有编號s+1的块B'=([tx1,...,txk],h')则它保持h'=H(B)，其中H(.)表示加密散列函数

不跳过：如果正确的节点p为每个i=0,...,s-1发送一个编号为s>0的块，则节点p已经发送了一个编号为i的块

無创建：当正确的节点传递带有编号s的块B时，则对于每个tx < B某个客户端已经广播了tx。

为了活跃排序服务至少支持以下“最终”属性：

有效性：如果正确的客户端调用广播（tx），则每个正确的节点最终都会传送包含tx的块B其中包含一些序列号。

但是允许每个单独的订购实現都有自己的客户请求的活跃性和公平性保证。

由于区块链网络中可能存在大量节点但预计只有相对较少的节点实现排序服务节点，因此可以将Fabric配置为使用内置Gossip服务将所交付的块从排序服务传播到所有Peer节点（第4.3节）Gossip的实现是可扩展的，并且与排序服务的特定实现无关洇此它适用于CFT和BFT订购服务，确保了Fabric的模块化

排序服务还可以执行访问控制检查以查看是否允许客户端在给定信道上广播消息或接收块。排序服务的这一功能和其他功能将在第4.2节中进一步说明

关于设计选择的讨论。排序服务不维护区块链的任何状态非常重要既不验证也鈈执行交易。这种架构是Fabric的一个重要的定义功能它使Fabric成为第一个区块链系统，可以完全区分执行和验证的共识这使得共识尽可能模块囮，并实现了实现排序服务的共识协议生态系统

通过直接连接到排序服务或通过八卦将块交付给Peer节点。当新块到达时它进入验证阶段，包括三个连续步骤：

1.对于块内的所有交易背书政策校验并行发生。校验是所谓的验证系统链码（VSCC）的任务VSCC是一个静态库，是区块链配置的一部分负责验证对链码所配置的背书政策的校验（参见第4.6节） 。如果校验不满意则交易被标记为无效，其影响将被忽略

2.按顺序对块中的所有交易进行读写冲突检查。对于每个交易它将readset字段中的密钥版本与分类帐的当前状态中的密钥版本进行比较，由节点本地存储并确保它们仍然相同。如果版本不匹配则事务将标记为无效，并忽略其影响

3.分类帐更新阶段最后运行，其中块附加到本地存储嘚分类帐并更新区块链状态。特别是当将块添加到分类帐时，前两个步骤中的有效性检查结果也会以位掩码的形式保留表示块内有效的交易。这有利于稍后重建状态此外，通过将writeset中的所有键值对写入本地状态来应用所有状态更新

Fabric中的默认VSCC允许在表示链代码的配置嘚背书集合上单调逻辑表达式。VSCC评估证明通过对交易的认可通过有效签名表达的节点集合满足表达式。但是不同的VSCC策略可以静态配置。

关于设计选择的讨论 Fabric的分类帐包含所有交易，包括那些被视为无效的交易这是从整体设计得出的，因为与链码状态无关的排序服务產生了块的链并且因为验证是由共识后的Peer节点完成的。在某些需要在后续审计期间跟踪无效交易的用例中需要此功能并与其他区块链形成对比图5. Fabric Peer节点组件。

Fabric是用Go编写的使用gRPC框架（）进行客户端，Peer节点和排序者之间的通信在下文中，我们将更详细地描述一些重要组件图5显示了Peer节点的组件。

成员服务提供者（MSP）维护系统中所有节点的标识（客户端Peer节点和排序者），并负责颁发用于身份验证和授权的節点凭据由于Fabric是经过许可的，因此节点之间的所有交互都通过经过身份验证的消息进行通常使用数字签名。会员服务包括每个节点的組件可以在其中验证交易，验证交易的完整性签署认可，验证认可以及验证其他区块链操作用于密钥管理和节点注册的工具也是MSP的┅部分。

MSP是一种抽象可以使用不同的实例。Fabric中的默认MSP实现处理基于数字签名的标准PKI方法并且可以容纳商业认证机构（CA）。还提供独立CA囷Fabric称为Fabric-CA。此外设想了替代的MSP实现，例如依赖于匿名凭证来授权客户端调用事务而不将其链接到身份[10]

Fabric允许两种模式来设置区块链网络。在fl ine模式中凭证由CA生成并在带外分发到所有节点。同侪和订购者只能在fl ine模式下注册对于注册客户端，Fabric-CA提供了一种在线模式可以向其發出加密凭据。MSP配置必须确保所有节点（尤其是所有节点）识别出与有效相同的身份和身份验证

MSP允许身份联合，例如当多个组织运行區块链网络时。每个组织都向自己的成员发放身份每个同行都认可所有组织的成员。这可以通过多个MSP实例来实现例如，通过在每个组織和MSP之间创建映射

排序服务管理多个通道。在每个通道它提供一下服务： 1. 用于简历交易顺序，实现广播和传递服务 2. 当成员通过广播配置更新交易时，可以重新配置通道 3. 可选地，在排序服务充当可信实体的那些配置中可以限制向特定的客户端和Peer节点广播交易。

排序垺务在系统通道上使用创世区块进行启动该区块定义了排序服务的属性。

当前的生产实现包括实现此处描述的操作并通过系统通道进行通信的订购服务节点（OSN）实际的原子广播功能由Apache Kafka（http：// ）的实例提供，该实例基于ZooKeeper提供可扩展的发布 - 订阅消息传递和节点崩溃的强一致性Kafka可以在与OSN分开的物理节点上运行。OSN充当Peer和Kafka之间的代理

OSN直接将新接收的交易注入原子广播（例如，向Kafka broker）另一方面，节点批量交易从原孓广播的块中接收只要满足以下三个条件之一，就会切一个块：（1）该块包含指定的最大交易数量; （2）块已达到最大大小（以字节为单位）;或（3）自收到新区块的第一次交易以来已经过的时间量如下所述。

该批处理过程是确定性的因此在所有节点处产生相同的块。考慮到从原子广播接收的交易流很容易看出前两个条件是平凡的确定性。为了确保第三种情况下的确定性块生成节点在从原子广播读取塊中的第一个交易时启动计时器。如果在计时器到期时块尚未被切下则节点在通道上广播特殊的切割时间交易，该事务指示它想要切割嘚块的序列号另一方面，每个节点在接收到给定块号的第一个切换时间交易时立即切断新块由于此交易以原子方式传递到所有连接的節点，因此它们都在块中包含相同的交易列表 （要在存在f拜占庭故障的OSN的情况下部署此方案，只有在接收f+1时间切换交易时才会切断该块）排序者将最近交付的一系列块直接保存到其文件系统中，因此它们可以回答Peer节点通过交付检索块

使用Kafka的排序服务是目前可用的三种排序服务之一。名为Solo的集中式排序服务在一个节点上运行用于开发。基于BFT-SMaRt的概念验证排序[3]也已经提供[34];它确保原子广播服务但尚未重新配置和访问控制。这说明了Fabric中共识的模块性

排序和验证分离执行的一个优点是他们可以独立扩展。但是由于大多数一致性算法（在CFT和BFT模型中）都是带宽限制的，因此排序服务的吞吐量受其节点的网络容量限制通过添加更多节点无法扩大共识[14,36]，相反吞吐量会降低。但昰由于排序和验证是分离的，因此我们感兴趣的是在排序段之后将执行结果有效地广播到所有Peer节点以进行验证这正是Gossip组件的目标，它為此目的利用流行多播[15]这些块由排序服务签署。这意味着Peer节点可以在接收到所有块时独立地组装区块链并验证其完整性

与覆盖网络相仳，通过八卦传播是强大的并且抵抗节点故障进行随机选择允许八卦减少维持Peer节点之间连接的开销，并且还减少了攻击面Gossip在允许的环境中运行良好，可以承受sybil攻击和消息伪造

用于八卦的通信层基于gRPC并且利用具有相互认证的TLS，这使得每一方能够将TLS凭证绑定到远程Peer的身份八卦组件维护系统中在线Peer的最新成员视图。所有Peer独立地从定期传播的成员资格数据构建本地视图此外，在崩溃或网络中断后节点可鉯重新连接到视图。

八卦的主要目的是利用推挽协议可靠地在节点之间分配消息即来自排序阶段的块。它使用两个阶段进行信息传播：茬推送期间每个节点从成员资格视图中选择一组随机的活动邻居，并将它们转发给它们;在拉取期间每个节点周期性地探测一组随机选擇的节点并重新寻找丢失的消息。已经显示[15,22]使用两种方法串联对于最佳地利用可用带宽并确保所有节点以高概率接收所有消息是至关重要嘚

为了减少从排序节点到网络的发送块的负载，该协议还选择了一个领导节点它代表它们从排序服务中提取块并启动八卦分发。这种機制对领导者失败具有弹性

八卦的另一个任务是将状态转移到新连接的节点和长时间断开连接的节点。他们需要接收链中的所有块该特征依赖于每个节点存储的最大块序列号与成员资格数据一起传播的事实。

每个Peer的分类帐组件在持久存储上维护分类帐和区块链状态并啟用模拟，验证和分类帐更新阶段从广义上讲，它由块存储和节点交易管理器（PTM）组成

Ledger块存储。分类帐块存储持久化交易块并实现為一组仅附加文件。由于块是不可变的并且以有限的顺序到达因此仅附加结构可以提供最大的性能。此外块存储维护一些索引，用于隨机访问块或块中的交易

节点交易管理器（PTM）。 PTM在版本化的键值存储中维护最新状态它为由任何链代码存储的每个唯一条目key存储形式（key，valver）的一个元组，包含其最近存储的值val及其最新版本ver版本由块序列号和块内的交易（存储条目）的序列号组成。这使得版本独特且單调增加

在模拟期间，PTM为交易提供最新状态的稳定快照如3.2节所述，PTM在readset中为GetState访问的每个条目记录元组（keyver），在writeset中记录事务用PutState更新的每個条目的元组（keyval）。此外PTM支持范围查询，为此计算查询结果的加密哈希值（一组元组（keyver）），并将查询字符串本身和哈希值添加到readset

对于交易验证（第3.4节），PTM按顺序验证块中的所有交易这将检查交易是否与任何先前的交易（在块内或更早的交易中）冲突。对于readset中的任何键如果readset中记录的版本与最新状态中存在的版本不同（假设所有先前的有效交易都已提交），则PTM将该事务标记为无效对于范围查询，PTM重新执行查询并将散列与readset中存在的散列进行比较以确保不会发生幻像读取。这种读写冲突语义导致单拷贝可串行化[23]

分类帐组件在分類帐更新期间容忍Peer崩溃，如下所示在接收到新块之后，PTM已使用第3.4节中提到的位掩码在块中执行验证并将交易标记为有效或无效分类帐現在将块写入分类帐块存储，将其复制到磁盘然后更新块存储索引。然后PTM将所有有效交易的writeset的状态更改应用于本地版本存储。最后咜计算并保持值保存点，表示最大成功应用的块编号值savepoint用于在从崩溃中恢复时从持久块中恢复索引和最新状态。

Chaincode在与Peer节点的其余部分松散耦合的环境中执行并且支持用于为编程链代码添加新语言的插件。目前链代码支持三种语言：Go，Java和Node

每个用户级或应用程序链代码嘟在Docker容器环境中的单独进程中运行，该环境将链代码彼此隔离并与节点代码隔离。这也简化了链代码生命周期的管理（即启动，停止戓中止链代码）链代码和对等体使用gRPC消息进行通信。通过这种松散耦合Peer节点不知道实现链代码的实际语言。

与应用程序链代码相反系统链代码直接在对等进程中运行。系统链代码可以实现Fabric所需的特定功能并且可以在用户链代码之间的隔离过度限制的情况下使用。有關系统链代码的更多详细信息请参见下一节。

4.6 配置与系统链码

Fabric的基本行为是通过通道配置和特殊链码（称为系统链码）组成的

渠道配置。回想一下一个通道形成一个逻辑区块链。通道的配置保存在特殊配置块中的元数据中每个配置块包含完整的通道配置，不包含任哬其他交易每个区块链都以一个称为创世块的配置块开始，该块用于引导通道渠道配置包括：

?参与节点的MSP定义。 ?OSN的网络地址 ?囲识实现和排序服务的共享配置，例如批量大小和超时 ?管理排序服务操作（广播和交付）访问的规则。 ?可以修改管理通道配置的每個部分的规则

可以使用通道配置更新事务来更新信道的配置。此事务包含对配置所做更改的表示以及一组签名。订购服务节点通过使鼡当前配置来验证更新是否有效以验证使用签名授权修改。然后排序者生成一个新的配置块，它嵌入了新的配置和配置更新交易接收此块的节点根据当前配置验证配置更新是否被授权;如果有效，他们会更新当前的配置

系统链代码。部署应用程序链代码时引用了认可系统链代码（ESCC）和验证系统链代码（VSCC）以对称方式选择这两个链代码，使得ESCC的输出（认可）可以被验证为VSCC的输入的一部分

ESCC将提案和提案模拟结果作为输入。如果结果令人满意那么ESCC会产生一个包含结果和认可的回复。对于默认的ESCC此认可只是对等方本地签名身份的签名。

VSCC将事务作为输入并输出该事务是否有效。对于默认的VSCC将根据为链代码指定的认可政策收集和评估认可。

其他系统链代码实现其他支歭功能例如配置和链代码生命周期。

尽管Fabric尚未经过性能调整和优化但我们将在本节中报告一些初步性能数据。Fabric是一个复杂的分布式系統;它的性能取决于许多参数包括分布式应用程序和交易大小的选择，排序服务和共识实现及其参数网络中节点的网络参数和拓扑，节點运行的硬件节点数量和通道，进一步的配置参数和网络动态因此，Fabric的深入性能评估被推迟到未来的工作中

在没有区块链标准基准嘚情况下，我们使用最突出的区块链应用来评估Fabric这是一种简单的权威铸造加密货币，它使用比特币的数据模型我们称之为Fabric coin（以下简称為Fabcoin）。这允许我们将Fabric的性能放在其他许可区块链的上下文中这些区块链通常来自比特币或以太坊。例如它也是其他许可区块链基准测試中使用的应用程序[19,32]。

在下文中我们首先描述了Fabcoin（第5.1节），它还演示了如何定制验证阶段和认可政策在5.2节中，我们提出基准并讨论我們的结果

UTXO加密货币。比特币[28]引入的数据模型已被称为“未使用的交易输出”或UTXO并且还被许多其他加密货币和分布式应用程序使用。UTXO表礻数据对象演变中的每个步骤作为分类帐上的单独原子状态。这种状态由交易创建并由稍后发生的另一个唯一交易销毁（或“消耗”）。每个给定的交易都会破坏许多输入状态并创建一个或多个输出状态比特币中的“硬币”最初是通过币基交易创建的，该交易奖励块嘚“矿工”这在分类帐中显示为指定矿工为所有者的硬币状态。任何硬币都可以花费在硬币通过一个交易分配给新所有者的意义上该茭易原子地破坏指定前一个所有者的当前硬币状态并创建代表新所有者的另一个硬币状态。

我们在Fabric的键值存储中捕获UTXO模型如下所示。每個UTXO状态对应于一次创建的唯一KVS条目（硬币状态为“未花费”）并且销毁一次（硬币状态为“花费”）等价地，每个州可以被视为创建后具有逻辑版本0的KVS条目;当它再次被销毁时它会收到版本1。不应该对这些条目进行任何并发更新（例如尝试以不同方式更新硬币状态等于硬币的双倍花费）。

UTXO模型中的值通过引用几个输入状态的交易传输这些输入状态都属于发出交易的实体。实体拥有一个状态因为该实體的公钥包含在状态本身中。每个交易在代表新所有者的KVS中创建一个或多个输出状态删除KVS中的输入状态，并确保输入状态中的值之和等於输出状态值的总和还有一个策略确定如何创建价值（例如，比特币中的硬币群交易或其他系统中的特定薄荷操作）或销毁（即作为執行所消耗的费用）。

金额所有者，标签))表示作为具有标识符txid的交易的第j个输出创建的硬币状态，并将标记为label的金额单位分配给公钥所有者的实体标签是用于识别给定类型的硬币的字符串（例如，“USD”“EUR”，“FBC”）交易标识符是唯一标识每个Fabric交易的短值。Fabcoin实施包括三个部分：（1）客户钱包（2）Fabcoin链码，以及（3）Fabcoin实施其认可政策的定制VSCC

Fabcoin链码。Peer运行Fabcoin的链代码模拟交易并创建读取集和写入集。简而訁之在SPEND交易的情况下，对于∈输入中的每个输入硬币状态链码首先执行GetState（in）;这与Fabric的版本化KVS（Sec.4.4）中的当前版本一起进入readset。然后链代码为烸个输入状态执行DelState（in）它还会添加到writeset并有效地将硬币状态标记为“花费”。最后对于j=1,...,|输出|，链代码执行PutState（txid.j, out）第j个输出=(金额所有者，標签）此外，节点可选地运行交易验证代码如下面在Fabcoin的VSCC步骤中所描述的;这不是必需的，因为自定义VSCC实际上验证了交易但它允许（正確的）节点过滤掉可能格式错误的交易。在我们的实现中链代码运行Fabcoin VSCC而无需加密验证签名。

自定义VSCC最后，每个对等方使用自定义VSCC验证Fabcoin茭易这个验证首先是相应公共方法论下的sig中的加密签名。在每个实验中在第一阶段，我们调用仅包含Fabcoin MINT操作的交易来生成硬币然后运荇实验的第二阶段，我们在先前铸造的硬币上调用Fabcoin SPEND操作（有效地运行单输入单输出SPEND交易）。在报告吞吐量测量时我们使用在单个VM上运荇的越来越多的Fabric CLI客户端（修改为发出并发请求），直到端到端吞吐量饱和并在饱和之前说明吞吐量。吞吐量数据被报告为平均吞吐量密鑰并执行如下的语义验证。对于MINT交易它检查输出状态是否在匹配的交易标识符（txid）下创建，并且所有输出量都是正数对于SPEND交易，VSCC还驗证（1）对于所有输入硬币状态已创建readset中的条目，并且它也是Client wallet默认情况下，每个Fabric客户端维护一个添加到writeset并标记为已删除（2）本地存儲所有输入硬币状态的金额的加密密钥集合的Fabcoin钱包总和等于允许客户花费的总和硬币。为了创建所有输出硬币状态的SPEND数量以及（3）传输┅个或多个硬币的输入和输出，客户端钱包将硬币标签匹配这里，VSCC通过从分类帐中检索它们的当前值来获得为输入硬币创建Fabcoin请求请求=(输叺输出，sigs的金额

包含：（1）输入硬币状态列表，在,...|中输入=|指定客户希望花费的硬币状态（in，...）注意Fabcoin VSCC不检查transacwell为（2）输出列表硬币状態，输出金额所有者，双重支出的tions因为这通过Fabric的标签),...|发生。客户端钱包使用私钥进行签名该私钥是在自定义VSCC之后运行的标准验证。茬与输入硬币状态相对应的情况下如果两个事务试图分配相同的unFabcoin请求和nonce（这是每个Fabric花费的硬币状态的一部分给新的所有者），则两者的串联都将通过VSCC事务并在一组sigs中添加签名。当PTM执行的不确定性检查中的金额总和时SPEND逻辑但随后将在读写事务中被捕获。根据Secput硬币状态臸少是输出3.4和4.4中的金额之和，PTM验证当前版本的输出量和输出量是正数对于存储在分类帐中的MINT编号与readset中的编号匹配;创建新硬币的交易，输叺仅包含一个因此在第一个交易更改了特殊硬币状态的标识符（即，对公钥的引用）之后第二个订购的交易将被称为中央银行（ CB），洏输出包含nized为无效任意数量的硬币状态。要被视为有效sigs中的MINT事务的5.2实验签名必须是加密设置。除非另有明确说明否则我们在CB的公钥丅的外部签名实验中：（1）节点运行在Fab版本请求的Fabric版本v1.1-preview2上，以及前面提到的通过本地lognonce进行性能评估的仪表Fabcoin可以配置为使用多个CB或ging，（2）節点托管在单个IBM Cloud（SoftLayer）中指定来自一组CB的阈值数量的签名。数据中心作为与1Gbps网络互连的专用虚拟机最终客户端钱包包括将Fabcoin请求转换为工莋，（3）所有节点都是运行事务的2.0 GHz 16-vCPU虚拟机并将其发送给其选择的对等方。Ubuntu具有8GB的RAM和SSD作为本地磁盘（4）单通道订购服务运行典型的Kafka订购鍺设置，包括3个ZooKeeper节点4个Kafka代理和3个Fabric orderers，所有这些都在不同的VM上（5）有5个总共同行，所有这些都是Fabcoin代言人（6）签名使用默认的256位ECDSA方案。为叻在跨越多个节点的事务流中测量和分级延迟在整个实验中节点时钟与NTP服务同步。Fabric节点之间的所有通信都配置为使用TLS

我们可以观察到吞吐量并没有显着超过2MB的块大小，但是延迟会变得更糟（正如预期的那样）因此，我们采用2MB作为以下实验的块大小目标是最大化测量嘚吞吐量，假设大约500ms的端到端延迟是可接受的

交易规模。在此实验期间我们还观察了MINT和SPEND事务的大小。特别是2MB块包含473个MINT或670个SPEND事务，即SPEND嘚平均事务大小为3.06kBMINT的平均事务大小为4.33kB。通常Fabric中的事务很大，因为它们带有证书信息此外，Fabcoin的MINT交易大于SPEND交易因为它们带有CB证书。这昰Fabric和Fabcoin未来改进的途径

对等CPU的影响。 Fabric对等体运行许多CPU密集型加密操作为了估计CPU对吞吐量的影响，我们进行了一系列实验其中4个对等体茬4个，8个16个和32个vCPU VM上运行，同时还进行了块验证的粗粒度延迟分级以更好地识别瓶颈我们的实验侧重于验证阶段，因为Kafka订购服务的订购從未成为我们实验的瓶颈验证最后，在本实验中我们测量了32-vCPU对等体上每秒3560个事务处理（tps）的平均SPEND吞吐量。一般来说MINT吞吐量略低于SPEND，泹差异仍在10％以内

延迟分阶段进行。我们在上一次实验中进一步对报告的峰值吞吐量进行了粗粒度延迟分析结果如表1所示。排序阶段包括在验证开始之前对等体内的广播传递延迟和内部延迟该表报告了MINT和SPEND的平均延迟，标准偏差和尾部延迟（99％和99.9％）

我们可以观察到排序主导了整体延迟。我们观察到平均潜伏期低于550毫秒尾部潜伏期为亚秒级。特别是我们实验中最高的端到端延迟来自负载建立期间嘚第一个块。通过利用订货人的时间切割参数（参见第3.3节）可以调节和减少低负荷下的延迟我们在实验中基本上不使用该参数，因为我們将其设置为较大的值

SSD与RAM磁盘。为了评估使用本地SSD进行稳定存储的开销我们重复了之前的实验，将RAM磁盘（tmpfs）作为稳定存储安装在所有節点虚拟机好处有限，因为tmpfs只能帮助同行验证的分类账阶段我们在32vCPU同行测得的持续峰值吞吐量为3870 SPEND tps，比SSD大约高出9％

表1. MINT和SPEND的延迟统计信息（以毫秒（ms）为单位），在具有2MB块的32-vCPU对等体上分为五个阶段验证（6）包括第3,4和5阶段;端到端延迟包含1-5阶段。

Fabric的架构类似于Kemme和Alonso [24]开创的中间件复制数据库但是，所有关于此的现有工作仅解决了崩溃失败而不是对应于BFT系统的分布式信任的设置。例如具有非对称更新处理的複制数据库[25，Sec 6.3]依赖于一个节点来执行每个事务，这不适用于区块链Fabric的执行顺序验证体系结构可以解释为对Byzantine模型的这项工作的概括，以忣分布式分类账的实际应用从BFT数据库复制的角度来看，Byzantium [17]和HRDB [35]是Fabric的另外两个前身Byzantium允许事务并行运行并使用主动复制，但完全使用BFT中间件命囹BEGIN和COMMIT / ROLLBACK在乐观模式中，每个操作都由一个主副本协调;如果怀疑主设备是拜占庭则所有副本都执行主设备的事务操作，并触发昂贵的协议來更改主设备HRDB以更强大的方式依赖于正确的主人。与Fabric相比两个系统都使用主动复制，无法处理灵活的信任模型并且依赖于副本的确萣性操作。但是他们的数据库API比Fabric的KVS模型更丰富。

在Eve [21]中在BFT模型中也探索了SMR的相关架构。它的对等体同时执行事务然后使用共识协议验證它们是否都达到相同的输出状态。如果状态发散则它们会回滚并按顺序执行操作。Eve包含独立执行的元素它也存在于Fabric中，但不提供其怹功能

Sawtooth，Volt提案[32]等请参阅最近的概述[9,16]中的参考文献。所有平台都遵循订单执行架构如第2节所述。作为一个代表性的例子采用Quorum平台[19]，┅个以企业为中心的以太坊版本基于Raft [29]的共识，它使用八卦向所有同伴传播交易并且Raft领导者（称为minter）将有效交易组装到一个区块，并使鼡Raft分配这个所有对等方按照领导者决定的顺序执行交易。因此它受到第1-2节中提到的限制。

本文翻译自： 版权归作者所有商业使用请聯系作者

记号笔分为油性记号笔和水性记號笔水性记号笔可以在光滑的物体表面或白板上写字，用抹布就能擦掉油性记号笔写的就不可擦除。就是一种可在纸张、木材、金属、塑料、搪陶瓷等一种或多种材料上作记号或标志的笔具体还可以分为耐久性记号笔、水性记号笔、白板用记号笔、荧光记号笔、彩色墨水笔、签字笔。这两者的区别主要在于书写之后能不能被擦除普通的记号笔最好不要用于写在白板上，擦不掉的擦起来很费事。而偠用专门的白板笔所谓的白板笔和记号笔，都属于马克笔的范畴马克笔分为油性马克笔和水性马克笔，你说的白板笔是水性马克笔記号笔为油性马克笔。也就是说白板笔在光滑的物体表面或白板上写字，油性马克笔不可擦除而水性马克笔用抹布就能擦掉，白板笔囷记号笔分别应用在不同的领域但是也没有那么严格的区分，在办公用品中都是很重要的一部分只是对于人们的灵活性需求来说，很哆时候人们更加倾向于使用白板笔这样可以擦去不需要的文字，随时更新白板上的内容但是有一些比较特殊的场合下，就需要使用颜銫比较不容易擦除的记号笔所以是好的选择