开源架构Fabric、FISCO BCOS（以下简称“BCOS”）、CITA 技术对比

本文主要是介绍开源架构Fabric、FISCO BCOS（以下简称“BCOS”）、CITA 技术对比，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

转自

https://www.coingogo.com/news/41300

联盟链技术哪家强？开源架构Fabric、FISCO BCOS（以下简称“BCOS”）、CITA 技术对比。

出品：碳链价值研究院

摘要

第 46 届世界经济论坛达沃斯年会将区块链与人工智能、自动驾驶等一并列入“第四次工业革命”。《经济学人》曾在 2015 年 10 月的封面文章《信任的机器》中介绍区块链——“比特币背后的技术有可能改变经济运行的方式”。

区块链之所以被称为信任的机器源于其分布式和不可篡改的两个核心特性，这也是区块链有别于传统数据库的核心特性。这里的分布式包含两层含义：一是传统的分布式存储，二是区块链的底层协议带来的协作性，这里更多的是指代其分布式协作的能力。

在区块链中主要通过共识算法、智能合约、治理、跨链、隐私等来实现其“可信协作”，所以本文将从这几个方面并结合企业应用场景来分析底层技术的差异，来帮助企业用户更好地做出选择。同时也会从传统企业软件的可维护性、性能、开发工具、扩展性、软件协议等方面来进行分析和对比。

就联盟链的历史、以及和公链的区别来说，早期来看差异不大，但是现在随着细分市场持续深化，公链和联盟链之间的差别越来越明显。

首先，公链面对的是一个不可控场景，需要在安全，性能和去中心化上找到一个平衡点。而在联盟链企业服务场景中，参与方数量相对来说更加的可控，联盟链在性能和安全性上更容易有突破。但也正是由于参与方（节点）的可控，去中心化这个方面有自己更加独特的设计。除此以外，在公链中，所有的信息都是公开透明可以被查验的，每一个参与方相对来说比较平等。但是在工业界中，这是不可被接受的，有大量的公对公数据隐私需要处理，在企业中也存在多种组织模式需要设定权限。

基于这些特征，联盟链在发展上包括节点管理、共识选择、权限控制和合约设计范式差异化多很大，同时不同的框架对于合约的设计范式理解也不尽相同。此外，区块链有开源和闭源之分，但是区块链创造的信任是基于开源代码产生的，没有开源就不是真正意义上的区块链系统。因此为了研究的客观，本文主要集中讨论开源框架。目前在国内市场使用较广泛的开源架构分别是 Fabric，FISCO BCOS 和 CITA。

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

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

CITA 是一个开源的区块链操作系统内核，以高稳定性，高性能，高可扩展性为设计目标。CITA 开源项目由秘猿科技 Cryptape 于 2016 年发起。目前由溪塔科技等 CITAHub 社区企业共同维护。CITA 采用微服务架构设计，提供丰富的开发工具集，灵活的区块链治理工具，开发者可为不同类型的区块链网络进行二次开发或配置。

为了区分区块链不同的实现和设计思路，可以首先来明确一下区块链本身的定义。通常区块链本身的定义是一个去中心化和分布式账本，同时也是一个记录事件和交易的不可篡改账本。在这个账本中，不可篡改的特性是由共识算法保证的。由此看来，现有的联盟链可以分为两大类：以 Fabric 为代表，在传统数据库主导的分布式数据库技术；以及更符合“区块链精神”的 FISCO BCOS 和 CITA。

Fabric 特性：IBM Fabric 保证了区块链中的分布式和不可篡改性两点，省略了去中心化的共识机制，IBM Fabric 在框架中并没有真正的去中心化共识机制。在 Fabric 架构中，将参与方（节点）分成了三种角色即：排序节点、背书节点和提交节点。对于每一笔交易：共识状态的过程是由客户端、背书节点、提交节点共同参与完成的；排序节点只负责交易顺序的共识，而不负责状态共识，在交易状态共识和排序可以分别采用不同的策略。排序节点中的共识方式是 Kafka 或者 Raft，这实际上和已有的分布式数据库共识方式是一致的，不具备容错性。

