Fabric、FISCO BCOS、以太坊的比较

Fabric、FISCO BCOS、以太坊的比较

1. 以太坊

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

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

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

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

1.2 这是如何工作的？

当一个新块到达一个节点时，它会获取该块的哈希值，然后尝试对其进行验证。 它使用工作量证明共识算法，需要大量计算能力来生成一些随机位。 当生成的随机位附加到块的哈希值时，它会给出一个特定的值（新哈希值）。 节点已经知道它正在寻找的散列。 如果生成的值与预期答案匹配，则该块有效。

节点通过附加从事务块中获得的哈希来不断尝试随机位。 一旦任何矿工找到答案，该区块就会被添加到区块链中。

1.3 工作证明的问题

获取随机位需要大量的计算能力（CPU 周期、GPU、电力），

矿工奖励会随着时间的推移而减少，当这种情况发生时，开采这些区块的矿工就会减少。 这可以为恶意用户打开窗口，恶意用户可以轻松获得超过 51% 的网络，从而危及网络。

以太坊正试图从工作量证明切换到权益证明算法。

1.4 权益证明

它需要显示货币的所有权。 你不再需要做大量的计算，这样可以节省很多能量，第二个好处是你可以锁定以太币，这就产生了稀缺性。 所以价格会上涨，这意味着只有拥有以太币（以太坊货币）的矿工才能验证区块。 如果恶意验证者验证了错误的节点，他们就会丢失以太币。

2.面料背景 2.1

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

Hyperledger 是 2015 年成立的 Linux 基金会下的一个项目，旨在促进区块链项目跨多个公司的协作。 Hyperledger 有多个项目，有多个平台可以构建超服务。

这些项目如下：

HyperLedger Fabric 更侧重于大型组织，而以太坊更受小型应用程序和公共智能合约的欢迎。 HyperLedger Fabric 旨在创建专门供企业使用的许可区块链。 企业的一个重要特征是数据的机密性和隐私性。 Fabric 通过建立在 HTTP/2 之上的点对点协议管理分布式账本。 它使用智能合约来提供对账本的受控访问，这些智能合约可以用 go 或 java 语言编写。 Hyperledger 没有加密。

Hyperledger Fabric 中的一些关键概念是：Ledger、Block、Chaincode、Consensus、Member、Membership services、Multi-channel、peer、transaction、policy、private channels。

下图显示了 Hyperledger 逻辑架构的类别：

2.2 共识机制

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

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

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

排序节点中的共识方式是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之后，chaincode可以在非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目前官方不支持国密算法，同济和第三方都有支持国密的补丁和解决方案。 主流的国密支持方案有两种：修改Go语言库和修改Fabric底层框架。 包括Fabric框架、SDK、Fabric-CA等，需要全套国密支持。 此外，针对国内Fabric项目和社区的发展，根据Hyperledger Fabric中国工作组的最新规划，未来将开发支持可插拔国密算法的Fabric版本。

2.11 开源协议

Hyperledger Fabric采用Apache-2.0开源协议，Apache License是对商业应用友好的许可证。 用户还可以在需要时修改代码以满足他们的需求，并将其作为开源或商业产品发布/销售。

3. FISCO BCOS 背景 3.1

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

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

3.2 共识机制

FISCO BCOS作为分布式账本，可以保证数据不可篡改，还可以利用去中心化的共识机制拜占庭容错，保证1/3的容错率。 该链的参与者分为共识节点、只读节点和自由节点。 共识节点是具有记账权的参与者，只读节点是可以访问所有数据的参与者。 自由节点是已经完成网络接入但尚未加入群组，不参与共识和同步的节点。

BCOS共识机制效率相对传统

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

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

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

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 和预编译合约。 借助以太坊智能合约完整的生态系统，在其基础上进行定制，并有丰富的合约编写和测试工具。 目前支持EVM的语言主要是Solidity，它具有图灵完备的特性。 为了解决Solidity执行效率低下的问题，BCOS提供了将Solidity和C++与EthCall对接的编程接口。 复杂的业务可以用C++编写，提高效率。 Solidity和EVM目前的功能还不能完全满足各种复杂业务场景的需求，这也是它的不足之一。

3.5 权限控制

FISCO BCOS V2.5之后以太坊是单账本吗，增加了基于角色的权限控制，分为治理方、运维方、监管方、业务方。 每个角色的权利和责任是分离的，角色是相互排斥的。 防止角色既是“裁判”又是“选手”的情况。 治理方负责区块链治理； 运维方负责区块链运维，该角色由委员会增加； 业务方可以调用合约的编写接口； 监管者可以获得链上运行过程中的权限变更记录和需要审计的数据。 权限控制的最小粒度是表，基于外部账户进行控制。

3.6 存储

FISCO BCOS的区块存储以MPT（默克尔前缀树）的形式存储。 世界状态使用两种存储模式：存储状态和MPT状态。 MPT 状态支持 RocksDB 和外部存储。 MPT存储在保存历史状态的同时最小化存储数据。 Storage State 支持 RocksDB、MySQL 和 External。 使用存储状态存储时，牺牲了部分可追溯性，但带来了性能提升，可以支持SQL语句查询和统计。 因为世界的状态总是可以通过交易来恢复，所以可以牺牲一些可追溯性来换取性能的提升和状态的查询。

3.7 性能

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

3.8 跨链方案

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

3.9 部署支持

微众银行还开源了基于它的中间件平台WeBASE，作为连接底层和应用层的桥梁。 在WeBASE的下一层，WeBank新增了实体身份识别与可信数据交换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协议的开源代码，商业软件或对代码有保密要求的部门不适合作为集成/采用的依据类库和二次开发，业务不够友好

