本着“LearningbyDoing”的理念，上周加入了Bob组织的HiBlock区块链技术布道群。这个群体不容易混。群规要求每个成员每周必须有产出。如果连续交两张白卷，就会被踢出群。在这样的压力下，我决定新开一个坑：区块链周记，记录每周的区块链学习成果和攀爬心得。作为系列的新篇章，我选择从Hyperledger的Fabric开始。为什么选择Hyperledger作为起点？我在之前的文章中说过要从超级账本开始区块链的学习和实践，也给出了个人的理由。但作为一篇说教文章，单凭个人喜好是没有说服力的。在Fabric的文档中，强调了它为企业应用而生的原因：企业希望与已经确定身份的人做生意，而不是像公链那样完全匿名的交易对手。不是每个人都可以加入商业网络交易隐私，例如，对于不同的渠道或经销商，他们获得不同的折扣，这些信息必须是隐私的并且相互隔离。从性能和交易确认时延上可以看出，相比公链激进的做法，以Fabric为代表的联盟链要温和很多，也容易被企业接受。再加上它给的一些限制，技术实现上还是比较容易的。关于区块链本身的Fabric中主要组件的理论和介绍已经很烂了，这里不再赘述。本节我们就来看看Fabric是如何通过其主要组件来实现技术的。从大的角度来看，Fabric的主要组成部分大致可以分为这几个部分：分布式账本，它解决了数据共享的问题，让所有参与者拥有共同的交易历史。智能合约解决了应用程序和账本之间的交互，包括查询和更新。共识机制解决了数据同步问题，实现了基于背书策略的交易传播。会员服务，解决参与者的身份问题，只有受信任的会员才能完成交易。分布式账本Fabric的分布式账本状态由两部分组成：世界状态（WorldState）和区块链。前者代表账本的当前状态，经常更改和查询，常以数据库的形式实现；后者用于捕获前者的每一次变化，作为事务变化记录，不可修改，很少查询，常以文件的形式实现。对于世界状态的DB载体，当前版本有两种选择：内置的LevelDB和外置的CouchDB。如果想获得更灵活的查询能力，选择后者。由此，你应该能猜到worldstate中存储的数据是以KV对的形式存在的。对于区块链来说，它是由Blocks组成的哈希链，每个Block包含一组有序的交易。这个顺序就是交易顺序，非常关键。除了这两个组件之外，Fabric还引入了一个独特的设计：Channel，用来解决不同组织间账本共享的问题。如果A机构同时与B机构和C机构做生意，B机构和C机构是竞争对手，那么A和B可以通过建立不同的通道来实现，A和C分别共享自己的账本。利用Channel，很好的解决了常见的B2B场景。Channel抽象了业务参与者之间的通信，可以看作是业务网络的一个子网，实现了交易和业务隐私的相互隔离。智能合约Fabric的智能合约以“链码”的形式存在，外部客户端使用它来完成对世界状态的改变。与以太坊不同，链码支持使用通用编程语言编写。目前版本支持Go和Node.js，但是从FabricJavaSDK的源码可以看出离支持Java不远了：publicenumType{JAVA,GO_LANG,NODE}对于初学者来说，需要注意的是该链码！=FabricSDK。前者运行在Fabric环境中，执行业务逻辑。后者被客户端程序用来与链码交互。做一个类似的类比：把Fabric环境想象成一个像Tomcat这样的容器。Chaincode可以看作是运行在其中的一个Servlet。FabricSDK类似于HttpClient，用于Java客户端发起请求，实现与Servlets的交互。可见，链码本身其实就是一个应用，其生命周期可以分为：打包、安装、实例化、升级。同样，chaincode可以绑定到任意数量的Channels并独立运行。关于链码教程，文档中已经给出了详细的说明，这里不再赘述。共识机制Fabric中的节点分为三类：Client，代表终端用户向背书者提交交易调用（TransactionInvocation），向排序服务广播交易提议（TransactionProposal）。Peer，提交交易，维护世界状态和账本副本（区块链）。其中，一种特殊的Peer是Endorser。Orderer，提供节点间的通信服务，保证消息的传递和顺序，典型的是Kafka队列。文档中介绍了整个交易流程：client发起交易提案。背书节点验证并执行。客户端检查对事务提议的响应。如果背书策略得到满足，则客户端将背书打包到交易中并将其提交给排序服务。消息包括：背书者签名、读写集、通道id。交易由排序者提交给通道上的所有节点，节点将检查并提交交易。账本更新。从以上流程可以看出，Fabric的共识机制是基于背书策略，可以通过命令行参数进行配置，不需要Channel所有Peer的参与。会员服务会员服务负责参与者的身份许可和验证，它基于数字证书和信任链。所谓成员，可以是一个组织（Org），也可以是一个组织单元（OU）。Fabric成员服务配置可以出现在两个地方：Local（节点）和Channel（通道级别）。从开发的角度来看，引入成员服务的作用是应用程序（Client和Chaincode）想要参与到区块链网络中，需要相应的签名和证书。Fabric的开发套路说实话，从上面的简单介绍，我们可以看出Fabric的开发并不简单，至少涉及到：Client，提供UI，链码交互等辅助功能。Chaincode，负责执行业务逻辑。业务网络，定义参与者、渠道和认可政策。成员管理，定义组织及其成员映射，涉及一系列证书的颁发。应用部署，将以上部分部署到Fabric环境中。这还没完，怎么测试也是个大麻烦。与简单的CRUD应用程序相比，仅仅构建一个Fabric环境是令人望而生畏的。如果对自己有更高的要求，想要实现持续集成环境怎么办？此外，开发后的运维成本也不会低。除了Fabric本身的基础设施，链码的顺利升级也对开发和运维提出了高标准。鉴于这些麻烦的事情，如果你没有办法说服业务伙伴也部署一套Fabric，我认为没有必要基于它开发应用程序。在单一组织内应用区块链，我个人认为是一个伪命题，没有存在的价值。关于sampletutorial，Fabric的文档中已经给出了示例，大家可以仔细阅读。为了降低区块链应用的开发难度，Hyperledger项目引入了Composer。其目的是加速应用程序的开发和部署。已经支持Fabric，目前处于孵化阶段。它建立在众多框架和工具之上：node.js+angular，帮助开发者完成全栈区块链解决方案的开发。yeoman，利用其模板功能快速构建应用程序框架。一套开发环境，实现应用的打包部署并暴露为RestfulService。看起来不错！写在最后对于一个初学者来说，写这篇文章真的很不容易！如果文章中有错误，欢迎指出，:)。关于下周的周记，我会写一个Fabric实际应用的例子，同时给出一个Composer的例子，敬请期待。注：在写这篇文章的过程中，我还发现了一篇吐槽Fabric的文章。这里有一个链接，方便你客观评价。