IBM Fabric 如果作为一个一体化的套件来满足带有角色的分布式数据库业务，是功能非常全面的，但也正是节点的复杂性使得应用部署较重，对于环境要求较高。除此之外，由于共识算法采用的是 Kafka 和 Raft，导致节点数量扩展上难以突破，在项目后期扩展上会比较吃力。

CITA 和 FISCO BCOS 的特性：对于 FISCO BCOS 和 CITA 来说，保证以上所述区块链的所有特点，但是在使用的时候设计范式会和传统项目差异较大。作为一个分布式账本，可以保证数据的不可篡改同时也可以使用了去中心化的共识机制拜占庭容错，保证了 1/3 的容错率。在这两种框架中，将链的参与方分成了共识节点和只读节点两种，共识节点即是拥有记账权利的参与方，而只读节点是拥有查阅所有数据的参与方。

如果说以太坊代表着区块链的精神，CITA 和 FISCO BCOS 继承自公链。CITA 和 FISCO BCOS 身上对于以太坊虽然在场景和使用上已经和公链完全不同，但是在一些底层逻辑上还是可以看到对于公有链的继承。从技术上来讲，继承了以太坊的虚拟机，也就是继承了以太坊庞大的生态。接下来，本文将从技术实现角度对比三者的不同。

共识和交易流程

共识机制作为区块链的灵魂，无论是公链还是联盟链，共识机制都从根本上限制了区块链的交易处理能力和扩展性，同时也是其分布式协作能力的基础。共识是分布式系统中节点对数据或网络最终状态达成的协议。由于网络环境和节点状态的不可控，共识机制需要同时考虑性能、可靠性、安全性等多方面问题。共识机制从大的方面，可分为 Nakamoto Consensus 等无需准入的共识机制，和 PBFT 等需要准入的共识机制两大类。

Nakamoto 共识在公链上应用广泛，但是它的概率模型在提供较高可靠性的同时，牺牲了效率。在具体商业应用环境中，许可机制已经保证了一定程度上的节点可信度，这样的前提下，用户更关心执行效率和最终确定性。这是 BFT 类共识在联盟链中流行的原因。

接下来本文将先分别介绍 FISCO BCOS、CITA 和 Fabirc 共识技术实现，本文再从性能，应用场景，扩展性和安全性等几个方面来进行对比分析。

技术实现

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 包后，更新本地数据库并广播给其他节点，其他节点收到之后更新本地数据库。

下图为标准的一次PBFT的过程：

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

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

CITA 采用自主研发的共识协议

CITA 实现了根据区块链连续共识特点而优化的 CITA-BFT。区块链是一个连续共识的过程，CITA 将交易的执行和共识进行拆分，避免了两次执行的问题。根据复制状态机的原理：起始状态一致，执行交易顺序一致，执行过程是确定的，三个条件都满足的情况下就可以保证最终结果一定会一致。在区块链中起始状态由创世块来保证一致，虚拟机是完全确定的，所以只要保证交易顺序一致就可以保证其最终结果一定一致。在区块链中 Block 的 preHash 已经包含了上个块交易处理之后的世界状态信息。CITA-BFT 对当前区块的交易顺序和上个区块的执行结果进行共识。这样在共识过程中不需要去执行交易，而只需要在共识完之后进行一次交易处理，大大提高了整个链的吞吐量。CITA-BFT 是针对区块链连续共识的特点进行了优化，采用了先共识后处理的方式，使得共识的过程不必执行交易，只需要共识完成之后执行一次交易即可。经过验证，在最简单的存证交易时，共识性能有 35% 左右提升。

