Fabric、FISCO BCOS、以太坊对比

一、以太坊

以太坊是一个开放的软件平台，使开发人员能够构建和部署去中心化的应用程序。这是一个公共区块链网络。它旨在使用户以对等的方式与社交系统，金融系统进行交互。

以太坊拥有自己的加密货币–Ether。矿工努力赚取以太。它有智能合约，定义协议的规则和处罚，并执行这些义务。目前，以太坊使用工作证明协议，计划是将其网络更新为股权证明。

1.1 什么是工作量证明（POW）

这是一种共识算法。该算法允许区块链的节点就区块链的当前状态达成共识。在以太坊上大约每15秒就达到对全球状态的共识。

1.2 这是如何运作的？

当新块到达节点时，它获取该块的hash，然后尝试验证。它使用POW一致性算法，该算法需要大量的计算能力来生成一些随机位。当生成的随机位附加到块的hash时，它给出特定值（新hash）。 Node已经知道它正在寻找的哈希值。如果生成的值与预期答案匹配，则该块有效。

节点通过附加从交易块获得的hash来继续尝试随机位。一旦任何矿工找到答案，那么该区块将被添加到区块链中。

1.3 工作量证明的问题

它需要大量的计算能力（CPU周期，GPU，电力）才能获得随机位，
矿工奖励随着时间的推移而减少，当发生这种情况时，更少矿工们挖掘这些区块。这可以为恶意用户打开窗口，恶意用户可以轻松获取超过51％的网络，从而破坏网络。
以太坊试图从工作量证明转换为股权证明算法。

1.4 股权证明

它需要显示货币的所有权。你不再需要进行大量的计算，这可以节省大量的能量，第二个好处是你可以锁定以太，从而造成稀缺。因此价格会上涨，这意味着只有拥有以太（以太坊货币）的矿工才能验证区块。如果恶意验证器验证错误节点，则它们会丢失以太。

二、Fabric

2.1 产生背景

Hyperledger Fabric 是分布式账本解决方案的平台，该平台以模块化架构为基础，提供高度的机密性，灵活性和可扩展性。它旨在支持不同组件的可插拔实现，并适应整个经济生态系统中存在的复杂性。Fabric 最早由 IBM 设计和开发，2015 年将其源代码奉献给了 Linux 基金会的Hyperledger 项目。Fabric最初即被定义为跨行业应用，更注重的是构建基于区块链技术的通用框架。

Hyperledger是2015年成立的Linux基金会下的一个项目。它旨在促进跨多个公司的区块链项目的协作。Hyperledger中有多个项目，并且有多个平台打造超级服务。

这些项目如下：

• 来自IBM的Fabric
• 来自英特尔的Sawtooth Lake
• R3形成Corda
• Iroha
• Indy
• Burrow

HyperLedger Fabric更多地关注大型组织，而以太坊则更受小型应用和公共智能合约的欢迎。HyperLedger Fabric旨在创建专门用于企业用途的权限区块链。企业的一个重要特征是数据保密和隐私。Fabric通过基于HTTP/2构建的对等协议来管理分布式分类帐。它使用智能合约来提供对分类账的受控访问，这些智能合约可以用go或java语言编写。超级分类账没有加密货币。

超级分类帐结构中的一些关键概念是：Ledger，Block，Chaincode，Consensus，Member，Membership services，Multi-channel，peer，transaction，policy，private channels。

• Modular Consensus：模块化共识指不同的行业在网络中拥有自己的网络甚至子网络。Hyperledger通过提供可插拔的共识为这些要求提供解决方案。目前，它提供PBFT（实际拜占庭容错），开发者社区正在积极致力于不同的共识机制。

• Chaincode：这是超级分类账中的智能合约。

• Membership Services：成员资格服务在许可的Hyperledger结构网络上对身份进行身份验证，授权和管理。在对等体中运行的成员资格服务代码对区块链操作进行身份验证和授权。

• peer：维护分类帐并运行链代码容器以便对分类帐执行读/写操作的网络实体。对等方由会员拥有和维护。

• Transaction：调用或实例化操作。调用是从分类帐读取/写入数据的请求。Instantiate是在对等体上启动链代码容器的请求。

• Policy：有认可，验证，块提交，链码管理和网络/渠道管理的策略。策略通过系统链代码定义，并包含网络操作成功的必要规范。例如，认可策略可能要求100％的代理在交易模拟时获得相同的结果。

