接触区块链的童鞋都知道比特币或者说以太坊,但是了解超级账本(Hyperledger)的肯定不多。在区块链的世界观里,一直有公有链、联盟链和私有链的分别,但后两者没有公有链引起的反响大,也被很多公有链的拥趸所鄙视。
但是我们不应该采取非一即二的思想看待这个问题,世界上没有任何客观实体是非黑即白,站的角度不同,结论也不一样。联盟链(私有链)是现有中心化商业团体联盟之间(团体内部)进行商业活动的手段和渠道,B2B 的业务很难迁移到公有链上,不仅仅是性能更是因为商业机密等问题。我相信未来是公有链与联盟链(私有链)共存,各自都有自己的使用场景,正如广域网与局域网,互有利弊,各司其职。
拉扯完背景,拖上这篇文章的主角:Hyperledger Fabric,它是由 IBM 带头发起的一个联盟链项目,于 15 年底移交给 Linux 基金会,成为开源项目。Hyperledger 基金会的成员有很多大牌,诸如 IBM,Intel,思科等。基金会里孵化了很多区块链项目,Fabric 是其中最出名的一个,一般我们说超级账本(Hyperledger)基本上指的都是 Fabric。在接下来的篇幅里,我会讲解 Fabric 的架构,包括多链多通道、账本设计等等,以及链码的编写和部署流程,最后再讲讲遇到的坑和 Fabric 的一些不足。
Fabric 的架构历经了两个版本的演进,最初接触的 0.6 版本只能被用来做商业验证,无法被应用于真实场景中。主要原因就是结构简单,基本所有的功能都集中在 peer 节点,在扩展性、安全性和隔离性方面有着天然的不足。因此在后来推出的 1.0 正式版中,将 peer 节点的功能进行分拆,把共识服务从 peer 节点剥离,独立为 orderer 节点提供可插拔共识服务。更为重要的一个变化就是加入了多通道(multi-channel)功能,可实现了多业务隔离,在 0.6 版本的基础上可以说是质的飞跃。
Fabric 中的链(chain)包含了链码(chaincode)、账本(ledger)、通道(channel)的逻辑结构,它将参与方(organization)、交易(transaction)进行隔离,满足了不同业务场景不同的人访问不同数据的基本要求。通常我们说的多链在运维层次上也就是多通道。一个 peer 节点可以接入多条通道,从而加入到多条链,参与到不同的业务中。如图所示:
账本简单的说,是一系列有序的、不可篡改的状态转移记录日志。状态转移是链码(chaincode)执行(交易)的结果,每个交易都是通过增删改操作提交一系列键值对到账本。一系列有序的交易被打包成块,这样就将账本串联成了区块链。同时,一个状态数据库维护账本当前的状态,因此也被叫做世界状态。在 1.0 版本的 Fabric 中,每个通道都有其账本,每个 peer 节点都保存着其加入的通道的账本,包含着交易日志(账本数据库)、状态数据库以及历史数据库。
基于 Kafka 实现的共识机制是 Fabric1.0 中提供的共识算法之一。之所以将 0.6 版本中提供的 PBFT 暂时取消,一是因为交易性能达不到要求;二一点是因为 Fabric 面向的联盟链环境中,因为节点都是有准入控制的,拜赞庭容错的需求不是很强烈,反而是并发性能最重要。因此,也就有了 Kafka 共识的出现。
前面介绍的 Fabric 架构更多的是针对 Fabric 平台运维工程师,而对更多的应用开发者来说,链码其实才是最重要的。链码(chaincode)是 Hyperledger Fabric 提供的智能合约,是上层应用与底层区块链平台交互的媒介。现阶段,Fabric 提供 Go、Java 等语言编写的链码,但不管是哪种语言编写的链码,套路都是差不多的。
所有的链码都继承两个接口,init 和 invoke。init 接口用于初始化合约,在整个链码的生命周期里,该接口仅仅执行一次。剩下的 invoke 接口是编写业务逻辑的唯一入口,虽然只有一个入口,但是可以根据参数传递的不同自由区分不同业务逻辑,灵活性很高。比如应用开发者规定 Invoke 接口的第一个参数是合约方法名,剩余的 Invoke 参数列表是传递给该方法的参数,那么就可以在 Invoke 接口方法体中根据方法名的不同分流不同业务了。
那么在合约里能够获取哪些内容呢?我把合约接口能获得数据分为三类:
编写链码还有一个非常重要的原则:不要出现任何本地化和随机逻辑。此处的本地化,不是指语言本地化,而是执行环境本地化。区块链因为是去中心架构,业务逻辑不是只在某一个节点执行,而是在所有的共识节点都执行,如果链码输出与本地化数据相关,那么可能会导致结果差异,从而不能达成共识。比如,时间戳,随机函数等。这些方法是链码编程的禁地,除非你知道你的用意,否则慎用!
在最初接触 Fabric 的那段时间,我其实是很混淆 peer、通道和链码间的关系的,直到我从头到尾完成了一次平台的部署。简单的说,peer 是一个独立存在的计算机节点,不管是物理机还是虚拟机,总之是独立实体。在 peer 没有加入任何通道之前,是不能够做任何业务的,因为他没有业务载体。而通道就是业务载体,是纯粹的逻辑概念,可以独立于 peer 存在,但也因此也没任何存在的意义了。最后链码就是业务,业务是跑在通道里的,不同的通道即便是运行相同的链码,因为载体不同,可认为是两个不同业务。peer 是地,通道是路,链码是车,三者相辅相成才能构建一套完整的区块链业务系统。经过以上分析,链码的部署也就如“把大象放进冰箱分几步”这么简单了:
从逻辑上来说,就是如此的简单。当然,在实际的操作过程中,肯定要复杂的多,感兴趣的读者可以对照着官方文档从头到尾撸一遍,之后再读这篇文章,我相信你会有更清晰的认识。
区块链是门新技术,Hyperledger Fabric 是更新的区块链实现,在我们调研实践的过程中,基本上除了官方文档以外再也找不到其他资料可供我们参考,我们唯一可行的学习途径就是:撸源码!通过撸代码去了解内部实现机制,出现未知错误,直接看源码反推,使用之路确实艰辛。在使用的过程中,我们也发现了很多坑,一些坑我们可以采用其他办法绕过,另外的就只能当做是 Fabric 的不足了。
之前因为学习资料的缺失,我们只能通过撸代码来学习。而现在这个时间点,Fabric1.0 版本已经推出有一段时间了,网络上已经有了很多学习资料,基本免费开源,此处不做推荐。之后也会具体的针对 Hyperledger Fabric 推出更有侧重点的文章,敬请期待。
参考资料:
Hyperledger Fabric 官方文档 2017:http://hyperledger-fabric.readthedocs.io/en/latest/index.html
A Kafka-based Ordering Service for Fabric 2017:https://docs.google.com/document/d/1vNMaM7XhOlu9tB_10dKnlrhy5d7b1u8lSY8a-kVjCO4/edit
自游,区块链底层架构师。16 年初接触区块链并全职投入,现供职于某世界 500 强企业做区块链底层研究及 BAAS 平台搭建。精通区块链底层存储、共识等技术,职业方向偏重联盟链体系。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞5
添加新评论1 条评论
2018-04-11 14:46