【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

联盟链战国:五大巨头横向对比

  • 2018-10-18
  • 本文字数:12610 字

    阅读完需:约 41 分钟

联盟链是目前区块链落地实践的热点,也是大家对“杀手级应用”期望最大的区块链部署形态。联盟链的诞生源于对区块链技术的“反思”,是对比特币、以太坊所体现的技术特点与企业客户实际需要的融合与折衷,蕴含了大量区块链工作者的智慧与辛劳。

由于对未来价值的“共识”,很多厂商推出了自己的联盟链框架或平台,本文选择了 Hyperledger Fabric、FISCO BCOS、微软的 Coco、企业以太坊联盟(EEA)及 R3 的 Corda 这五个具有一定影响力的联盟链,拟从设计理念、生态、效率、扩展性、节点管理与权限管理、智能合约、部署与运维友好性、隐私保护、公链结合或演化能力九个方面进行比对,以供各位开发者、爱好者参考。

其中,EEA 由于只出具规范而不涉及代码,所以比对中采用了其官方承认的技术基础——摩根大通的 Quorum 平台;Corda 并不是区块链,严格说与其他四者的比较属于分布式账本技术这个层级的比较,但是由于其承认设计上是受到区块链技术启发,且对其他联盟链也产生了一定的影响,因此,也列入了比较范围。本文的信息主要来源于公开的技术白皮书、Github 中的开源信息,就不在文中一一注明了。

一、设计理念

设计理念其实决定了一个框架或者系统的最佳应用方式,是其设计的出发点,因此,研究每种区块链时,都应当认真关注其如何“看待自己”,以免在应用上出现“硬套”的问题。设计理念上本文分成核心思路与市场定位两部分进行比较。

(一)核心思路

核心思路体现的是其设计初衷,这个“初心”对其后续技术走向有一定的影响。

  • Hyperledger Fabric 是希望改变公链的单一通用网络模式,通过建立多个可以互联的区块链网络覆盖各类不同的业务场景,实现设计的灵活性,满足多样化的要求,并实现网络间的交互,这种思路体现在了其独特的通道机制设计上。
  • FISCO BCOS 初衷是设计一个国内企业主导研发、自主可控、对外开源的满足金融行业需求企业级区块链底层平台,并逐渐扩展至其他领域、适用于广泛的分布式商业场景,所以进行了自底向上的完整设计,并考虑了较多国内的特殊需求。
  • Coco 基于保密联盟环境的假定,重新评估了公链的设计,通过将其他区块链协议集成为底层,快速高效地构建区块链应用。在这种思路下 Coco 大胆放松了一些关键的设计限制,并且最终实现了一个对现有区块链协议的加速机制,可集成的协议已经包括 Hyperledger Fabric、以太坊、Corda、Quorum 等。
  • EEA 是力求引导一种基于以太坊的标准区块链设计,可根据成员需要定制,但不提供代码(Quorum 提供部分开源代码)。官方承认其技术基础是摩根大通开发的 Quorum 平台,该平台的目标则是提供高速、高吞吐量交易的能力,以解决区块链技术在金融等领域遭遇的挑战。
  • Corda 希望提供一个具有唯一性、权威性、可以记录企业间所有协议的全局逻辑账本,核心是实现具有节点间最小信任机制的无中心数据库,因此,Corda 主张充分考虑与现有业务系统的结合,而非将现有业务系统拆掉重来。Corda 的设计思路对 Hyperledger Fabric 有一定影响,也参与了对后者的建设。

(二)市场定位

市场定位反映了对自身应用方向的价值主张。五个联盟链都是面向企业级应用的,但是具体的定位略有差异:

  • Hyperledger Fabric 旨在打造不分行业的通用区块链开源框架;
  • FISCO BCOS 源自企业级区块链平台 BCOS,做为一个金融版本分支,保留通用性的同时,更关注于金融行业,并且较多考虑了监管机构的特殊性;
  • Coco 希望提供更高效易用的区块链技术,没有特殊的行业定位;
  • EEA 比较有趣,它以将所有企业导向一个统一的路线图(该路线图以以太坊技术发展为基础)为目标,但是由于目前的技术代表是摩根大通的 Quorum,所以,应用实例上对金融行业更有指导性;
  • Corda 则是针对金融行业的,并且明确提出至少一定时间内不会考虑其他行业。

从设计理念的角度来讲,选用 Hyperledger Fabric 时,应当善用其通道机制,通过通道机制降低业务或者环境的复杂度,但是要注意其跨通道能力的一些技术限制;FISCO BCOS 则应关注其对国内市场特殊需求的适应性设计,这些设计会带来很多部署上的优势;Coco 和 EEA(Quorum)设计理念上都属于基于现有协议的优化加速机制,只是前者“博爱”,兼容的协议更多,后者“专一”,只针对以太坊;选用 Corda 则要先明确,它不是区块链,不要带着区块链的价值假定去应用。