• Private Channels ：Hyperledger Fabric频道是两个或多个特定网络成员之间通信的私有“子网”，用于进行私人和机密交易。频道由成员（组织）定义。必须对每一方进行身份验证并授权其在该频道上进行交易。加入频道的每个对等体具有由成员服务提供者（MSP）给出的自己的身份，其向每个对等体验证其频道对等体和服务。

• Performance and scalability：性能和可扩展性，分类帐必须能够持续运行直到其生命周期。它应该允许发现，搜索，身份解析和执行其他关键功能。即使节点数量也会随着时间的推移而增加。因此，性能是关键因素，Fabric能够有效扩展而不会降低性能。

下图显示了Hyperledger逻辑体系结构在其类别中：

2.2 共识机制

Hyperledger Fabric 保证了区块链中的分布式和不可篡改性的特点，省略了去中心化的共识机制（不支持拜占庭容错）。 Fabric 架构中将参与节点分成了三种角色，即排序节点、背书节点和提交节点。对于每一笔交易，共识状态的过程是由客户端、背书节点、提交节点共同参与完成的。

客户端首先将交易请求发送给背书节点，背书节点执行后将 read/write set 及其签名返回给客户端，客户端收集到足够相同的结果后，将 read/writeset、多组签名和交易请求组成签名后的交易，发送给排序节点，排序节点组成区块之后，广播给提交节点，提交节点验证 read/write set 和签名数是否满足，标记结果并保存合法的结果到各自的账本。

排序节点只负责交易顺序的共识，而不负责状态共识，在交易状态共识和排序可以分别采用不同的策略。

排序节点中的共识方式是 Kafka 或者 Raft，由于Kafka部署运维较为棘手，Fabric2.0后不再支持Kafka。目前正在开发Hotstuff去中心化的共识算法的插件，未来将支持拜占庭容错。

2.3 数据隔离

Hyperledger Fabric区块链网路的子链是按照“1个通道+ 1个账本+ N个成员 ”的基本组成。通道是两个或多个特定网络成员之间的通信的私有“子网”，用于进行需要数据保密的交易。Fabric中建立一个通道相当于建立了一个子链，支持多链消息传递。但是Fabric的“多链”并不完善，因为它不支持跨链路由、跨链事务，只能跨链读取，更像是在一个单链上做的逻辑分割。实际开发中，通道通常被用于区分不同的业务，或者在复杂、冗长的业务流中区分不同的阶段，跨链机制的建立，只能通过同一个节点加入不同的通道来实现。V1.2版本后提出了私有数据的概念，它允许在通道上定义的组织子集能够背书、提交或查询私有数据，而无需创建单独的通道。为授权节点单独创建隐私数据库，隐私数据不会被暴露到排序节点上。

2.4 智能合约

Fabric的合约通过ChainCode的方式以Docker的方式进行线下部署，通过交易进行激活。ChainCode合约的部署相对较重，Fabric2.0版本后docker镜像将会使用Alpine Linux，相比之前版本更加轻量。支持多种语言，开发者不需要学习新的语言，V2.0后链码可以运行到非Docker自定义环境。

2.5 权限管控

Hyperledger Fabric 中策略是基础设施的管理机制。Fabric策略表示成员如何同意或者拒绝网络、通道或者智能合约的变更。包括系统通道配置、用户通道配置、权限控制列表，智能合约背书策略，用户可以在启动前由排序服务创建者建立初始规则和联盟成员，确定网络的治理方式，也可以在任何时间及时修改治理策略。

2.6 存储

Hyperledger Fabric的区块存储采用文件方式保存。可以方便对区块进行查找的追溯。Fabric的世界状态储存支持LevelDB和CouchDB存储，世界状态存储时不支持历史状态的保存，CouchDB存储支持丰富的条件查询和统计。

2.7 性能

Hyperledger Fabric在节点数量扩展方面是弱项，已落地项目多是个位数节点，但是可以支持较多的客户端。第三方测评在32核CPU，10节点的情况下，TPS在3400左右。由于环境节点数不同，测试结果仅供参考。

2.8 跨链方案

Hyperledger Fabric的跨链方案，目前国内蚂蚁区块链、腾讯云区块链等厂商都在研究支持，这些厂商都开发了基于云链结合的BaaS系统。跨链更多指的是Fabric框架之间的同构跨链，例如阿里云BaaS上对互操作性做了全面支持。用户可以将阿里云BaaS上的Fabric组织和外部的Fabric组织连接成一个业务通道，共同治理业务网络，完成智能合约的执行和共识。

