Hyperledger Fabric 和 FISCO BCOS区别

	Hyperledger Fabric	FISCO BCOS
设计	继承IBM分布式体系设计	继承以太坊公链技术
框架	适用于不同领域的通用框架	通用框架、更适用于金融领域
隔离方式	通道隔离	群组隔离
隔离设计	支持多通道，单通道私有数据隔离	支持多群组，群组内数据隔离
智能合约环境	Docker环境	EVM环境
智能合约语音	Go、Java、Nodejs	Solidity智能合约语言
智能合约通用性	由于合约才有通用语音，合约执行存在不确定性，执行环境有存在差异的可能，所以不能保证合约计算的一致性和确定性	语音环境统一，通用性满足
智能合约可验证、可审计	部署合约分布由背书节点独自部署和运行，不在链上进行部署和共识，联系共识，存在节点误部署和修改代码的风险，无法通过区块链保证合约的不篡改，对验证和审计不够友好	链上部署、调用合约，合约代码保存在链上，可以对合约进行验证、审计
智能合约可追溯	通过交易追踪合约的激活和调用，但是合约代码变更不可追踪	通过交易追踪合约的部署、调用、更新
智能合约语音友好度	支持传统语音，易上手	多数场景实用solidity语言，已成熟，易上手
智能合约工具链	传统语音，工具链完善	基于solidity的工具链进行深度定制，工具链完善
智能合约部署	由背书节点通过Rocker分别部署，部署成本高	通过交易，方便部署，链上部署
智能合约调用	合约调用必须在同一个chaincode	合约之间可以方便调用
智能合约升级	背书节点分别去升级	通过部署新合约的方式进行升级
复杂合约	背书节点分别执行合约，并不对合约时间和复杂度进行限制	通过设置区块交易上限使区块链可以处理复杂度非常搞定合约
并行计算	不支持并行计算，交易依次执行。同一个区块不允许有冲突交易，否则后续交易失败	支持并行计算，但是需要在交易中预先设计冲突状态，场景有限且 使用难度比较高
指令扩展	传统语音，指令丰富，不需要扩展	通过预编译合约进行指令扩展
中心化共识	暂时不支持去中心化共识	支持去中心化共识
节点支持	支持少数节点	理论上节点不受限制
节点类型	背书节点、排序节点、提交节点三者共同参与共识	共识节点、只读节点、游离节点
节点扩展性	背书节点增删方便，排序节点增删方便，背书策略易修改，排序策略易修改	方便节点的删减
节点模块化	执行、排序、验证分离，节点功能可以根据情况组合	共识/执行耦合，不易替换和定制化
TPS	3400	20000
支持跨链方案	支持同构跨链方案	支持同构、异构跨链
权限管控	基于策略的权限控制	基于角色的权限控制，控制账号对表的操作
支持的执行共识	通过不同的角色实现共识，排序采用raft共识	pbft/raft/rpbft
执行共识	不同的背书策略安全性不同，既可以是安全性较高的背书节点和全部通过， 也可以是单一背书节点通过的策略	BFT类共识只要保证2/3+1个节点诚实， 既可正常出块，保证1/3个共识节点诚实既可保证结果正确
共识节点	通过配置文件进行管理排序节点管理，节点管理员通过发送交易激活新的配置文件，通过CA来认证	通过系统合约进行管理，节点管理员通过发送交易进行共识节点的增删
普通节点	通过配置文件来管理背书节点和提交节点，Channel管理员通过发送交易来激活新的配置文件，通过CA来认证。	通过白名单和黑名单管理链接，通过CA来判断节点是否为普通节点
交易排序上链	排序可以采用Raft或者solo共识，leader节点具有有较大权限可以拒绝交易	BFT类算法只要保证2/3+1个节点诚实既可保证交易会上链
交易状态一致性	排序和验证都不进行最终状态的共识，有提交节点来验证交易，并分布更新各自状态。只有等待下一个相关交易读取状态或者客户端主动查询，由客户端判断是否一致	BFT类共识只要保证2/3+1个节点诚实， 既可正常出块，保证1/3个共识节点诚实既可保证结果正确
区块存储方式	文件方式保存区块	MPT保存区块
存储数据库	Leveldb、CouchDB保存状态	MySQL、RocksDB保存状态
KV状态存储	支持KV数据，不保留历史不可追溯。支持CouchDB，不保留历史不可追溯，支持条件查询	支持两种模式：KV数据库，保留历史可追溯； SQL数据库，不保留历史数据不可追溯，支持条件查询。
国密支持	中国工作组计划支持，存在第三方技术支持	支持
开源协议	Apache-2.0	GPL3.0