CITA-BFT 避免了共识协议最后一轮 Leader 广播的过程。在传统的 PBFT 中在最后的 Commit阶段，需要 Leader 收到足够的 Commit 包并广播给其他节点。区块链是一个连续共识的过程，在 CITA-BFT 中，Block 中共识投票是上一个区块的投票，所以合并了 Commit 阶段的 Leader 广播最终区块过程和下一个高度的 Proposal 阶段，这样节省了一轮广播过程，通过下一个高度Proposal 的过程统一了 Commit 投票信息。

CITA-BFT 采用Proposal 预处理技术使共识和执行能够并行进行，提高了系统性能。由于联盟链在多数情况下，网络状况良好能在一轮共识流程中完成共识，CITA 中引入了 Proposal预处理的技术：在 Pre-prepare 阶段，节点在收到 Proposal 之后可以直接处理交易，而不必等到共识流程完成，等到共识流程完成之后再将共识结果通知交易处理器。在传统的 PBFT 的过程中，交易处理和共识是串行的，引入 Proposal 预处理之后，可以使得共识的 Prepare 阶段 Commit 阶段和交易处理并行进行，大大提高了整个系统的吞吐量。经测试，对于简单的交易处理，有 10% 到 20% 左右的性能提升。

在 CITA 中采用了 CompactBlock 的技术来压缩共识区块的大小，提高网络带宽利用率。Block中的交易已经单独广播过一次，所以共识 Block 中只需要包含交易 ID 即可，这样可以大大降低区块消息的大小。经测试在网络条件较好的情况下，对于简单的交易处理，有 5% 到 10% 的性能提升。

Fabric 共识机制限制业务效率提升

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

在 Fabric 中由于交易的执行是非确定性的，这点不同于 FISCO BCOS 和 CITA 的设计理念。所以需要背书节点先执行交易，并由客户端根据背书策略进行对比结果，再发给排序节点，最终由提交节点验证并更新各自的数据库。可以理解为：共识状态的过程是由客户端、背书节点、提交节点共同参与完成的；排序节点只负责交易顺序的共识，而不负责状态共识。在交易状态共识和排序可以分别采用不同的策略。比如交易状态可以采用超过 3/4 的状态一致，而排序节点的共识使用传统的 Raft 或者 Solo 共识，采用传统 CFT 共识即可满足多数场景。这里的问题是交易中需要包含用户的签名，以及多个背书节点的签名，以及 read/write set，这样导致交易非常大。

Fabric 在交易状态有冲突时，例如 A 和Ｂ之间频繁转帐这种场景，因为每笔交易都会修改 AB 账户的余额，所以会造成交易冲突。冲突交易每个块最多只能有一个交易被处理，这将大大限制业务合约的场景。

性能对比

CITA共识性能好

FISCO BCOS：

传统的 PBFT
共识过程中会重复执行交易，共识效率一般

CITA：

先共识再执行，只执行一次交易，整体效率较高
优化 Commit 阶段的 Leader 广播过程，减少共识时间
Proposal 预执行技术使得共识和执行并行，提高整体性能
CompactBlock 技术提高带宽利用率

Fabric：

执行（验证）和排序可以采用不同的共识策略，比较灵活
交易需要多个背书节点签名和 read/write 集合会导致交易非常大

对比可以看出 FISCO BCOS 采用传统 PBFT，共识效率一般；CITA 采用了自主研发的 CITA-BFT，共识和交易处理有 50% 以上的性能提升；Fabric 将整个流程拆分为执行、排序、验证，增加了灵活性，但是验证和执行的分离导致交易非常大。

应用场景

Fabirc 共识机制限制了业务场景

FISCO BCOS/CITA：都是 BFT 类共识，适合多数的联盟链场景，由参与方、监管方和可信第三方组成共识节点。

