Fabric 1.4和BCOS 2.0对比

实现方式

Fabric	BCOS
Docker	EVM沙箱机制

Fabric部署一个新的智能合约或者要做升级的时候，所有参与节点要人工安装部署一次；
BCOS发布新业务时，把合约放在链上即可以运行，不需要线下部署的操作。

架构分析

（一）节点分类

Fabric	BCOS
1.Client	1.共识节点
2.Peer	2.观察节点
3.orderer	3.游离节点

Fabric节点：
Client：该客户端提交真实的交易请求（transaction-invocation）给背书者，广播交易提案（transaction-proposals）给ordering服务。
Peer：该节点提交交易，维护世界状态和账本。
orderer：该节点运行着通信服务，提供传递担保服务，如原子性，排序广播。
BCOS将节点分为共识节点和观察节点，共识节点参与共识算法，成为链上的记账者，观察节点不参与共识，只同步数据。游离节点是完成网络准入但没有加入群组的节点，不参与共识和同步。

（二）交易流程

1. 客户端创建一笔交易并且发送给它选择的背书节点。
2. 背书节点模拟交易并产生背书签名。
3. 提交客户端为交易收集背书并通过ordering服务广播该背书。
4. 排序服务向对等节点传送一笔交易，节点进行账本更新。

1. 用户通过操作SDK或直接编写curl命令向所连接的节点发起交易。
2. 节点收到交易后，若当前交易池未满则将交易附加至TxPool中并向自己所连的节点广播该交易；否则丢弃交易并输出告警。
3. Sealer会不断从交易池中取出交易，并立即将收集到的交易打包为区块并发送至共识引擎。
4. 共识引擎调用BlockVerifier对区块进行验证并在网络中进行共识，BlockVerifier调用Executor执行区块中的每笔交易。当区块验证无误且网络中节点达成一致后，共识引擎将区块发送至BlockChain。
5. BlockChain收到区块，对区块信息（如块高等）进行检查，并将区块数据与表数据写入底层存储中，完成区块上链。

（三）灵活性

Fabric采用松耦合的设计，将共识机制、身份验证等组件模块化，在应用过程中可根据应用场景选择相应模块；同时，fabric可支持针对不同主体间交易的多通道结构，实现更为灵活的业务适应性（业务隔离、安全性等）。

BCOS共识算法模块采用插件化设计实现，通过修改系统配置，实现在多个联盟链里使用不同的共识机制，参与到同一个联盟链的所有节点必须采用同一种共识配置。

核心技术组件

核心技术组件是指区块链系统所依赖的基础组件、协议和算法，可进一步细分为通信、存储、安全机制、共识机制四个方面。

（一）通信

Fabric	BCOS
gossip协议	JSON-RPC 2.0协议

gossip协议：gossip协议主要是一个P2P的网络传输协议，fabric主要通过此协议来进行区块的同步。
JSON-RPC：一种无状态、轻量级的远程过程调用协议。该规范主要定义了几个数据结构及其处理规则。它允许运行在基于socket，http等诸多不同消息传输环境的同一进程中。它使用JSON(RFC 4627)作为数据格式。

（二）存储

Fabric	BCOS
普通的文件和kv的数据库（levelDB/couchDB）	AMDB（分布式存储）（levelDB/MySQL）

AMDB：通过抽象表结构，实现了SQL和NOSQL的统一，通过实现对应的存储驱动，可以支持各类数据库，目前已经支持LevelDB和MySQL。

（三）安全机制

Fabric	BCOS
用传输层安全性（TLS）保护通信安全	节点准入机制 、CA黑名单、权限控制

TLS通信可以使用单向（仅服务器）和双向（服务器和客户端）身份验证。
FISCO BCOS通过引入群组概念，使联盟链从原有一链一账本的存储/执行机制扩展为一链多账本的存储/执行机制，基于群组维度实现同一条链上的数据隔离和保密。
基于群组概念的引入，节点准入管理可分为网络准入机制和群组准入机制。
CA黑名单，别称证书拒绝列表（certificate blacklist，简称CBL）。CA黑名单基于config.ini文件中[certificate_blacklist]配置的NodeID进行判断，拒绝此NodeID节点发起的连接。
分布式权限控制基于外部账户(tx.origin)的访问机制，对包括合约部署，表的创建，表的写操作（插入、更新和删除）进行权限控制，表的读操作不受权限控制。

