联盟链走向何方

时间 2020-08-08 标签联盟走向何方

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

出品：碳链价值研究院数据库

　01　安全

摘要服务器

第 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++媲美。

总结

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