Fabric：将共识的流程拆分为执行，排序和验证，具有更好的灵活性，但是由此带来交易结构非常大，而且冲突交易每个块只能上链一个交易，大大限制了业务合约的场景。比如对于一个统计投票的合约，有 N 个投票者，每个投票人员通过发送交易进行投票，因为总的投票结果是共享状态，这种情况下每个区块只能处理一笔交易。比如对于 Randao 项目，需要收集参与者的所有提交信息，这个时候就需要一个集合变量来存储这些信息，由于每个参与者的交易都会修改这个集合变量，导致每个块只能处理一笔提交交易，并且集合变量会导致 read/write set 会非常大。

扩展性

安全性

可以看到，BCOS和CITA都使用类BFT的共识，所以在安全性方面分析现有的BFT协议即可，有用比较高的安全边界。

对于Fabric，由于执行、排序、提交节点职能的分离，且执行（验证）和排序可以分别采用不同的共识策略，安全策略可以由用户自由把握，客户端参与状态和执行的共识。

智能合约

智能合约一词有一定的误导性，智能往往给人带来一定的神秘色彩，就其合约功能本身来讲并无”智能性”。在区块链出现之前，所有的系统都是采用中心化的架构，监管机构和用户无法验证和保证系统功能的正确性，无法确保数据未被恶意修改，无法保证数据的安全性。由于区块链的出现，使得在不依赖于第三方的情况下，能够可信地进行交易，而且交易可追踪无法逆转。智能合约的核心含义在于：在区块链基础上实现可信计算，并由区块链协议保证的可追踪和无法逆转。

在比特币中交易主要用于点对点的现金支付，以太坊由于引入图灵完备的智能合约被称为区块链2.0。虽然理论上以太坊上的智能合约是图灵完备的，但是受限于交易手续费、合约指令、区块Gas上限、节点可信度等，公链智能合约并不适用于现有的企业开发。

联盟链由于节点数量有限，且节点运营方可以采用高性能的硬件设备，以及底层协议支持等，更适合企业开发。首先本文介绍三者智能合约的技术实现，再分别从安全性、易用性、可用性三方面进行对比分析。

技术实现

BCOS和CITA均支持EVM和预编译合约。借助于Ethereum 智能合约的完善的生态系统，两者都在其基础之上做了定制化，有丰富的合约编写和测试工具。

对于预编译合约需要开发者对区块链系统有一定的了解，需要较高的门槛。当前支持EVM的语言主要是Solidity，Solidity合约可以通过交易进行部署，在调用时将合约代码加载到虚拟机中。

Fabric的合约通过ChainCode的方式以Docker的方式进行线下安装，然后通过交易进行激活。ChainCode合约的部署相对较重，但支持多种语言（Go,Javascript等），合约的部署和更新以线下方式进行更新，合约代码并没有进行共识，可以将合约看成黑盒，只需要保证其输入和输出正确即可，并不关心其内部逻辑的具体实现。

由于Fabric采用了传统的语言进行合约编写，虽然开发者不需要学习新的语言，但是由于虚拟机的不确定性，ChainCode的方式只适合Fabric的先执行再共识再验证的共识方式，并不具备通用性。

安全性

安全性是智能合约有别于其他程序的主要特征，这里的安全性，包含确定性、可验证、可审计、可追踪等特性。

由于BCOS和CITA在智能合约设计理念上接近，本文将两者放入同一栏中。

对比可以看出由于BCOS/CITA交易是链上执行的，所以BCOS/CITA的智能合约更具有确定性、可验证、可审计、不可逆、可追踪的特点。

Fabric在合约代码由背书节点各自部署和升级，验证性、审计性、可追踪性无法保证。但是由于在Fabric的设计理念中，合约执行后再由客户端进行验证，本文可以认为合约最终的结果是由客户端和背书节点共同决定的，只要交易结果符合背书策略并且符合用户预期，对于合约代码的验证性要求相对就没有那么重要了。

易用性

BCOS/CITA在合约易用性上略胜于Fabric

BCOS/CITA支持以太坊EVM并且对其工具链进行深度优化，对开发者更友好，合约的部署、调用、升级都通过交易进行，更轻量和方便。

可用性