4. 以太坊、Fabric 和 FISCO BCOS 与以太坊 FabricFISCO BCOS 的区别

设计

以太坊公链技术

继承IBM分布式系统设计

继承以太坊公链技术

平台说明

通用区块链（不仅用于支付）

通用区块链（不仅用于支付）

通用框架，更适合金融领域应用

管理

以太坊开发者

Linux基金会

金链联盟

货币

醚

没有任何

没有任何

挖矿奖励

5.0以太币

不适用

不适用

共识

战俘

拜占庭容错

PBFT\Raft

访问标准

全网免费接入

带访问控制

带访问控制

贸易

匿名或私人

公开或机密

公开或机密

隐私

上市

公共到私人

公共到私人

智能合约环境

EVM环境

码头环境

EVM环境

智能合约语言

Solidity、Golang、C++、Python

Java，戈朗

坚固性，C++

五、Fabric、FISCO BCOS技术对比Hyperledger FabricFISCO BCOS

设计

继承IBM分布式系统设计

继承以太坊公链技术

框架

不同领域的通用框架

通用框架，更适用于金融领域

隔离法

通道隔离

群体隔离

隔离设计

支持多通道、单通道私有数据隔离

支持多组，组内数据隔离

智能合约环境

码头环境

EVM环境

智能合约语言

围棋，Java，Node.js

Solidity 智能合约语言

智能合约的多功能性

由于合约具有普适性，合约执行存在不确定性，执行环境可能存在差异，因此无法保证合约计算的一致性和确定性

语言环境统一，通用性满足

智能合约是可验证和可审计的

部署合约分发由背书节点单独部署运行，无需链上部署和共识，联系共识，存在节点误部署和代码修改风险，区块链无法保证合约不被篡改，以及对验证和审计不够友好

在链上部署和调用合约，合约代码存储在链上，可对合约进行验证和审计

智能合约可追溯

通过事务跟踪合约的激活和调用，但无法跟踪合约代码的变化

通过交易跟踪合约的部署、调用和更新

智能合约语言友好性

支持繁体语言，简单易用

大部分场景使用Solidity语言，成熟易用

智能合约工具链

传统语言，完整的工具链

基于solidity工具链深度定制，工具链完善

智能合约部署

背书节点通过Rocker单独部署，部署成本高

通过交易，便捷部署，链上部署

智能合约调用

合约调用必须在同一个链码中

合约之间调用方便

智能合约升级

背书节点单独升级

通过部署新合约进行升级

复杂的合同

背书节点单独执行合约，不限制合约时间和复杂度

通过设置大宗交易的上限，区块链可以很好的处理合约的复杂性

并行计算

不支持并行计算，交易顺序执行。同一个区块不允许有冲突的交易，否则后续交易会失败

支持并行计算，但需要预先设计事务中的冲突状态，场景受限，使用相对困难

指令扩展

繁体语言，指令丰富，无需扩展

通过预编译合约进行指令扩展

中心化共识

暂时不支持去中心化共识

支持去中心化共识

节点支持

支持少数节点

理论上无限节点

节点类型

背书节点、排序节点、提交节点参与共识

共识节点、只读节点、自由节点

节点可扩展性

轻松增删背书节点，轻松增删排序节点，轻松修改背书策略，轻松修改排序策略

便捷的节点删除

节点模块化

执行、排序、验证分离，节点功能可根据情况组合

共识/执行耦合，不易替换和定制

性能测试指标TPS

3400

20000

支持跨链方案

支持同构跨链方案

支持同构和异构跨链

权限控制

基于策略的访问控制

基于角色的权限控制，控制账户对表的操作

支持执行共识

通过不同角色达成共识，采用raft共识进行排序

pbft/筏/rpbft

执行共识

不同的背书策略具有不同的安全性。 可以是高安全背书节点全通的策略，也可以是单背书节点的策略。

BFT共识只要2/3+1个节点诚实，就可以正常出块，1/3个共识节点诚实保证结果正确

共识节点

通过配置文件管理排序节点管理，节点管理员通过发送交易激活新的配置文件，由CA认证

通过系统合约进行管理，节点管理员通过发送交易来添加和删除共识节点

公共节点

背书节点和提交节点通过配置文件进行管理，Channel管理员通过发送交易激活新的配置文件，由CA认证。

通过白名单和黑名单管理链路，通过CA判断节点是否为正常节点

链上交易排序

排序可以使用Raft或者solo共识，leader节点有更大的权限拒绝交易

BFT算法只要保证2/3+1个节点是诚实的，就可以保证交易上链

事务状态一致性

排序和验证不对最终状态进行共识，有提交节点以分布式方式验证交易并更新各自的状态。只等待下一个关联交易读取状态或客户端主动查询， client会判断是否一致

BFT共识只要2/3+1个节点诚实，就可以正常出块，1/3个共识节点诚实保证结果正确

块存储方式

将块保存为文件

MPT 保存块

存储数据库

Leveldb、CouchDB 保存状态

MySQL、RocksDB 保存状态

KV状态存储

支持KV数据，不保留历史不可追溯支持CouchDB，不保留历史不可追溯，支持条件查询

支持两种模式：KV数据库，可追溯历史； SQL数据库，不保留历史数据，不可追溯，支持条件查询。

国密支持

中国工作组计划支持，存在第三方技术支持

支持

开源协议

阿帕奇-2.0

GPL3.0

参考文章以太坊和Hyperledger Fabric的区别Hyperledger Fabric和FISCO BCOS技术比较开源架构Fabric、FISCO BCOS（以下简称“BCOS”）、CITA技术比较技术上我们如何比较Fabric、FISCO BCOS、Quorum和CordaHyperledger Fabric以及Corda FISCO BCOS 区别