（四）共识机制

Fabric	BCOS
Solo	PBFT
Kafka	Kafka
Raft

Hyperledger Fabric在0.6版中应用了PBFT，而在1.0版中放弃了PBFT，转而采用效率更高的Kafka，支持单点和集群两种方式，由Kafka直接给交易排序和出块。
FISCO BCOS基于插件化的共识机制，支持并行计算的PBFT和标准Raft两种方式，使用者可根据需要进行插件化的配置。

应用功能

（一）身份认证

Fabric和BCOS均支持数字证书的身份认证形式。
Fabric提出了一个基于PKI的身份管理，实施交易的权限管理。首先通过Registration Author（RA）注册获得许可，然后通过Enrollment Certificate Authority（ECA）获得注册安全证书（ECert）；第三步，通过Transaction Certificate Authority（TCA）获得交易安全证书，最后只有使用以上证书的二者之一签名的节点才能发起交易请求。
BCOS使用CA证书的准入机制，支持用户账户管理功能，采用角色和权限模型实现联盟链参与者管理，底层平台还预置了控制交易和部署合约的权限和接口。

（二）账户设计

Fabric和BCOS都没有代币概念。

（三）支持智能合约

Fabric的智能合约运行环境选择的是docker容器，在容器里可以支持java、go等语言编写的智能合约，提供一些复杂业务逻辑运行。对可以执行的智能合约的记账节点，每一份新部署的智能合约都将在一个独立的docker中运行。为每一个智能合约创建一个docker是fabric设计存在争议的地方。目前fabric并不支持对智能合约运行docker的生命周期管理。
BCOS主要运用solidity合约开发语言，其作为Ethereum的主要合约开发语言，具有图灵完备的特性。

（四）监管功能

在fabric系统中，监管机构可以按照规定规则来审计全部或部分总帐分录。在参与者合作中，审计员可以通过基于时间的证书来获得总帐查看权限，链接交易来提供实际的资产操作。Fabric利用密钥的层级可以给与审计员检查某些交易、某组交易的审计权限，只将最相关的密钥披露给审计实体以提供审计的可能性。不是系统成员的应用审计人员，可以给与被动的观察区块链数据的权限，同时保证给与他们只是为了与被审计应用程序相关的交易。
BCOS可支持监管部门和审计部门作为特殊节点加入，及时同步数据，并对数据完整性、有效性、过程和流程的合规性进行及时的监控，从而可对异常或违规行为及时处理或给与指导意见。另外，BCOS还可提供可监管、可审计的数据接口。

（五）特权机制

目前，特权机制主要有两类：一是暂停、回滚或者取消交易；二是改正数据。
Fabric暂无相关内容。
BCOS可以针对特定的业务场景，制定特定的权限集合，如监管方可以是联盟链的规则制定者和实施者，通过参与准入审核，智能合约编写、部署和升级，以及事前中后的监测和干预对业务实施监管。监管方也可以选择性地参与道交易过程，例如在合约执行前或者生效前，由监管方检查合约的规则、数据，必须符合监管要求，才给出签名背书。一旦发现违法行为，监管方拥有一系列控制权限，包括但不限于堆某个业务叫停、冲正某些交易、冻结某些账户、升级合约以修改订正业务规则等。底层平台预置了控制交易和部署合约的权限和接口，通过监管工具、角色赋权等方案，让监管方可以直接实施联盟链的控制。

（六）角色权限

Hyperledger Fabric中虽然成员没有明确的角色划分，但是基于其运维或对应的节点的差异会自然形成不同的角色；
FISCO BCOS网络中的角色包含超级管理员、链或权限管理员、运维、交易、监管等。
Hyperledger Fabric中权限主要通过策略进行管理，策略实际上是成员通过节点进行某种操作，比如提交交易提案等，所需要满足的签名数量要求。
FISCO BCOS权限管理采用系统合约的方式，并可以通过自定义合约的方式进行权限管理功能的扩展，权限管理模型为ARPI（账户—角色—权限—接口）模式，多个账户可以对应同一个角色，角色有明确的权限列表，每个权限对应一个接口，接口指向智能合约，权限列表按照系统合约方式维护。业务中的权限管理则采用交易权限链的方式，一个交易相当于一组权限链，包含多个Filter，交易处理是逐个Filter行权限判断，一个交易完成相当于一组Filter审核都通过。

