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服务。