2.9 部署支撑

Hyperledger Fabric作为底层框架，并没有提供过多了中间组件来支撑应用层的开发，例如官方提供了Hyperledger Explorer区块链浏览器用来查询统计区块信息，BaaS平台可以提供基于区块链的搜索查询、交易提交、数据分析等一系列操作服务，用来帮助开发者更快地验证自己的概念和模型，便于创建、部署、运行和监控区块链。

2.10 国密支持

Hyperledger Fabric官方目前还不支持国密算法，同济和第三方有支持国密的Patch和方案。主流存在修改Go语言库和修改Fabric底层框架两种国密支持方案。包括Fabric框架、SDK、Fabric-CA等需要全套国密支持，另外为了国内Fabric项目和社区的发展，根据最新Hyperledger Fabric中国工作组的计划，未来会开发支持可插拔国密算法的Fabric版本。

2.11 开源协议

Hyperledger Fabric采用Apache-2.0开源协议，Apache Licence是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

三、FISCO BCOS

3.1 产生背景

FISCO BCOS 诞生于 2017 年，由金链盟推出，是标准的国产底层。金链盟是由深圳市金融科技协会、深圳前海微众银行、深证通等二十余家金融机构和科技企业于 2016 年 5 月 31 日共同发起成立的非营利性组织。

FISCO BCOS 最初的定位是设计为自主可控的、适用于金融行业的开源区块链底层平台，在设计监管接口时，FSICO BCOS更适合中国企业。随着平台的发展，也逐渐支持了更多金融领域以外的场景。FISCO BCOS 继承自以太坊公链。 虽然在场景和使用上已经和公链完全不同，但从技术上来讲，继承了以太坊的虚拟机，也就是继承了以太坊庞大的生态。

3.2 共识机制

FISCO BCOS作为一个分布式账本，可以保证数据的不可篡改同时也可以使用了去中心化的共识机制拜占庭容错，保证了 1/3 的容错率。将链的参与方分成了共识节点、只读节点和游离节点，共识节点即是拥有记账权利的参与方，只读节点是拥有查阅所有数据的参与方。游离节点是完成网络准入但没有加入群组的节点，不参与共识和同步。
BCOS共识机制效率相对较为传统

FISCO BCOS 的共识机制采用了传统的 PBFT 共识，其共识流程主要包括 Pre-prepare, Prepare 和 Commit 三个阶段：

1. Pre-prepare：Leader 节点执行区块，产生签名，并将 Proposal 广播给其他共识节点；

2. Prepare：共识节点验证 Proposal 并广播签名，同时收集其他节点签名，节点收集到 2f + 1 的签名后，开始广播 Commit 包；

3. Commit：Leader 节点收集 Commit 包，节点收集满 2*f + 1 的 Commit 包后，更新本地数据库并广播给其他节点，其他节点收到之后更新本地数据库。

在区块链中因为共识节点之间需要统一 Commit 阶段的投票，所以最后的 Commit 阶段略为不同：Leader 节点收到 2*f+1 的 Commit 包之后会将最终的 Commit 包广播给其他共识节点来统一投票。

在整个共识流程中，交易在 Pre-prepare 阶段执行一次，在 Prepare 阶段验证一次，FISCO BCOS 中使用的传统 PBFT 流程为先执行再验证的模式，包含了两个执行交易的时间长度。

3.3 数据隔离

FISCO BCOS引入多群组架构，支持区块链节点启动多个群组，群组间交易处理、数据存储、区块共识相互隔离，保障区块链系统隐私性的同时，降低了系统的运维复杂度。群组间数据隔离，每个群组独立运行不同的共识算法。多群组架构中群组间共享网络，通过网络准入和账本白名单实现各账本间网络消息隔离。每个群组均运行一个独立的账本。

3.4 智能合约

FISCO BCOS支持EVM和预编译合约。借助于Ethereum 智能合约的完善的生态系统，在其基础之上做了定制化，有丰富的合约编写和测试工具。当前支持EVM的语言主要是Solidity，具有图灵完备特性。为了解决Solidity执行效率低，BCOS提供了一个EthCall连接Solidity和C++的编程接口，复杂的业务可以使用C++编写以提高效率。Solidity和EVM目前的功能还无法充分满足各种复杂业务场景的需求，这也是其缺点之一。

3.5 权限管控

