Hyperledger Fabric 1.0架构初探

编辑文章

HyperLedger是Linux基金会下面的开源区块链项目,由IBM、Intel、GP Morgan以及其他一些金融公司与机构最早提出,其中HyperLedger Fabric(下文简称Fabric)最广为人知。Fabric1.0版本是一个提供分布式账本解决方案的平台,采用了模块化、可插拔的架构,具备很强的安全性、灵活性以及可扩展性,其基本架构、组件以及相应的流程,已经有很多文章介绍,最权威的信息来源,可以参考HyperLedger官方的架构参考文档。(hyperledger-fabric.readthedocs.io/en/latest/indel.html)。本文试图从原理层面分析一下Fabric的各种设计思路。

一、模块化信任设计

在《区块链:去信任的机器》一文中,我曾经提到:“区块链将传统的信任通过各种技术手段消解后,也带来一种架构性的自由,人们不再需要事事依赖于对于中心化系统的信任假设,被迫把业务逻辑、数据集中在一个信任点上,绑定到同一个信任主体来简化架构设计”,区块链网络中的节点无需实现所有的信任特性,而是可以根据需要,将不同的信任特性分散到不同的网络节点中来实现,这一点在Fabric模块化的设计方面体现的尤其明显。

上图是Fabric架构的一个演进过程。0.6除了通过Membership引入了许可概念之外,基本结构还是参考公链的设计,所有的功能都在peer节点中实现,作为一个开源账本平台,灵活性和扩展性没有得到充分考虑。1.0版本则对架构进行了重新设计,将智能合约的执行、TX的排序、出块功能、账本维护进行了模块化设计,使得联盟链有了自己的独特基因与设计方法论,不再是公链的简单模仿。

在公链设计中,我们更多的考虑的是完全的“去信任化”,即:所有的节点本性都是恶的、利己的,因而是不可信的,架构设计则充分利用这种利己主义的博弈,来产生确定性,降低对于特殊节点的信任(依赖),因此公链的设计往往都是以博弈为中心,架构是比较受限的。而联盟链,则适当放宽了对于“去信任化”的需求,引入了一些“信任化”的元素,来提供更高的性能与更强的灵活性。

上图是Fabric的交易流程,从中我们可以看出与公链完全不同的一种设计思路。

1、 业务逻辑的正确性:Client与EP(Endorsing peer)节点之间的背书流程该

流程可以视为传统的C/S模式的业务实现流程(流程1-3),按照传统的C/S处理逻辑,Client调用EP中的Chaincode(处理业务逻辑),产生事务日志,更新业务状态机,并返回结果给Client。

但由于Fabric是一个分布式处理系统,作为分布式处理系统的重要特征就是:事务并发、缺乏全局时钟,因此,如果按照传统的C/S流程来处理,直接更新业务状态机的话,各peer节点之间存在的并发事务,将导致不同peer之间的业务状态机一致性无法得到保证。Fabric选择的做法是,先产生事务日志,不更新业务状态机,将事务日志经过全局排序后,再去更新peer业务状态机。

EP节点实际上已经执行了业务处理逻辑,只是没有写入到最后的存储当中,因此,大多数的业务逻辑(智能合约)层面的工作,在Fabric的设计当中,第一步就已经完成了。完成的结果采用了一种Rset/Wset日志的方式,传递给后续的处理环节。在形式上,EP节点对处理后的结果进行签名,语义上,表达了一种对业务逻辑层面正确性的背书,这种背书,采用了一种比较灵活的正则表达式判决(Chaincode Policy)的方式,例如:择多判决。

这样设计带来的一个好处是并发性带来的性能提升,不同的EP节点集合,可以用来处理不同用户的、不同类型的事务,同时也可以灵活的设计业务处理逻辑,因为不同的事务对于安全性、性能的要求不尽相同。缺点是,确定性完全取决于Chaincode Policy,当这个Policy只有一个节点时,就蜕化成中心化模式了。

2、 节点之间的一致性:Client与Orders之间的排序流程(流程3-4)

经过背书的事务+事务日志,业务逻辑上的正确性已经得以保证,但不同peer之间的并发性问题并没有解决。通过Channel广播到Orders节点,通过共识算法进行排序,解决并发性问题。

联盟链很少采用“最终一致性”的共识算法,而是更多的采用“立即一致性”的共识算法。因为B2B商业需求,很少能够接受长时间的共识过程。

3、 事务之间的隔离性:CP(Committing pees)校验流程

Orders节点将并发事务进行排序,解决了全局时钟问题,但并没有解决事务的隔离性问题。CP节点负责将Orders节点排序过的块中的事务进行校验,执行VSCC逻辑进行处理,解决交易之间的隔离性问题,并广播到各Peer节点最终更新账本与业务状态机。