二、生态

大家常说建联盟链就是建生态,所以本文就比较下要帮着别人建生态的联盟链,其自身的生态建的如何。生态考察主要包括管理方、社区和商业应用这三个方面。

(一)管理方

从管理方看,各家都是“实力派”。

  • Hyperledger Fabric 的管理方是 Linux 基金会,基金会管理下的 Hyperledger 其实是一个项目系列,包括 Cello、Swatooth、Burrow、Iroha 等;
  • FISCO BCOS 管理方是金链盟,金链盟是由深圳市金融科技协会、深圳前海微众银行、深证通、腾讯、华为、中科院等金融机构、科技企业、学术机构等组成的非营利性组织;(参考 https://www.fisco.com.cn/views/member.html)
  • Coco 的管理方是微软;
  • EEA 是由芝加哥交易所、因特尔、ING、摩根大通和微软等三十几家创始成员组成的;
  • Corda 的管理方 R3 是以银行为主的组织,至少已经吸收了 42 家金融巨头,包括富国银行、美国银行、花旗银行、德意志银行、加拿大皇家银行等,我国的平安、招行等也是其成员,不过 R3 麻烦不断,也有些重量级成员已经退出。

(二)社区

现今科技发展比较流行开源,五大联盟链也都是开源的,开源意味着要搞好社区建设,通过社区推广和改进设计,凝聚更多智慧。

  • Hyperledger Fabric 已经打造了国际化的社区,除了在 GitHub 上比较活跃外,大量的线下 Meetup、技术推广活动也比较多,加上 IBM 的有力推动,使其有了大量的活跃用户;
  • FISCO BCOS 社区建设初现规模,已有了千级成员、百级机构参与,除了 GitHub 外,还有官方微信群。FISCO BCOS 在不断迭代源码和文档的基础上,陆续推出了线上线下多种形式的系列运营活动,包括技术培训、高校开课、线上线下讲座沙龙、包括近期举办的金链盟中国区块链大赛,影响力逐渐扩散。作为国内开源项目,相信未来发展上会有一定的“天时地利人和”;
  • Coco 社区不是很活跃;
  • Quorum 在 GitHub 上已经有了 551 个话题,有一定活跃度;
  • Corda 也不是很活跃。

(三)商业应用

商业应用是大家打造区块链平台的目的,也是一个联盟链最重要的人气所在。

  • Hyperledger Fabric 得益于 IBM 的大力推广,加上技术框架比较成熟、推出较早,目前已有较多商业应用,据 IBM 披露有 400 多个落地项目,其中不乏马士基、沃尔玛、联想、邮储银行这类大型客户,也有统计称,所有联盟链项目中 Hyperledger Fabric 已占据半壁江山;
  • FISCO BCOS 从金融出发,携本土优势,落地项目也有数十个,包括微众银行的机构间对账平台、网易的竞猜游戏,四方精创的供应链金融、城商行旅游金融联盟的旅游金融、仲裁链、安妮股份的版权存证平台、乐寻坊的人才活动平台、链动时代的不动产登记系统等;
  • Coco 目前在项目方面乏善可陈,除了其白皮书中提到的 Mojix 将其供应链 Dapp 转移到 Coco 平台上之外,没有更多公开的项目信息;
  • Quorum 上,比较有影响的应该算是 2017 年 10 月摩根大通开发的 IIN(Interbank Information Network)平台,实现跨行信息交互,摩根大通、加拿大皇家银行、澳大利亚 ANZ 银行、新西兰银行等相继加入该平台;
  • Corda 也是同样的境地,雷大雨小,耗费巨资,但是测试的多,落地的少。

从生态角度看,Hyperledger Fabric 启动的比较早,目前领先一步,但是 FISCO BCOS 奋起直追,已经初见规模,Coco、Quorum、Corda 还需要做很大努力。

三、效率

区块链目前最差强人意的指标莫过于效率,虽然现在也有些人开始反思也许不应当苛求区块链的效率,但是商业应用总是回避不了这个问题。效率方面,本文从共识协议、出块速度、TPS 和存储消耗这四点加以比对。

(一)共识协议

联盟链为了提升交易速度,往往是先从共识协议“下手”。POW 和 POS 都无法满足商业应用的需要,“挖矿”对联盟链来讲也是没必要的,因此,各家都采用了替代的共识方案。

  • Hyperledger Fabric 在 0.6 版中应用了 PBFT,而在 1.0 版中放弃了 PBFT,转而采用效率更高的 Kafka,支持单点和集群两种方式,由 Kafka 直接给交易排序和出块。
  • FISCO BCOS 支持并行计算的 PBFT 和标准 RAFT 两种方式,前者是将通常的 PBFT 中议长节点和投票节点分步验证的方式优化为并发验证,从而进一步提高共识效率;
  • Coco 支持 Paxos 和 Caesar 两种协议。由于 Coco 节点是建立在基于硬件的 TEEs(可信执行环境)上,因此就假定了节点充分可信,所以在 Paxos 中,leader 节点处理过的事务,follwer 节点简单跟随即可,这体现了其对公链假定的改变;Caesar 支持灵活的容错模型,可以与 Paxos 共同使用以防范 leader 节点由于 TEEs 遭到破坏产生的安全威胁,该协议支持在 follwer 节点发现 leader 节点不可靠时将其驱逐,从而保证全网的安全;
  • Quorum 支持 Raft 和 Istanbul BFT 两种协议。后者是由来自台湾的 AMIS 帐联网公司在 2017 年研发的,可以大幅提升现有的以太坊架构的讯息交换效率;
  • Corda 比较特殊,它借鉴“矿工”角色设计了公证人模块来提供交易公证(也即签名)服务,整个网络不依赖于任何特定的共识算法。但公证人是一个集群概念,一般使用 BFT 或 Raft 在公证人间达成一致,因此,公证人是存在效率问题,可能成为效率瓶颈;

与传统分布式系统的共识设计相比,Hyperledger Fabric 并没有什么改进,其共识方式与中心化共识的分布式数据库一致;FISCO BCOS 支持 PBFT 共识算法,具备拜占庭容错功能,也提供 RAFT 共识算法,适用于在节点可信度比较乐观的场景;Coco 是通过 TEEs 提高节点可信性,以降低共识协议的复杂度;Quorum 也没做多少调整,尤其是在引入 Istanbul BFT 之前;Corda 应该说是在传统设计中引入了“矿工”理念。

(二)出块速度

由于替换了共识机制,因此相比使用 POW 的比特币、以太坊,联盟链出块速度要提高很多。Hyperledger Fabric、FISCO BCOS、Coco 都是秒级出块;Quorum 则称是毫秒级,默认设定是 50 毫秒,可以调整;Corda 没有块,所以也没有出块速度可以考量。

(三)TPS

TPS 相当于区块链世界中的“网红”,很多新出现的链都把 TPS 贴在“脑门”上。这五大联盟链虽然 TPS 远高于比特币、以太坊,但还是比现有的分布式系统逊色:

  • Hyperledger Fabric 通常实测的 TPS 在 300-500 之间;
  • FISCO BCOS 实测单链可以达到 1000 以上。并且支持多链架构下的并行计算,可灵活扩展,理论上无上限。
  • Coco 官方数据是 1600;
  • Quorum 在 Istanbul BFT 协议下可以达到 400-800,Raft 下缺少数据;
  • Corda 由于其网络结构的原因,没有全局吞吐量可以衡量。

其实 TPS 方面如果没有达到一个数量级以上的差异,是不用特殊关注的,因为在实际应用中,节点数量、网络环境、硬件配置、软件设计等都会对 TPS 产生影响,而现有的联盟链在吞吐量上已经可以满足相当一部分商业场景的要求,毕竟 Visa 在 2016 年每秒实际处理的交易也只有 1,667 笔,尽管 Visanet 据称有每秒处理 56,000 笔交易的能力。

(四)存储消耗

区块链可以说是以“浪费”存储来换取信任的技术。虽然存储设备的价格越来越低廉,但这不代表“浪费”就没毛病,存储的快速膨胀一定会带来效率、成本、可用性等诸多问题,甚至会要求改变设计架构,尤其是在大家都想追求“杀手级应用”的时候。

  • Hyperledger Fabric 方面,蚂蚁金服倒是给出了一个详细的计算公式,Fabric 数据容量估算(GB) = 每种业务每天平均交易笔数 x (Fabric 每笔交易基本开销 + 每笔交易平均业务数据大小 KB x 2 ) x 业务 Channel 数量 x(365 x 年数 x(Peer 节点数量 x 2~1 之间 + Orderer 节点数量)+ Kafka Retention 天数 x Kafka Replica 数量) / (1024 x 1024),其计算示例中,在业务笔数每天 10 万、4 节点、2 通道、单笔交易容量 1K 的情况(其他因素不详细列出了)下,年存储消耗 4619G;
  • FISCO BCOS 支持历史数据快速追踪,对接数据库,实现分布式存储,能够支持海量服务的存储需求,提高存储访问速率,节省存储消耗。
  • Coco 由于设计上需要集成区块链协议做底层,因此其消耗就取决于集成的区块链协议,比如集成了 Hyperledger Fabric,那加上 Coco 自身的消耗,其存储消耗量至少应该是比肩 Fabric 的;
  • Quorum 也没有针对存储的特殊优化,至少应当按照大于以太坊消耗来估算;
  • Corda 倒是不同于其他联盟链,因为它基本上就是传统的分布式数据库,而且没有任何节点保存全局数据,每个节点都只保存跟自己有关的数据,所以,其存储消耗应该与传统分布式系统设计类似,没有过多的冗余消耗。

综上,从效率方面看,在 Hyperledger Fabric 之后推出或开源的其他联盟链,效率高于它也属正常。FISCO BCOS、Quorum 本就是面向金融的设计,所以效率要求自然要高于一开始就希望做通用框架 Hyperledger Fabric;Coco 设计理念上就是希望做成“加速器”的,它的效率理应高于任何它可以集成的区块链;而 Corda 的设计模式决定了很难全面评价其效率,只能去单独观察每个实例。

四、扩展性

联盟链的用户都希望自己能发展成生态圈,比如海尔的供应链、中化的原油进出口贸易平台、马士基的全球交易平台等,因此,扩展性是联盟链设计必须要考虑的问题。这方面本文关注了节点数量扩展、共识扩展、单多链模式、加密算法扩展、第三方认证证书支持这五点。

(一)节点数量扩展

  • Hyperledger Fabric 在节点数量扩展方面是弱项,已落地项目多是个位数节点,但是可以支持较多的客户端,算是一种弥补,不过节点数少其实意味着参与方的独立性是会有所下降的;
  • FISCO BCOS 的分组模式支持根据节点数量进行水平扩容,因此理论上节点数量是不受限制的;
  • Coco 在这方面有些“投机取巧”,可支持的节点数量取决于其集成的区块链协议,如果集成的是公链协议,在理论上也不受限制;
  • Quorum 是基于以太坊的,因此理论上也没有限制;
  • Corda 同样也没有节点数限制。

虽然除了 Hyperledger Fabric,其他联盟链似乎都没有节点数量问题,但是节点数量其实还受共识协议的影响,BFT 类共识协议在节点数量超过一定水平时会出现吞吐量下降,设计时应当考虑这点。

(二)共识协议扩展

共识协议的扩展能力对联盟链的稳定性有很大影响,能否根据节点数量、网络平衡情况、吞吐量进行调整决定了其网络的扩展能力。

  • Hyperledger Fabric 虽然很早在设计上就称其共识模块可插拔,但是目前实际应用上看是不具备插拔能力的,每个版本仅支持一种共识模式;
  • FISCO BCOS 支持共识协议的插件式实现,允许切换共识机制;
  • Coco、Quorum 目前也具备了这种能力;
  • Corda 实现的应该说不是共识协议的直接插拔,而是公证人模块的可插拔,可以通过切换公证人模块来选择公证人的共识模式。

(三)单多链模式

多链模式目前被很多新出现的链用于性能扩展,不过多链模式有利有弊,提升性能的同时也增加了设计复杂度。

  • Hyperledger Fabric 的通道机制其实可以算是早期的多链设计,但是通道在 Hyperledger Fabric 中并不是出于提升效率的目的设计的,而是为了满足业务多样性要求,以降低业务复杂度,因此,通道机制目前在性能扩展方面没有显著贡献;
  • FISCO BCOS 是明确的并行计算多链设计,设计上要求开发者尽可能保持多链的同构特征以减少冲突,多链设计被直接应用在系统扩展方面;
  • Coco 的模式仍然取决于其集成的区块链协议;
  • Quorum 是单链模式的,底层的性能扩展要跟随以太坊的技术路线,可能要依赖以太坊的分片等技术进行扩展;
  • Corda 设计上是多网络模式,没有单多链的概念,但是可以建立两个网络节点的双向连接,配置双方信任的公正和认证机构进行网络融合,融合算是其扩展的一种方式。

(四)加密算法扩展

对于国内的应用,加密算法的扩展也即国密替换是一个强烈需求,尤其是在金融领域。

  • Hyperledger Fabric 不支持国密替换,目前已有的应用凡实现国密的基本上是自行替换或者依赖第三方服务;
  • FISCO BCOS 是支持国密的;
  • Coco 未对加密算法的选择有明确说明,因为这对 Coco 而言属于底层,取决于其集成区块链协议,但目前它所集成的协议中还没有支持国密的;
  • Quorum、Corda 都没有对国密的支持方案。

(五)第三方认证证书支持

这一点对国内的应用也很重要。

  • Hyperledger Fabric 目前不支持第三方 CA;
  • FISCO BCOS  支持第三方证书,支持证书的撤销,支持多 CA;
  • Coco 由于私钥都保管在本地业务系统且允许自己生成,网络上只存公钥集,因此技术上看应该可以支持第三方 CA;
  • Quorum、Corda 都未见有此类支持。

综上,Hyperledger Fabric 在扩展性上有一定的限制; FISCO BCOS 的可扩展性是很有优势的,尤其是面向国内应用时;Coco 扩展性取决于其集成的协议;Quorum 的扩展性与以太坊关系密切;Corda 除了在加密算法和第三方认证证书方面外,扩展的自由度有可能是最高的。

五、节点管理与权限管理

除了共识之外,联盟链与公链的显著区别当属在节点和权限上的设计了。本文从节点类型、作用、成员准入控制、角色和权限管理这几个方面比较下各联盟链之间的差异。

(一)节点类型

  • Hyperledger Fabric 网络中的节点主要分为排序节点、背书节点和记账节点三类,实际应用中还可以加入只有同步账本能力的二级节点;
  • FISCO BCOS 中包含核心节点、全节点、轻节点;
  • Coco 是一个可信验证节点(VN)分布式网络,也即,它只有一类节点就是 VN;
  • Quorum 中的节点是基于的以太坊 Golang 版本实现的,因此节点之间是对等的,没有节点类型的区分,节点之间可以有白名单管理;
  • Corda 也不区分节点类型。

(二)节点作用

  • Hyperledger Fabric 网络中背书节点负责提供签名服务,经背书节点签名且满足签名策略的交易提案会提交给排序节点进行交易排序和出块,再由记账节点完成账本更新;
  • FISCO BCOS 中核心节点负责共识和记账,共识节点参与记账共识, 观察节点同步账本;
  • Coco、Quorum、Corda 中节点都是对等的。

(三)准入控制

  • Hyperledger Fabric 中有专门的 CA 模块提供用户信息注册、数字证书发行、延期和吊销等服务,成员管理采用 MSP 方式,同一个组织内的成员通过共用同一个 MSP 标识进行识别;
  • FISCO BCOS 中,成员加入网络采用管理员认证的方式,提供合法有效的成员信息与 CA 证书,由管理员审核通过后,加入网络;
  • Coco 网络中的角色分为成员和参与者两种,成员是网络的集体管理者,拥有投票权,投票决定其他机构的加入或删除;
  • Quorum 网络中节点通过授权才能加入网络,授权是集中式的,通过 Java 控制台操作;
  • Corda 中节点也是需要授权加入的,节点选择加入一个或多个网络地图,网络地图相当于网络成员及其地址列表,节点只能与所在地图中的成员进行交易。

(四)角色

  • Hyperledger Fabric 中虽然成员没有明确的角色划分,但是基于其运维或对应的节点的差异会自然形成不同的角色;
  • FISCO BCOS 网络中的角色包含超级管理员、链或权限管理员、运维、交易、监管等;
  • Coco 网络中的角色分为成员和参与者两种,但不是必须同时具有两类参加者,也可以只有成员类型;
  • Quorum 网络中没有角色的区分;
  • Corda 网络中的角色分为公证人和参与者两种,公证人提供公证服务,参与者进行交易。

(五)权限管理

  • Hyperledger Fabric 中权限主要通过策略进行管理,策略实际上是成员通过节点进行某种操作,比如提交交易提案等,所需要满足的签名数量要求。
  • FISCO BCOS 权限管理采用系统合约的方式,并可以通过自定义合约的方式进行权限管理功能的扩展,权限管理模型为 ARPI(账户——角色——权限——接口)模式,多个账户可以对应同一个角色,角色有明确的权限列表,每个权限对应一个接口,接口指向智能合约,权限列表按照系统合约方式维护。业务中的权限管理则采用交易权限链的方式,一个交易相当于一组权限链,包含多个 Filter,交易处理是逐个 Filter 进行权限判断,一个交易完成相当于一组 Filter 审核都通过。
  • Coco 网络有成员负责治理,参与者是没有投票权的,不能参加网络管理。成员和参与者都可以拥有 VN。成员对网络的管理通过共同维护一个可编程的网络章程来进行,章程内容至少包括成员列表、VN 列表、代码清单、TEE 清单和投票策略。
  • Quorum、Corda 没有明显的权限管理内容。

综合比较,FISCO BCOS 的设计比较周全,也有一定的复杂性,但这也意味着它能够支持更复杂的场景; Hyperledger Fabric 、Coco 带有一定中心化因素;相较之下,Quorum、Corda 更接近公链思路。带有中心化因素本就是联盟链对其应用的商业环境的体现,这也无可厚非。

六、智能合约

为了提升效率,支持更加友好的设计,各联盟链在智能合约上也出现了不同的发展思路。

  • Hyperledger Fabric 中的智能合约称为“链码”。链码分为系统链码和普通链码,前者包括生命周期管理、配置管理等,属于系统控制层面的链码;普通链码则是用于实现业务逻辑的链码,智能合约开发通常指的就是这部分链码。链码的业务模型为“MCV-B”,即,在传统的 MVC(模型、控制器、视图)模式中嵌入 B(区块链),强调链码是业务逻辑的加强。链码的生命周期包括打包、安装、实例化、升级、停止和启动,运行在 Docker 中,由背书节点进行调用,目前主要支持的是 Go 语言。Hyperledger Fabric 虽然提供了跨通道机制,允许跨通道调用链码,但是跨通道调用只支持读而不支持写。
  • FISCO BCOS 中除了通常用于业务逻辑的智能合约外,将系统管理也智能合约化了,统称为系统合约,包含系统代理、节点管理、机构证书、权限管理、全网配置五类。上述合约原则上由区块链管理员在网络启动时部署,网络运行期间的变更则需要在去全网所有节点许可的情况下由管理员操作。FISCO BCOS 主要支持 EVM 引擎的智能合约。
  • Coco 由于其节点运行在可信执行环境中,因此,与其他联盟链不同的是智能合约只需单个节点运行,不必多次验证。更与众不同的是,因为可以单点只运行一次,所以 Coco 的智能合约支持不确定交易。此外,允许智能合约直接连接外部可信数据源。
  • Quorum 是基于以太坊智能合约的,智能合约本身没有特别之处,合约运行结果方面,节点只对公开交易和节点涉及的私有交易进行验证,而不必验证所有交易。
  • Corda 的智能合约设计思路也比较独特,首先,它主张智能合约的业务数据和业务逻辑要能关联到明确的法律依据上,这相当于要智能合约跟业务凭证之间具有强联系;其次,Corda 主张纯函数式设计,力推金融合约的标准化,提供小型类库,以减少对低层次逻辑的重新开发;再次,单纯看智能合约的话,Corda 的智能合约是“碎片化”的小段程序,而且只能做为起流转控制作用的“验证程序”,做不到一般智能合约那种价值转移功能,在 Corda 中,“交易”、“智能合约”和“流式架构”加起来才能与其他平台的智能合约相当。

总结一下,Hyperledger Fabric 的链码设计给了智能合约一个新的设计框架,这方面它是开创性的;FISCO BCOS 则将智能合约应用扩展到了系统管理方面;Coco 采取了改变公链设计假定的思路,不仅不对智能合约进行重复验证,还支持不确定交易;Quorum 的智能合约基本沿袭公链思路;Corda 的思路也比较另类,但是智能合约本身却更弱化了。

智能合约是随着以太坊火起来的,成了区块链的标志性技术,但其实目前的智能合约还远不够“智能”,这个名字容易引起误解。以太坊创始人 Vitalik 最近在推特上发文称对使用智能合约这个术语表示“十分遗憾”,应该使用更专业或更无聊的名字,比如,“持续的脚本”之类的东西,想来也有此意。

七、部署与运维友好性

联盟链常被称为是个“坑”,这个“坑”主要是在部署和运维方面。

(一)部署

  • Hyperledger Fabric 虽然已经是个成熟框架了,有良好的社区环境,市面上还有若干不错的教材,但是部署方面依然让很多新人不知就里,笔者所在的微信群里大部分时间都在交流部署问题而非设计问题;
  • FISCO BCOS 提供一键安装 /step-by-step/docker 等搭链方式,同时还未企业生产部署提供物料包的打包工具,简化部署复杂度;
  • Coco 的部署特点是增加了一次对其他区块链协议的集成,要先有底层区块链协议,才能部署 Coco,这其实要设计人员对 Coco 和其集成的区块链协议都有一定了解才好,学习成本较大,此外,Coco 需要部署 TEE 硬件设备来支持可信执行环境构建,这是其他联盟链通常不需要的,TEE 因此也成为一个安全隐患;
  • Quorum 需要在以太坊之上部署,依赖以太坊,与 Coco 相同,设计人员最好也要了解以太坊;
  • Corda 的部署目前缺乏实例来做比较。

(二)运维

  • Fabric 目前没有提供多少支持工具,多数需要设计者自己开发;
  • FISCO BCOS 提供了方便运维的合约命名服务,提供区块链浏览器和监控,并且有上帝模式用于处理节点崩溃问题,运维友好度有一定改善;
  • Coco 目前未见提供多少运维工具;
  • Quorum 有一些第三方支持工具;
  • Corda 与其他联盟链相比,运维方面最大的特色莫过于支持受限形式的数据库回滚。

联盟链的部署和运维都有一定的学习曲线,其复杂度远高于公链,一个新手部署一条以太坊要不了多少时间,但是运转起一个联盟链,还是需要打听不少“小伙伴”的。

八、隐私保护

联盟链有一个让大家纠结的问题是,明明要上链一起共建生态、共享信息,却纷纷要求隐私保护,要上链又不能随意公开,不仅希望身份保密,还希望交易信息保密,这与公链信息公开、身份保密的设计理念有很大不同,但这是合理要求,尤其是在金融领域。本文从可见范围、加密措施两方面对各链加以比较。

(一)可见范围

  • Hyperledger Fabric 的通道可以用来隔离数据,只有在同一通道内的节点才可以共享同一套账本信息,而通过组织设计,基于 MSP 标识可以在同一通道内进一步控制数据可见范围,1.2 版中加入了私有数据模式,允许指定的节点间共享信息,这比组织更加灵活;
  • FISCO BCOS 设计了 AMOP 协议,以提供机构间的点对点通信,通信信息属于链下信息,不在全网共享,链上部分在引入中央对手方提供信用背书的情况下,数据也仅在交易方和中央对手方之间共享,多链方式也可用于数据隔离,必要时通过跨连互通;
  • Coco 支持两个或多个交易者的机密交易,通过 TEE 控制可见性,但要求集成的区块链协议最好也提供一定支持;
  • Quorum 区分公开数据和私有数据,私有数据只允许限定的交易方可见;
  • Corda 数据仅在交易方之间可见,节点之间提供一个交易依赖关系图,数据根据需要发送,而不在全局广播,任何参与方都无法见到包含全部数据的全局账本。

(二)加密措施

  • Hyperledger Fabric 1.1 开始支持账本数据加密,1.2 版引入私有数据后,设计上允许只给 Kafka 提供交易 Hash 用于排序而不向 Kafka 提供交易信息,以防排序节点泄露数据;
  • FISCO BCOS 允许采用高强度的加密数据信封进行保护,未参与交易的机构只能接收到密文,此外,建议对敏感数据采用脱敏上链、Hash 上链等方式进行保密处理;支持零知识证明,环签名,群签名,同态加密等隐私保护方法。
  • Coco 允许应用程序先进行数据加密再提交事务,公网数据采用加密传播的方式,以对不受信任的 host 保密;
  • Quorum 有独立的 Constellation 模块,对私有事务的交易数据进行加密保护,还提供了独立的零知识证明(ZSL)模块以防止验证用户身份时发生信息泄露;
  • Corda 也使用 enclave 进行数据保护,并考虑使用安全硬件。

在隐私保护上,各链都下了很大力气,这方面与其一较短长,不如考虑互相借鉴。

九、选型建议

通过以上八个方面,本文粗略比较了五大联盟链的设计与差异,如果非要从技术角度给各家打个分、排个名,实在有些“霸王硬上弓”之嫌,各家原本思路和焦点就不同,都有自己的“小目标”,非要不管人家自己的想法去论个短长,有些不太“科学”,也不是应用的合理“姿势”。各联盟链毕竟都是为了解决实际问题、为了落地区块链项目而设计的,所以,本文最后从大家都会关心的技术选型角度做个总结。

整体而言,Hyperledger Fabric 的综合实力依然最强,推出时间早、框架完整且比较成熟,有国际化应用和国际化社区加持,案例和技术支持对于仍属早期发展阶段的区块链而言非常重要,Hyperledger Fabric 在这方面可以说优势极大。但是,它也有些不能回避的问题,比如基础研发进展缓慢,研发主体不明确,一些应用者关心的关键问题迟迟不见解决。随着百度、阿里、腾讯、京东等一众国内大厂的强势加入,Hyperledger Fabric 的优势地位也会受到越来越多的挑战,对此,它急需合适的应对措施。

FISCO BCOS 应该说是本土化设计的代表,其在底层研究上的投入、关键技术上的改进、对国内需要的适应性调整、对社区建设和运维的重视,都有可圈点之处,平台在各行业的通用性也在加强,随着开源工作的推进和案例的不断增加,其本土化优势会逐步显现。在国家政策的鼓励下,国内大厂如今纷纷高调杀入联盟链市场,如果这些大厂真的“倾情”加入,那与 Hyperledger Fabric 相较,其开发主体、资金投入的稳定性要更有优势,而且,大厂们基本自带生态和流量,案例的增长、生态的发展也是可以预期的,是很多项目可以借力之处。

Coco、Quorum、Corda 都存在支持能力不足、缺乏有效案例的问题,虽然微软目前在 Coco 以及其他基于 Azure 的区块链平台和应用上投入了一定力量,但是对国内应用者而言,仍显不足。

因此,从技术选型角度来讲,应用者,尤其是新入局的应用者,最好还是在 Hyperledger Fabric 这种影响广泛的成熟框架或者 FISCO BCOS 这种有实力且能提供较强本土支持的平台上做选择,而在开发过程中借鉴下 Coco、Quorum、Corda 中的优秀设计理念。

区块链仍属于技术的早期阶段,这个阶段必然要求应用者具备较强的学习能力,多做基础研究,敢于对所选择的技术平台进行改良,积极与平台提供商合作进行技术探索,区块链还没到像主流操作系统那样可以“坐享其成”的阶段,仍然需要所有参与者秉持“开源”思想,不辞辛苦、热情奉献、共同进步。

作者按:文章大部分是晚上写的,是“夜话”;挑来选去,最后写了五个链,想起了“春秋”。春秋之后是战国,估计是随着 BATJ 积极加入后的战国。“天下大势,合久必分,分久必合”,联盟链乃至区块链会否如此,可能要“久”到下一代技术来决定了。近期有文章称当前的基础研究越来越难以支撑技术的创新发展了,区块链也有此忧虑。作为早期形态,刻意“浪费”算力和存储换取信任,可以;作为未来的成熟形态,不妥。五大联盟链中也有对此问题的些许思考,但现有方案乃是当下之技术或认知所能达到的较高水平了。今日“链人”之努力乃是前进的必经之路,足以启发天下之想象。没有今日的“痛苦”,就没有未来理想的区块链世界,愿大家广发宏愿,持续努力。

彩蛋:作者已对本文整理成图表,有需要的伙伴请关注微信公众号“区块链前哨”,回复“金链盟大赛”即可获取。

金链盟中国区块链大赛已开赛,有兴趣报名的伙伴请【阅读原文】了解。

作者介绍

付晓岩,原中国建设银行资深业务架构师,负责业务架构设计、项目管理,热衷新技术探索与实践,具有丰富的银行业务经验和企业级项目业务架构设计经验。2000 年加入建行,曾长期参加建行“新一代核心业务系统”建设,主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。从 2017 年开始探索区块链技术及其应用,并发表《关于使用区块链技术建设行业级同业交易平台的探讨》、《数字货币可能诱发的现金社会经济活动的模拟与思考》等多篇文章。

2018-10-18 21:415088
用户头像
钰湚—付晓岩 企业架构理论研究者,业务架构设计倡导者

发布了 73 篇内容, 共 56.4 次阅读, 收获喜欢 427 次。

关注

评论 1 条评论

发布
暂无评论
发现更多内容

华创视讯加入龙蜥社区,携手共建开源新生态

OpenAnolis小助手

开源 龙蜥社区 CLA 华创视讯 龙腾计划

开发板上新抢先知!居然可以用来跑游戏?

HarmonyOS开发者

开发板 HarmonyOS

建木持续集成平台v2.3.1发布

Jianmu

开源 DevOps 自动化 持续集成 gitops

Consul的基本使用与集群搭建

神农写代码

网站开发进阶(三十六)String.getBytes()方法中的中文编码问题解决总结

No Silver Bullet

编码 5月月更 getBytes

用上这个 Mock 神器,让你的开发爽上天!

Liam

前端 前端开发 Postman Mock Mock 服务

去哪儿网MySQL日志分析实践,80%数据丢失都给你救回来!

Qunar技术沙龙

dba

第1章-Spring的模块与应用场景

码匠

Java Spring Framework

购买自助洗车机时都要注意哪些

共享电单车厂家

自助洗车机多少钱 自助洗车机价格 自助洗车加盟 购买自助洗车机

开家自助洗车房需要投资多少钱

共享电单车厂家

自助洗车加盟 开自助洗车店多少钱 开家自助洗车房

实践GoF的23种设计模式:建造者模式

华为云开发者联盟

Go 设计模式 GoF 建造者模式

自助洗车加盟都要注意哪些事项

共享电单车厂家

自助洗车加盟 自助洗车机厂家 自助洗车品牌

文章插图汇总

武师叔

Redis命令HSCAN踩坑指南

Qunar技术沙龙

dba

区块链系统开发,交易所交易平台搭建

Geek_56201b

龙蜥正式开源 SysOM:百万级实战经验打造!一站式运维管理平台 | 龙蜥技术

OpenAnolis小助手

开源 操作系统 龙蜥社区 SysOM 系统运维SIG

墨天轮最受DBA欢迎的数据库技术文档-SQL优化篇

墨天轮

MySQL 数据库 oracle postgresql

从活动能力层建设看业务架构

Qunar技术沙龙

业务架构

加盟自助洗车需要营业执照吗

共享电单车厂家

自助洗车加盟 加盟自助洗车

技术干货| MongoDB如何查询Null或不存在的字段?

MongoDB中文社区

mongodb

gRPC服务开发和接口测试初探【Go】

FunTester

Hadoop hdfs 的shell操作

Emperor_LawD

hadoop Shell 5月月更

疫情时代如何提高办公效率?

小炮

解决方案| 阿里云数据库MongoDB版助力餐道显著提升运维效率,打造卓越餐饮/零售服务

MongoDB中文社区

mongodb

一个小操作,SQL查询速度翻了1000倍。

TiDB 社区干货传送门

行业案例| MongoDB在腾讯零售优码中的应用

MongoDB中文社区

mongodb

基调听云研发总监杨金全出席CSDN可观测性与APM峰会

基调听云

云原生 APM 可观测性 基调听云

TiKV 缩容不掉如何解决?

TiDB 社区干货传送门

给大家科普下如何加盟自助洗车

共享电单车厂家

自助洗车加盟 自助洗车怎么加盟 如何加盟自助洗车

网站开发进阶(三十三)中文字符编码问题解决总结

No Silver Bullet

异常 5月月更 中文编码

【国产免费】分布式作业批处理ETL平台TASKCTL变量属性设置

TASKCTL

大数据 DevOps 分布式 自动化运维 TASKCTL

联盟链战国:五大巨头横向对比_语言 & 开发_钰湚—付晓岩_InfoQ精选文章