FISCO BCOS V2.5版本后新增基于角色的权限控制，分为治理方、运维方、监管方和业务方，对各个角色进行权责分离，角色互斥。防止角色既当“裁判员”又当“运动员”的情况。治理方负责区块链治理；运维方负责区块链运维，该角色由委员添加；业务方可以调用该合约的写接口；监管方能够获取链运行中权限变更记录以及需要审计的数据。权限控制的最小粒度为表，基于外部账户进行控制。

3.6 存储

FISCO BCOS的区块存储采用MPT（默克尔前缀树）的方式保存。对于世界状态采用了两种存储模式：storage state和MPT state。MPT state支持RocksDB和External存储，MPT存储在保存历史状态的同时，最大化减少存储数据。Storage State 支持RocksDB、MySQL、External，使用storage state存储时，牺牲了部分的可追溯性，但带来了性能上的提升，同时能支持SQL语句的查询和统计。因为世界状态始终是可以通过交易进行还原，所以可以牺牲部分可追溯性而换取性能的提升和状态查询。

3.7 性能

FISCO BCOS采用pbft共识时间复杂度是O(n*n)，当超过20个节点以后效率不高。V2.3.0版本提出了rPBFT共识算法，可以在安全性和效率之间动态调整参数，减少节点规模对共识算法的影响，理论上节点数量是不受限制的。中国信通院可信区块链测评，BCOS单链TPS超2万。

3.8 跨链方案

FISCO BCOS的跨链方案是采用WeCross跨链路由，WeCross由微众银行自主研发并完全开源的分布式商业区块链跨链协作平台。采用哈希时间锁和两阶段事务提交方案，基于默克尔证明机制实现数据互信，通过开发不同联盟链的STUB插件，将不同联盟链数据抽象成统一的资源，实现非侵入式跨链。目前支持FISCO BCOS和Hyperledger Fabric之间的异构跨链。

3.9 部署支撑

微众银行也在其基础上开源了中间件平台WeBASE，以此作为连接底层和应用层的桥梁。而在WeBASE的再上一层，微众银行为其加入了实体身份标识与可信数据交换WeIdentity、消息协作WeEvent等应用解决方案，并完全对外开源。这些协议让开发者直接在地基上盖房子，做DAPP，原理与BaaS很相似，降低开发门槛。此外BaaS平台也在逐步支持BCOS框架，例如腾讯云区块链服务平台（TBaaS）v3.1.0 服务平台集成多引擎包含了FISCO BCOS引擎

3.10 国密支持

FISCO BCOS作为国产联盟链底层平台，支持国密。国密版FISCO BCOS将交易签名验签、p2p网络连接、节点连接、数据落盘加密等底层模块的密码学算法均替换为国密算法。SDK同样支持国密算法。支持国密SM1、SM2、SM3、SM4等全部标准，构建了全套监管解决方案。

3.11 开源协议

