【51CTO.com原创稿件】
摘要
第46届世界经济论坛达沃斯年会将区块链与人工智能、自动驾驶等一并列入“第四次工业革命”。《经济学人》曾在2015年10月的封面文章《信任的机器》中介绍区块链——“比特币背后的技术有可能改变经济运行的方式”。
区块链之所以被称为信任的机器源于其分布式和不可篡改的两个核心特性，这也是区块链有别于传统数据库的核心特性。这里的分布式包含两层含义：一是传统的分布式存储，二是区块链的底层协议带来的协作性，我们这里更多的是指代其分布式协作的能力。
党中央在10月24日下午就区块链技术发展现状和趋势进行第十八次集体学习时指出，要抓住区块链技术融合、功能拓展、产业细分的契机，发挥区块链在促进数据共享、优化业务流程、降低运营成本、提升协同效率、建设可信体系等方面的作用。我们认为正是由于区块链”可信的机器”的特性使其有在社会的诸多领域发挥重要作用的潜力。
在区块链中主要通过共识算法、智能合约、治理、跨链、隐私等来实现其“可信协作”，所以我们将从这几个方面并结合企业应用场景来分析底层技术的差异，来帮助企业用户更好地做出选择。同时我们也会从传统企业软件的可维护性、性能、开发工具、扩展性、软件协议等方面来进行分析和对比。
我们选择了市面上历史最悠久，用户范围最广的几个开源底层进行对比。
FISCO BCOS诞生于2017年，由金链盟推出，是标准的国产底层。金链盟是由深圳市金融科技协会、深圳前海微众银行、深证通等二十余家金融机构和科技企业于2016年5月31日共同发起成立的非营利性组织。
CITA 是一个开源的区块链操作系统内核，以高稳定性，高性能，高可扩展性为设计目标。CITA 开源项目由秘猿科技 Cryptape 于2016年发起。目前由溪塔科技等CITAHub社区企业共同维护。CITA 采用微服务架构设计，提供丰富的开发工具集，灵活的区块链治理工具，开发者可为不同类型的区块链网络进行二次开发或配置。
Hyperledger Fabric是分布式账本解决方案的平台，该平台以模块化架构为基础，提供高度的机密性，灵活性和可扩展性。 它旨在支持不同组件的可插拔实现，并适应整个经济生态系统中存在的复杂性。Fabric最早由IBM设计和开发，2015年将其源代码奉献给了Linux基金会的Hyperledger项目。
共识和交易流程
共识机制作为区块链的灵魂，无论是公链还是联盟链，共识机制都从根本上限制了区块链的交易处理能力和扩展性，同时也是其分布式协作能力的基础。共识是分布式系统中节点对数据或网络最终状态达成的协议。由于网络环境和节点状态的不可控，共识机制需要同时考虑性能、可靠性、安全性等多方面问题。共识机制从大的方面，可分为 Nakamoto Consensus等无需准入的共识机制，和PBFT等需要准入的共识机制两大类。
Nakamoto 共识在公链上应用广泛，但是它的概率模型在提供较高可靠性的同时，牺牲了效率。在具体商业应用环境中，许可机制已经保证了一定程度上的节点可信度，这样的前提下，用户更关心执行效率和最终确定性。这是BFT类共识在联盟链中流行的原因。
下面先分别介绍BCOS、CITA和 Fabirc共识技术实现，我们再从性能，应用场景，扩展性和安全性等几个方面来进行对比分析。
技术实现
BCOS共识机制效率相对较低
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阶段验证一次，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中由于交易的执行是非确定性的，这点不同于BCOS和CITA的设计理念。所以需要背书节点先执行交易，并由客户端根据背书策略进行对比结果，再发给排序节点，最终由提交节点验证并更新各自的数据库。我们可以理解为：共识状态的过程是由客户端、背书节点、提交节点共同参与完成的；排序节点只负责交易顺序的共识，而不负责状态共识。在交易状态共识和排序可以分别采用不同的策略。比如交易状态可以采用超过3/4的状态一致，而排序节点的共识使用传统的Raft或者Solo共识，采用传统CFT共识即可满足多数场景。这里的问题是交易中需要包含用户的签名，以及多个背书节点的签名，以及read/write set，这样导致交易非常大。
Fabric在交易状态有冲突时，例如A和Ｂ之间频繁转帐这种场景，因为每笔交易都会修改AB账户的余额，所以会造成交易冲突。冲突交易每个块最多只能有一个交易被处理，这将大大限制业务合约的场景。
性能对比
最佳">CITA共识性能最佳
BCOS：
•传统的PBFT
•共识过程中会重复执行交易，共识效率较低
CITA：
•先共识再执行，只执行一次交易，整体效率较高
•优化Commit阶段的Leader广播过程，减少共识时间
•Proposal预执行技术使得共识和执行并行，提高整体性能
•CompactBlock技术提高带宽利用率
Fabric：
•执行（验证）和排序可以采用不同的共识策略，比较灵活
•交易需要多个背书节点签名和read/write集合会导致交易非常大
对比可以看出BCOS采用传统PBFT，共识效率较低；CITA采用了自主研发的CITA-BFT，共识和交易处理有50%以上的性能提升；Fabric将整个流程拆分为执行、排序、验证，增加了灵活性，但是验证和执行的分离导致交易非常大。
应用场景
Fabirc共识机制限制了业务场景
BCOS/CITA：都是BFT类共识，适合多数的联盟链场景，由参与方、监管方和可信第三方组成共识节点。
Fabric：将共识的流程拆分为执行，排序和验证，具有更好的灵活性，但是由此带来交易结构非常大，而且冲突交易每个块只能上链一个交易，大大限制了业务合约的场景。比如对于一个统计投票的合约，有N个投票者，每个投票人员通过发送交易进行投票，因为总的投票结果是共享状态，这种情况下每个区块只能处理一笔交易。
扩展性
|
|
BCOS |
CITA |
Fabric |
|
节点扩展性 |
方便节点的增删 |
方便节点的增删 |
背书节点增删方便，排序节点增删方便， 背书策略易修改， 排序策略易修改。 |
|
节点模块化 |
共识/执行耦合，不易替换和定制化 |
共识和执行模块分离，方便替换和定制化 |
执行、排序、验证分离，节点功能可以根据情况自由组合 |
安全性
|
|
BCOS |
CITA |
Fabric |
|
执行共识 |
BFT类算法只要保证2/3+1个节点诚实即可正常出块，保证1/3个共识节点诚实即可保证结果正确。 |
BFT类算法只要保证2/3+1个节点诚实即可正常出块，保证1/3个共识节点诚实即可保证结果正确。 |
不同的背书策略安全性不同，既可以是安全性较高的背书节点全部通过，也可以是单一背书节点通过的策略。 |
|
交易排序上链 |
BFT类算法只要保证2/3+1个节点诚实即可保证交易会上链 |
BFT类算法只要保证2/3+1个节点诚实即可保证交易会上链 |
排序可以采用Raft或者Solo共识，Leader节点具有较大权限可以拒绝交易。 |
|
交易记录的不可篡改 |
链式结构保证交易记录不会篡改 |
链式结构保证交易记录不会篡改 |
链式结构保证交易记录不会篡改 |
|
交易状态一致性 |
BFT类算法只要保证2/3+1个节点诚实即可正常出块，保证1/3个共识节点诚实即可保证结果正确。 |
BFT类算法只要保证2/3+1个节点诚实即可正常出块，保证1/3个共识节点诚实即可保证结果正确。 |
排序和验证都不进行最终状态的共识，由提交节点来验证交易，并分别更新各自状态。只有等待下一个相关交易读取状态或者客户端主动查询，由客户端判断状态是否一致。 |
可以看到，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 |
Fabric |
|
确定性 |
完全确定 |
由于合约采用通用语言，合约执行存在不确定性，且执行环境有存在差异的可能性，所以不能100%保证合约计算的一致性和正确性。 |
|
可验证、可审计 |
链上部署、调用合约，合约代码保存在链上，可以对合约执行进行验证、审计 |
合约部署分别由背书节点独自部署和运行，不在链上进行部署和共识，链下共识，存在节点误部署和修改代码的风险，无法通过区块链协议保证合约的不可篡改，对验证和审计不够友好。 |
|
不可逆 |
区块链协议和数据结构保证 |
区块链协议和数据结构保证 |
|
可追踪 |
通过交易追踪合约的部署、调用、更新 |
通过交易追踪合约的激活和调用，但是合约代码变更不可追踪。 |
对比可以看出由于BCOS/CITA交易是链上执行的，所以BCOS/CITA的智能合约更具有确定性、可验证、可审计、不可逆、可追踪的特点。
Fabric在合约代码由背书节点各自部署和升级，验证性、审计性、可追踪性无法保证。但是由于在Fabric的设计理念中，合约执行后再由客户端进行验证，我们可以认为合约最终的结果是由客户端和背书节点共同决定的，只要交易结果符合背书策略并且符合用户预期，对于合约代码的验证性要求相对就没有那么重要了。
易用性
BCOS/CITA在合约易用性上略胜于Fabric
|
|
BCOS/CITA |
Fabric |
|
语言友好度 |
多数场景下使用Solidity语言，经过长时间发展，Solidity已较为成熟，易上手 |
支持传统语言，易上手 |
|
工具链 |
两者都基于Solidity的工具链进行了深度定制化，工具链完善 |
传统语言，工具链完善 |
|
部署 |
通过交易，方便部署，链上部署 |
由背书节点通过Docker分别部署，部署成本高 |
|
调用 |
合约之间可以方便调用 |
合约调用必须在同一个ChainCode中 |
|
升级 |
通过部署新合约的方式进行升级 |
背书节点分别去升级 |
BCOS/CITA支持以太坊EVM并且对其工具链进行深度优化，对开发者更友好，合约的部署、调用、升级都通过交易进行，更轻量和方便。
可用性
|
|
BCOS |
CITA |
Fabric |
|
复杂合约 |
通过设置区块交易上限使区块链可以处理复杂度非常高的合约 |
通过设置区块交易上限使区块链可以处理复杂度非常高的合约 |
背书节点分别执行合约，并不对合约时间和复杂度进行限制 |
|
并行计算 |
支持并行计算，但是需要在交易中预先设置冲突状态，场景有限且使用难度比较高 |
不支持并行计算，交易依次执行 |
不支持并行计算，交易依次执行。同一个区块中不允许有冲突交易，否则后续交易会失败 |
|
指令扩展 |
通过预编译合约进行指令扩展 |
通过预编译合约进行指令扩展 |
传统语言，指令丰富，不需要扩展。 |
|
定时任务 |
不支持 |
区块链内置合约定时执行功能 |
不支持 |
BCOS/CITA/Fabric都可以应对企业复杂的业务逻辑，支持比较复杂的合约计算和处理，同时CITA支持链上定时任务。
性能
经过区块链底层技术最近几年的发展，联盟链的性能已经不再是其最主要的瓶颈。
BCOS官方文档并未提供性能数据，我们只能根据第三方提供的数据来判断，我们找到了两个相对可靠的信息来源。中国信通院可信区块链最新评测（2019年11-19日），BCOS单链TPS超2万。在2019年7月底的一篇新闻稿”当测试团队说区块链性能达到10000TPS的那一刻，张开翔在微信群里给团队发出了人生中最大的红包。“。因为两次测试数据均未提供测试用的环境、节点数、使用的共识协议（BCOS支持Raft）等，推测这里可能是分别使用了不同的共识方法和节点数进行的测试。
CITA在官方文档中最新版本的交易性能已经可以达到 15,000+ TPS，数据来自 CITA 0.16 版本（2018年5月15日），在四台 32 核，64G 的云服务器上部署 4个节点，每台服务器配置百兆带宽。
Fabric官方并未提供其性能数据。根据第三方提供的数据（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不支持历史状态的保存，同时有性能上的提升，并支持丰富的条件查询和统计。
对比分析
|
|
BCOS |
CITA |
Fabric |
|
分布式数据库支持 |
支持 |
支持 |
支持 |
|
交易/回执存储 |
支持KV数据库 |
支持KV数据库 |
支持KV数据库 |
|
交易/回执存储性能 |
使用MPT存储，性能一般 |
使用Simple Merkle Tree，存储和计算性能略好于MPT |
使用MPT存储，性能一般。每个交易均需要保留背书节点的签名，交易数据要大很多 |
|
KV状态存储 |
支持两种模式： KV数据库，保留历史可追溯； SQL数据库，不保留历史数据不可追溯，支持条件查询 |
支持KV数据库，保留历史可追溯。 |
支持KV数据库，不保留历史不可追溯。 支持CouchDB，不保留历史不可追溯，支持条件查询 |
|
状态快照 |
不支持 |
支持快照，对世界状态历史进行裁剪，减少历史状态的存储 |
不支持 |
对比来看：
CITA在交易的存储结构上做了优化和改进，提供了快照功能对世界状态的历史进行裁剪。
BCOS世界状态的存储模式上，支持两种不同的模式，允许在牺牲一部分状态可追溯性上，提升性能和支持丰富的SQL查询。
Fabric的世界状态存储不保留历史状态，支持世界状态的条件查询。
我们认为在交易存储方面，节点必须要保留历史记录，而对于世界状态的历史存储，可以通过交易进行还原，在这种情况下BCOS/Fabric为用户提供较好的查询功能和较高的性能是一个不错的取舍。
治理
联盟链不同于公链的最大不同之处在于其治理方式的不同，对于公链来讲由于其是开放的系统需要一定的经济激励来协调不同角色间的关系，而联盟链由于节点是准入机制，所以其治理方式与公链有非常大的不同。对于联盟链来讲，其治理主要包含：节点管理、帐号权限、经济模型。
节点管理
对于BCOS和CITA来讲，节点主要分为两类：共识节点和普通节点。共识节点负责共识出块，普通节点只能同步数据并验证数据而没有打包交易的权力。
对于Fabric，节点分为背书节点，排序节点，提交节点。背书节点负责执行交易并返回结果，排序节点负责对交易排序并打包出块，提交节点负责验证交易并更新状态。
|
|
BCOS |
CITA |
Fabric |
|
共识节点 |
通过系统合约进行管理，节点管理员通过发送交易进行共识节点的增删 |
通过系统合约进行管理，节点管理员通过发送交易进行共识节点的增删 |
通过配置文件进行管理排序节点管理，节点管理员通过发送交易激活新的配置文件，通过CA来认证 |
|
普通节点 |
通过白名单和黑名单管理链接，通过CA来判断节点是否为普通节点 |
每个节点通过各自的白名单/黑名单来管理各自的普通节点，不判断普通节点身份 |
通过配置文件来管理背书节点和提交节点，Channel管理员通过发送交易来激活新的配置文件，通过CA来认证 |
对于共识节点BCOS/CITA均采用了系统合约的方式进行管理，节点的增删需要共识节点进行共识。而Fabric的节点增删，可以由节点管理员修改配置，无需共识，但是激活新的配置文件需要发送交易并进行共识。
我们认为通过白名单/黑名单的方式或者CA的方式管理节点身份，均能满足联盟链的大多数场景，CA在对节点身份的验证方面更加严格。
用户权限管理
对于联盟链来将，联盟各个角色以及联盟内均需要比较复杂的权限管理，这样不同的角色只能访问属于自己授权的资源。
在CITA/BCOS中都通过复杂的权限管理，来对用户的交易权限进行管理，包括发送交易，创建合约，合约方法调用权限等等。
Fabric通过配置文件的方式(Policy）的方式进行管理用户的权限。
BCOS/CITA权限管理通过交易的方式进行管理，比Fabric通过配置文件的方式修改，更加区块链化，治理操作会保留痕迹。
经济模型
CITA支持两种不同的经济模型
在公链中，矿工打包用户的交易往往需要用户支付一定的手续费；对于联盟链来讲，情况有所不同。
|
|
BCOS |
CITA |
Fabric |
|
免费模式 |
用户免费发送交易，但是会限制用户每个区块内交易复杂度，虽然免费但是也在一定程度上限制用户滥用资源 |
用户免费发送交易，但是会限制用户每个区块内交易复杂度，虽然免费但是也在一定程度上限制用户滥用资源 |
不考虑交易复杂度和交易数量，只要有权限，背书节点一定会执行，用户可以随意使用系统资源 |
|
收费模式 |
无 |
用户发送交易需要支付系统原生Token给出块节点，管理员可以通过系统合约调整共识节点出块权限 |
无 |
BCOS、CITA和Fabric均支持向用户提供免费服务的模式，同时在BCOS/CITA中会通过系统合约控制用户单个区块内对系统资源的使用情况，防止对系统滥用。
而CITA又可以支持收费模式，节点对用户交易精确计费并收取Token手续费。而Token即可以是节点免费分配给用户，也可以需要用户有偿使用，这样可以更加精细地控制用户对系统资源的使用情况。
跨链和隐私
跨链和隐私方案，距离生产环境依然有可优化空间
BCOS引入了群组的方式，使一个节点可以属于不同群组，而群组的消息、交易、存储、执行等等完全隔离。
Fabric 的群组概念和BCOS类似，一个节点可以属于不同群组，不同群组可以使用不同的背书策略。
在BCOS和Fabric中，群组的数据和通信等都是隔离的，并且可以使用不同的共识策略，所以可以将其看成多链。当前对于多链最大的问题在于链间通信，两者在这方面均没有非常成熟方案。
在CITA中，引入了侧链技术，侧链和主链之间可以互相通信，侧链技术距离生产环境依然有可优化的空间。
无论群组或者侧链等技术，本质上都是一种多链技术，当前多链技术只能解决节点的隐私问题，暂时无法处理交易和用户级别的隐私。
CITA已经开源其零知识证明和SGX的实现。
对于同态加密、零知识证明，SGX等等，都处于发展阶段，距离生产环境依然有可优化的空间。
密码学支持
CITA在密码学支持上更全面
|
|
BCOS |
CITA |
Fabric |
|
Hash算法 |
Keccak |
Keccak/blake2b |
SHA3 |
|
签名算法 |
Secp256k1 |
Secp256k1/ED25519 |
Secp256k1 |
|
国密支持 |
支持 |
支持 |
否 |
对比可以看到BCOS/CITA均支持国密，对国内监管需求较友好；在密码学算法支持上CITA更全面，除了支持常见的Keccak/Secp256k1之外，也支持更安全性能更好的Keccak/Secp256k1。
系统架构
CITA采用了微服务架构
BCOS和Fabric均采用了单一系统的架构，这种架构要求节点必须在单一的物理机器上。
而CITA采用了微服务架构，而且CITA也是全球第一个使用微服务架构的开源区块链。采用微服务架构，可以使节点不仅仅限制在单个物理机器上，这样对于企业用户可以用更好的硬件设备去支持节点，有更好的扩展性。由于微服务间通过消息订阅进行通信，企业用户可以方便地替换或者增加定制化的服务，方便进行功能扩展。
开源协议
BCOS的开源协议对商业应用不够友好
|
|
BCOS |
CITA |
Fabric |
|
开源协议 |
GPL-3.0 |
Apache-2.0 |
Apache-2.0 |
这里简单介绍下相关的开源协议。
GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
由此可以看出，BCOS的开源协议对商业应用不够友好。
语言实现
CITA使用更现代的语言Rust，性能更高同时安全性更可靠
BCOS：使用C++进行开发，C++性能高，但是由于其历史原因，系统容易有内存安全的隐患；
Fabirc：Go实现，由于垃圾回收机制性能比C++弱；
CITA：Rust实现，现在相对主流的区块链界的语言，Rust在内存安全方面有保证，性能可以和C++媲美。
总结
经过以上的分析，我们汇总其最主要的优缺点：
|
|
BCOS |
CITA |
Fabric |
|
优点 |
• 两种不同的存储模式 • 智能合约方便易用 |
• 自主研发高效的共识算法 • 智能合约方便易用 |
• 支持CouchDB存储 • 共识协议更加灵活 |
|
缺点 |
• 开源协议对商业应用不友好 |
• 数据库不支持条件查询 |
• 共识和交易流程限制其业务场景 |
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