BCOS/CITA/Fabric都可以应对企业复杂的业务逻辑，支持比较复杂的合约计算和处理，同时CITA支持链上定时任务。

性能

经过区块链底层技术最近几年的发展，联盟链的性能已经不再是其最主要的瓶颈。

BCOS官方文档并未提供性能数据，本文只能根据第三方提供的数据来判断，我们找到了两个相对可靠的信息来源。中国信通院可信区块链最新评测（2019年11-19日），BCOS单链TPS超2万。[在2019年7月底的一篇新闻稿”](undefined)当测试团队说区块链性能达到10000TPS的那一刻，张开翔在微信群里给团队发出了人生中最大的红包。“。因为两次测试数据均未提供测试用的环境、节点数、使用的共识协议（BCOS支持Raft）等，推测这里可能是分别使用了不同的共识方法和节点数进行的测试。

CITA在官方文档中最新版本的交易性能已经可以达到 15,000+ TPS，数据来自 CITA 0.16 版本（2018年5月15日），在四台 32 核，64G 的云服务器上部署 4个节点，每台服务器配置百兆带宽。

Fabric官方并未提供其性能数据。根据第三方提供的数据（[https://arxiv.org/pdf/1801.10228.pdf](https://arxiv.org/pdf/1801.10228.pdf)），在32核CPU，10节点的情况下，性能可以到3400左右。根据这份报告背书节点数对性能影响并不大，因为背书节点并不实际参与共识。

现阶段联盟的性能已经有了长足的进步，相对落地场景而言，性能已经不再是最主要的瓶颈。同时国产联盟链在性能方面已经不输于国外的大品牌，甚至已经领先于国外。

存储

区块链的存储从内容方面讲主要包括两个方面：区块和交易存储、世界状态存储。本文先分别介绍各自的实现方式，再从支持数据库类型、存储效率、可扩展性、数据维护等方面进行对比分析。

实现方式

BCOS的状态存储支持两种存储模式

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

CITA支持RocksDB、External存储。使用MPT保存状态，使用Simple Merkle Tree保存交易和交易回执。对于状态存储CITA选择了经典的MPT存储，保存历史状态的同时，最大化减少存储数据。而对于交易和交易回执使用Simple Merkle Tree存储，可以优化存储数据量和减少Hash计算。

Fabric的区块存储，同样采用了MPT的方式进行保存。对于世界状态的存储支持KV和CouchDB存储，在世界状态存储时，Fabric不支持历史状态的保存，同时有性能上的提升，并支持丰富的条件查询和统计。

对比分析

对比来看：

CITA在交易的存储结构上做了优化和改进，提供了快照功能对世界状态的历史进行裁剪。BCOS世界状态的存储模式上，支持两种不同的模式，允许在牺牲一部分状态可追溯性上，提升性能和支持丰富的SQL查询。

Fabric的世界状态存储不保留历史状态，支持世界状态的条件查询。

本文认为在交易存储方面，节点必须要保留历史记录，而对于世界状态的历史存储，可以通过交易进行还原，在这种情况下BCOS/Fabric为用户提供较好的查询功能和较高的性能是一个不错的取舍。

治理

联盟链不同于公链的最大不同之处在于其治理方式的不同，对于公链来讲由于其是开放的系统需要一定的经济激励来协调不同角色间的关系，而联盟链由于节点是准入机制，所以其治理方式与公链有非常大的不同。对于联盟链来讲，其治理主要包含：节点管理、帐号权限、经济模型。

节点管理

对于BCOS和CITA来讲，节点主要分为两类：共识节点和普通节点。共识节点负责共识出块，普通节点只能同步数据并验证数据而没有打包交易的权力。

对于Fabric，节点分为背书节点，排序节点，提交节点。背书节点负责执行交易并返回结果，排序节点负责对交易排序并打包出块，提交节点负责验证交易并更新状态。

对于共识节点BCOS/CITA均采用了系统合约的方式进行管理，节点的增删需要共识节点进行共识。而Fabric的节点增删，可以由节点管理员修改配置，无需共识，但是激活新的配置文件需要发送交易并进行共识。

本文认为通过白名单/黑名单的方式或者CA的方式管理节点身份，均能满足联盟链的大多数场景，CA在对节点身份的验证方面更加严格。

用户权限管理

对于联盟链来将，联盟各个角色以及联盟内均需要比较复杂的权限管理，这样不同的角色只能访问属于自己授权的资源。

在CITA/BCOS中都通过复杂的权限管理，来对用户的交易权限进行管理，包括发送交易，创建合约，合约方法调用权限等等。

Fabric通过配置文件的方式(Policy）的方式进行管理用户的权限。

BCOS/CITA权限管理通过交易的方式进行管理，比Fabric通过配置文件的方式修改，更加区块链化，治理操作会保留痕迹。

经济模型

CITA支持两种不同的经济模型

在公链中，矿工打包用户的交易往往需要用户支付一定的手续费；对于联盟链来讲，情况有所不同。

BCOS、CITA和Fabric均支持向用户提供免费服务的模式，同时在BCOS/CITA中会通过系统合约控制用户单个区块内对系统资源的使用情况，防止对系统滥用。

而CITA又可以支持收费模式，节点对用户交易精确计费并收取Token手续费。而Token即可以是节点免费分配给用户，也可以需要用户有偿使用，这样可以更加精细地控制用户对系统资源的使用情况。

跨链和隐私

跨链和隐私方案，距离生产环境依然有可优化空间

BCOS引入了群组的方式，使一个节点可以属于不同群组，而群组的消息、交易、存储、执行等等完全隔离。

Fabric 的群组概念和BCOS类似，一个节点可以属于不同群组，不同群组可以使用不同的背书策略。

在BCOS和Fabric中，群组的数据和通信等都是隔离的，并且可以使用不同的共识策略，所以可以将其看成多链。当前对于多链最大的问题在于链间通信，两者在这方面均没有非常成熟方案。

在CITA中，引入了侧链技术，侧链和主链之间可以互相通信，侧链技术距离生产环境依然有可优化的空间。

无论群组或者侧链等技术，本质上都是一种多链技术，当前多链技术只能解决节点的隐私问题，暂时无法处理交易和用户级别的隐私。

CITA已经开源其零知识证明和SGX的实现。

对于同态加密、零知识证明，SGX等等，都处于发展阶段，距离生产环境依然有可优化的空间。

密码学支持

CITA在密码学支持上更全面

对比可以看到BCOS/CITA均支持国密，对国内监管需求较友好；在密码学算法支持上CITA更全面，除了支持常见的Keccak/Secp256k1之外，也支持更安全性能更好的Keccak/Secp256k1。

系统架构

CITA采用了微服务架构

BCOS和Fabric均采用了单一系统的架构，这种架构要求节点必须在单一的物理机器上。

而CITA采用了微服务架构，而且CITA也是全球第一个使用微服务架构的开源区块链。采用微服务架构，可以使节点不仅仅限制在单个物理机器上，这样对于企业用户可以用更好的硬件设备去支持节点，有更好的扩展性。由于微服务间通过消息订阅进行通信，企业用户可以方便地替换或者增加定制化的服务，方便进行功能扩展。

开源协议

BCOS的开源协议对商业应用不够友好

这里简单介绍下相关的开源协议。

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

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

由此可以看出，BCOS的开源协议对商业应用不够友好。

语言实现

CITA使用更现代的语言Rust，性能更高同时安全性更可靠

BCOS：使用C++进行开发，C++性能高，但是由于其历史原因，系统容易有内存安全的隐患；

Fabirc：Go实现，由于垃圾回收机制性能比C++弱；

CITA：Rust实现，现在相对主流的区块链界的语言，Rust在内存安全方面有保证，性能可以和C++媲美。

总结

经过以上的分析，本文汇总其最主要的优缺点：