二、缺乏惩罚机制

相对于公链的惩罚机制(算力、抵押物等),联盟链的安全设计依靠身份许可机制来保证,这种身份许可机制所保证的确定性,一定程度上需要部分基于传统的信任与惩罚机制,另一方面,也可以利用具体应用场景中的天然博弈特性,例如:竞争对手之间往往难以形成同盟。当然实际应用时也模仿公链设计出某种惩罚机制。

三、HyperLedger不是区块链3.0

区块链3.0的概念来自《区块链:新经济蓝图》(《Blockchain:Blueprint for a new economy》,Melanie Swan)一书,其中把以比特币为代表的数字货币称为区块链1.0,把以太坊为代表的智能合约称为区块链2.0,而区块链3.0暂时没有代表,只有定义:除货币和金融领域外,在其他领域上区块链的应用,包括政府、健康、文化和艺术等等。

从Melanie Swan的定义可以看出,区块链1.0和2.0还是能看出一定的技术脉络的,例如:比特币主要引入了区块链这个技术概念,建立了简单的货币交易模型。以太坊则引入了智能合约的技术概念,建立了复杂的分布式对象执行环境。但区块链3.0的定义,明显与技术无关,仅仅是描述了一个商业愿景,个人觉得并非一个一致性的定义,如果让我来猜想区块链3.0,更多的倾向于区块链网络与区块链网络之间能够相互连接,建立起一个区块链世界。

无论是Melanie Swan的定义,还是我的猜想,Fabric跟区块链3.0八杆子打不着,Fabric仅仅是解决了B2B环境中区块链的应用模式问题。

因此,并非出现了一种新的区块链应用模式,就硬要往区块链3.0上去凑,如果纯粹从炒作区块链3.0概念角度看,EOS可能更加成功。

四、身份系统是联盟链的核心

联盟链区别于公链最核心的要素,就是引入了许可机制,即,只有获得认可的参与方,才能够参与到区块链网络中来,这种许可包含多方面,例如:发起事务、背书、共识、写入账本等等。许可可以是来自某个信任方的配置,也可以通过协商、投票来实现。

许可从整体语义上讲,就是带有一定的信任在里面的,如果任何人都可以不加选择的被许可进入联盟链,那就是公链了。当然,这种信任有大有小,取决于具体的业务场景与许可策略设计(例如:抵押物)。

细分开来看,许可本质上就是安全,核心就是实现AAA(Authentication、Authorization、Auditable):确定身份、设定权限、实现权限控制、追究责任。

相对于公链的匿名性,一般联盟链的参与方都是实名的,并且都会对应到现实世界中的某个实体或者法人,如果存在不诚实或者做恶行为的话,会在现实世界中收到一定的损失或者承担一定的风险,例如:法律、商誉等。

公链中一般由客户端自主产生公钥私钥对来确定自己的身份,这种身份是完全自主的、去中心化的。联盟链中的身份,一般是有特定来源的,或者中心化的,例如在B2B环境中,联盟链往往是现实世界的商业关系到区块链网络的一个映射,此时联盟链中的身份一般对应于商业组织的组织架构、员工、客户等,这些身份是受控的。Fabric中提供了一整套MSP+CA解决方案来提供联盟身份解决方法。

在B2B环境中,不同的实体本身在业务逻辑上,拥有的权限就是不同的,因此设计相应的业务权限也是必要的。一方面,在Endorsement过程中,peer在执行chaincode时,需要检查相应的Client权限,另一方面,在商业协作中,对于业务的隔离、数据的隐私性要求非常高,传统的C/S IT解决方案,对于Server端而言,这根本不是一个问题,但对于区块链这样一个去中心化的解决方案而言,问题就比较突出,需要在所有的peer节点实现相应的限制逻辑,Fabric引入了Channel的概念,实现不同业务(账本)之间的隔离与隐私保护,这也是一种权限许可。

五、PBFT不再是必选共识

在联盟链中,PBFT这种应对最差情况下的共识算法,不再是必须的,反而是对性能的需求更为强烈。因此,Fabric中,对orders服务引入了部分信任乃至完全信任的算法选项,支持的首选共识算法也变成solo/Kafka/sbft。

在sbft中,需要由一个信任的节点(Block Generator)来负责出块,一方面由于引入了可信的提案方,提升了算法性能,另一方面,也引入了中心化的趋势。需要注意的是,Sbft中的s不是simplified的意思,而是speculative的意思,参考论文地址:(http://sosp2007.org/papers/sosp052-kotla.pdf),用于实现zyzzyva共识机制。

相对于sbft,使用kafka共识,则更近一步在系统中引入了信任,系统必须完全信任kafka orders服务。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180905G1YRPI00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券