在国家政策的鼓励下,区块链技术的研发与推广正在不断升温,技术、标准、平台、框架都在持续发展,这其中,既有来自国外的布道者,也有源自国内的探索者。做为区块链三大部署形态之一的联盟链,因其与现实场景的高度契合性,正在出现越来越多的落地实例。 为便于广大开发者、区块链爱好者了解联盟链中较为常见的两个开源设计,本文拟对Linux基金会的Hyperledger Fabric(以下简称Fabic)”和金链盟的“FISCO BCOS”进行简单的比较,权供大家参考。 一、理念:设计背景与发展路径的区别Fabric诞生略早于FISCO BCOS。IBM较早意识到了区块链技术中可能蕴含的商机,投入较大力量进行相关研究,并于 2015 年将其设计的 44000 余行源代码奉献给了Linux基金会的Hyperledger项目,再融合了R3 的一些设计思路后诞生了Fabric。 Fabric最初即被定义为跨行业应用,因此,它注重的是构建基于区块链技术的通用框架。而FISCO BCOS最初的定位是设计为自主可控的、适用于金融行业的开源区块链底层平台。虽然FISCO BCOS出身自带“人设”,但随着平台的发展,FISCO BCOS也逐渐支持了更多金融领域以外的场景,是从“一专”到“多能”的发展路线。 FISCO BCOS诞生于 2017 年,由金链盟推出,是标准的国产底层。金链盟是由深圳市金融科技协会、深圳前海微众银行、深证通等二十余家金融机构和科技企业于 2016 年 5 月 31 日共同发起成立的非营利性组织。 目前,Hyperledger的会员大约为 140 余个,包括金融业、制造业、科技业等,也说明了其跨行业性,成员中大约1/ 4 来自中国。 而金链盟成员超过 100 个机构,覆盖银行、基金、证券、保险、地方股权交易所、科技公司、学术机构等多个行业,成员几乎全部来自中国。因此,在设计监管接口时,FSICO BCOS更适合中国企业。 二、应用:带给开发者不同的设计思路Fabric做为一个通用设计框架,给出了比较完整的设计思路。其应用模型为MVC-B模式,MVC是软件设计中“模型-视图-控制器”设计模式,B即为区块链逻辑,包括链码(即智能合约)和交易,其含义即为以链码强化控制器,以交易强化模型,这是将区块链融入原有软件设计方式的指导。架构方面,Fabric给出的是成员管理服务、区块链服务、链码服务三大组成部分。可见,Fabric定义了一个基于区块链技术重新构建软件系统的架构方式,其用区块链彻底改变原有行业的良苦用心清晰可见。初次接触Fabric设计的人往往会试图用其建立起整个业务系统,笔者自己尝试过的业务设计也会顺着这种思路走,但是在实现中,通常会回到区块链系统与原业务系统结合的方式上。 FISCO BCOS架构中很实用的一个设计是“AMOP”协议,AMOP协议在金融机构之间的业务来往中可以提供灵活的互操作性,可以结合区块链来实现复杂的交易场景。比如:A机构和B机构之间进行某种商品交易的价格协商或者份额撮合,其间需要往复多次协商,最终双方商定结果后,再按此结果发起链上交易,写入账本并达成确认,此前的协商则不在账本中记录,通过AMOP实现加密的点对点通信。FSICO BCOS给出的架构设计参考为“A机构业务系统-A机构前置-区块链网络中A机构节点-区块链网络中B机构节点-B机构前置- B机构业务系统”,这可以明显看出两个业务系统即区块链系统、原业务系统之间的分工协作,也就是说FISCO BCOS的应用方式更多是希望参与区块链的各方将需要做公共实现的部分放在区块链上,而与原有的业务系统“和谐相处”。这其实与其最初定位于金融行业有关,金融行业普遍信息化程度较高,原有业务系统比较复杂,差异也大,轻易不会接受较大外来改造,因此,这种做“公约数”和“连接器”的思路更容易实现和推广。 业内普遍对区块链应用寄予较大希望的两种模式为:构建新的大型生态和改造现有的大型生态,而实现过程中,由于客观因素的限制,二者目前都没有出现突破。实际应用中,开发者可能还是要把握循序渐进的原则,从把区块链与现有系统结合做起,从改良到改变。 (责任编辑:admin) |