技术能力

从平台业务吞吐量、区块或交易确认时间、区块链平台可用性进行分析，此外，平台最大支持节点数量、最大并发开发者数量、最大并发用户访问量、平台稳定性也是研究因素。

（一）吞吐量

本地环境：4核8G、4节点
Hyperledger Fabric实测写入接口TPS在200-300之间；
FISCO BCOS实测单链并行转账可以达到1000以上。并且支持多链架构下的并行计算，可灵活扩展，理论上无上限。

（二）确认时间

Fabric和BCOS均可秒级出块，出块即达成共识。

（三）存储消耗

Hyperledger Fabric方面，根据蚂蚁金服给出的计算公式，Fabric数据容量估算（GB）=每种业务每天平均交易笔数x (Fabric每笔交易基本开销+每笔交易平均业务数据大小KB x 2 ) x业务Channel数量x（365 x年数x（Peer节点数量x 2~1 之间+ Orderer节点数量）+ afka Retention天数x Kafka Replica数量）/ (1024 x 1024)，其计算示例中，在业务笔数每天10万、4节点、2通道、单笔交易容量1K的情况（其他因素不详细列出了）下，年存储消耗4619G；
FISCO BCOS 2.0新增了对分布式数据存储的支持，节点可将数据存储在远端分布式系统中，克服了本地化数据存储的诸多限制。支持历史数据快速追踪，对接数据库，实现分布式存储，能够支持海量服务的存储需求，提高存储访问速率，节省存储消耗。

（四）节点数量

Hyperledger Fabric在节点数量扩展方面是弱项，已落地项目多是个位数节点，但是可以支持较多的客户端，算是一种弥补，不过节点数少其实意味着参与方的独立性是会有所下降的；
FISCO BCOS的群组模式支持根据节点数量进行水平扩容，因此理论上节点数量是不受限制的。

安全机制

区块链在设计中采用了分布式数据存储、共识机制、数字签名、加密算法等多种安全手段和技术。这些技术保证了数据的完整性、不可篡改和一致性，从而保证了数据从交易、共识计算、区块确认、数据存储等全生命周期的安全性。

（一）加密算法

都支持使用非对称加密算法。
Hyperledger Fabric不支持国密替换，目前已有的应用凡实现国密的基本上是自行替换或者依赖第三方服务；
FISCO BCOS支持国密。

（二）密钥存储

Fabric的密钥文件可以存储在支持PKCS11的硬件设备中。BCOS密钥保存在与区块链节点隔离的服务器、加密文件、USBKey、加密机等。需要使用私钥时，通过安全的内部通信接口或通过用户密码授权访问私钥。
BCOS采用落盘加密：落盘加密是对节点存储在硬盘上的内容进行加密，加密的内容包括：合约的数据、节点的私钥。

（三）密钥使用和密钥找回

均无定期更换机制，且私钥丢失后无法找回。

（四）第三方认证证书

Hyperledger Fabric目前不支持第三方CA；
FISCO BCOS支持第三方证书，支持证书的撤销，支持多CA。

（五）隐私保护

Fabric利用多通道（Channel）的机制保护隐私性。Channel代表了一个私有的广播通道，保证了消息的隔离性和私密性，不同的chaincode关联主体只知道自己chaincode相关交易和执行交易验证，共识服务只接收相关主体的广播请求和执行堆相关主体的消息送达，节点只记录与其相关的chaincode的状态。另外，chaincode可设定为保密，系统依据部署时设定的保密级别，执行通讯消息加密。Fabric在多通道模式下，共识节点会接受所有通道的交易数据，需要对共识节点进行适当的安全管理和技术控制，防止信息泄漏。
BCOS设计了AMOP协议，以提供机构间的点对点通信，通信信息属于链下信息，不在全网共享，链上部分在引入中央对手方提供信用背书的情况下，数据也仅在交易方和中央对手方之间共享，多链方式也可用于数据隔离，必要时通过跨连互通。BCOS还可使用数据脱敏、机构间点对点通信、数据明细链下保高强度加密数据信封方式等方式实现隐私控制。另外，BCOS已在客户端和智能合约上实现加法同态加密算法，例如在部分只涉及到数据加减的场景，可采用加法同态加密算法，实现对数据的隐私保护，同时不会对性能造成很大影响。BCOS还计划增加多操作同态加密和零知识证明用于证明加密数据的正确性（如账户余额数据是否足够用于支付）。
总体来看，理想的隐私保护策略，如零知识证明、动态加密等大都基于较为复杂的密码学技术，目前在各平台实际应用中有待进一步完善并丰富应用场景。