FISCO BCOS采用GPL3.0开源协议，GPL协议的主要内容是只要在一个软件中使用(类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。商用不够友好

四、以太坊、Fabric、FISCO BCOS差异对比

	以太坊	Fabric	FISCO BCOS
设计	以太坊公链技术	继承IBM分布式体系设计	继承以太坊公链技术
平台描述	通用用途区块链(不只是用于支付)	通用用途区块链(不只是用于支付)	通用框架、更适合应用于金融领域
管理	ethereum开发者	linux基金会	金链盟
货币	Ether	无	无
挖矿奖励	5.0Ether	N/A	N/A
共识	POW	PBFT	PBFT\Raft
准入标准	全网自由接入	有准入控制	有准入控制
交易	匿名或私人	公开或保密	公开或保密
隐私性	公开	公开给私人	公开给私人
智能合约环境	EVM环境	Docker环境	EVM环境
智能合约语言	Solidity,Golang,C++,Python	Java,Golang	Solidity，C++

五、Fabric、FISCO BCOS技术对比

	Hyperledger Fabric	FISCO BCOS
设计	继承IBM分布式体系设计	继承以太坊公链技术
框架	适用于不同领域的通用框架	通用框架、更适用于金融领域
隔离方式	通道隔离	群组隔离
隔离设计	支持多通道，单通道私有数据隔离	支持多群组，群组内数据隔离
智能合约环境	Docker环境	EVM环境
智能合约语言	Go、Java、Nodejs	Solidity智能合约语言
智能合约通用性	由于合约才有通用语音，合约执行存在不确定性，执行环境有存在差异的可能，所以不能保证合约计算的一致性和确定性	语言环境统一，通用性满足
智能合约可验证、可审计	部署合约分布由背书节点独自部署和运行，不在链上进行部署和共识，联系共识，存在节点误部署和修改代码的风险，无法通过区块链保证合约的不篡改，对验证和审计不够友好	链上部署、调用合约，合约代码保存在链上，可以对合约进行验证、审计
智能合约可追溯	通过交易追踪合约的激活和调用，但是合约代码变更不可追踪	通过交易追踪合约的部署、调用、更新
智能合约语言友好度	支持传统语言，易上手	多数场景实用solidity语言，已成熟，易上手
智能合约工具链	传统语言，工具链完善	基于solidity的工具链进行深度定制，工具链完善
智能合约部署	由背书节点通过Rocker分别部署，部署成本高	通过交易，方便部署，链上部署
智能合约调用	合约调用必须在同一个chaincode	合约之间可以方便调用
智能合约升级	背书节点分别去升级	通过部署新合约的方式进行升级
复杂合约	背书节点分别执行合约，并不对合约时间和复杂度进行限制	通过设置区块交易上限使区块链可以处理复杂度非常搞定合约
并行计算	不支持并行计算，交易依次执行。同一个区块不允许有冲突交易，否则后续交易失败	支持并行计算，但是需要在交易中预先设计冲突状态，场景有限且使用难度比较高
指令扩展	传统语言，指令丰富，不需要扩展	通过预编译合约进行指令扩展
中心化共识	暂时不支持去中心化共识	支持去中心化共识
节点支持	支持少数节点	理论上节点不受限制
节点类型	背书节点、排序节点、提交节点三者共同参与共识	共识节点、只读节点、游离节点
节点扩展性	背书节点增删方便，排序节点增删方便，背书策略易修改，排序策略易修改	方便节点的删减
节点模块化	执行、排序、验证分离，节点功能可以根据情况组合	共识/执行耦合，不易替换和定制化
性能测试指标TPS	3400	20000
支持跨链方案	支持同构跨链方案	支持同构、异构跨链
权限管控	基于策略的权限控制	基于角色的权限控制，控制账号对表的操作
支持的执行共识	通过不同的角色实现共识，排序采用raft共识	pbft/raft/rpbft
执行共识	不同的背书策略安全性不同，既可以是安全性较高的背书节点和全部通过，也可以是单一背书节点通过的策略	BFT类共识只要保证2/3+1个节点诚实，既可正常出块，保证1/3个共识节点诚实既可保证结果正确
共识节点	通过配置文件进行管理排序节点管理，节点管理员通过发送交易激活新的配置文件，通过CA来认证	通过系统合约进行管理，节点管理员通过发送交易进行共识节点的增删
普通节点	通过配置文件来管理背书节点和提交节点，Channel管理员通过发送交易来激活新的配置文件，通过CA来认证。	通过白名单和黑名单管理链接，通过CA来判断节点是否为普通节点
交易排序上链	排序可以采用Raft或者solo共识，leader节点具有有较大权限可以拒绝交易	BFT类算法只要保证2/3+1个节点诚实既可保证交易会上链
交易状态一致性	排序和验证都不进行最终状态的共识，有提交节点来验证交易，并分布更新各自状态。只有等待下一个相关交易读取状态或者客户端主动查询，由客户端判断是否一致	BFT类共识只要保证2/3+1个节点诚实，既可正常出块，保证1/3个共识节点诚实既可保证结果正确
区块存储方式	文件方式保存区块	MPT保存区块
存储数据库	Leveldb、CouchDB保存状态	MySQL、RocksDB保存状态
KV状态存储	支持KV数据，不保留历史不可追溯。支持CouchDB，不保留历史不可追溯，支持条件查询	支持两种模式：KV数据库，保留历史可追溯；SQL数据库，不保留历史数据不可追溯，支持条件查询。
国密支持	中国工作组计划支持，存在第三方技术支持	支持
开源协议	Apache-2.0	GPL3.0

参考文章

1. 以太坊和Hyperledger Fabric之间的差异
2. Hyperledger Fabric和FISCO BCOS技术对比
3. 开源架构Fabric、FISCO BCOS（以下简称“BCOS”）、CITA 技术对比
4. FISCO BCOS和以太坊差异综述
5. 技术上我们如何对比 Fabric，FISCO BCOS，Quorum 以及 Corda
6. Hyperledger Fabric 和 FISCO BCOS区别