开发及工具

（一）编程语言方面

Fabric的项目核心代码主要由go编写。Fabric采用了容器技术，讲智能合约代码放在docker中运行，可以用go、java等语言编写智能合约。
BCOS业务层支持采用如C++、java、python、javascript、go等语言进行开发，可使用ethereum的solidity语言作为合约开发语言。

（二）配套开发工具

均提供sdk工具包，在github上开源。

（三）接口的完备程度

Fabric提供了一套可灵活扩展的API接口，其每个模块都定义了相应的API接口，因此这些模块可以实现“即插即用”。例如共识算法的API支持用户无需修改算法代码就可以在各类用例中使用这一算法。
BCOS对业务层提供接口服务，并通过接口和区块链节点进行交互、发送交易、查询数据等。平台也提供https的服务端口，采用json编码格式定义功能接口，包括用户数据查询、区块数据查询、合约部署和管理、发送交易、交易数据查询、进行节点之间通信等。BCOS接口sdk的设计分为两种，一种是面向区块链底层功能接口的调用，调用者需要知晓区块链节点的具体部署情况，进行异步通信和容错处理，在接口字段里填入经过特定编码的数据参数另一种sdk直接面向业务，提供业务级别的接口，业务开发者只需要关注业务数据的字段以及调用返回结果，不需要了解区块链节点的具体部署情况，不需要处理异步通信的细节。

（四）智能合约的可编写性

Fabric使用现有的容器技术来支持智能合约功能，Fabric的智能合约理论上可以用任何语言来编写（如Java、Go和Node.js），目前支持Go和Node.js，开发者将无需学习新的语言，并且可以复用现有的业务代码和丰富的开发库，并使用自己熟悉的开发工具。相对地，采用Docker的智能合约架构也有大量的问题：首先，它很难对智能合约的执行流程进行控制，从而无法对其功能进行限制；其次，它无法对合约运行所消耗的计算资源进行精确的评估；此外，运行Docker相对而言是极其耗费资源的操作，这就使得难以在移动设备上运行合约；最后，不同节点的硬件配置、合约引用的开发库等，都有可能会使合约的行为具有很强的不确定性。
BC0S合约开发支持Solidity语言，该语言作为Ethereum的主要合约开发语言，具有图灵完备的特性。BC0S平台计划在下一版本支持JVM虚拟机和Java开发语言。

平台适用性

都预留了身份、策略、数据、过程等应用模块，提供了区块链与链外系统对接的通道，如链外的物联网设备、支付设备、分布式云存储系统、交易系统的对接和外部用户身份的绑定等。
Fabric可广泛应用于跨行业应用场景中，可满足金融服务、供应链管理、智能制造、文化娱乐、医疗健康、社会公益、教育就业等领域的应用。
BCOS定位为企业级应用服务的区块链技术平台，其在多链、跨链、分布式存储及隐私保护等方面上的设计，满足其在金融、健康医疗、供应链、工业、物联网、能源服务等多个领域上的适用性。另外BCOS可支持账号管理、资产管理、交易管理、安全控制等模块功能的配置，因此对于各多种场景下所需的功能其均能很好地实现。

总结

Hyperledger Fabric的综合实力较强，起步早、框架完整且比较成熟，有国际化应用和国际化社区加持，但在实际的落地场景中，其部署不易上手，实现数据跨链共享较为复杂，性能不高。
FISCO BCOS是本土化设计的代表，其在底层研究上的投入、关键技术上的改进、对国内需要的适应性调整、对社区建设和运维的重视，都有可圈点之处，平台在各行业的通用性也在加强，并随着开源工作的推进和案例的不断增加，其本土化优势逐步显现。与Hyperledger Fabric相较，其设计更贴近商业需求，部署简单，效率较高，可扩展性较强，开发主体、资金投入的稳定性要更有优势。