Hyperledger Fabric周周记：起源

本着“以教带学，Learning by Doing”的想法，我于上周加入了Bob组织的HiBlock区块链技术布道群。这个群可不太好混，群规要求每一个成员必需每周有输出，连续两次交白卷就要被踢出群。

在这样的压力之下，我决定开一个新坑：区块链周周记，记录下每周区块链的学习成果和爬坑经验。做为系列的新篇章，我选择从超级帐本的Fabric开始。

为何选择超级帐本做为起点？

我在以前的文章中曾说过会从超级帐本入手开始区块链的学习和实践，同时也给出了我的的理由。但做为一篇布道类文章，单单我的喜爱是没有说服力的。

在Fabric的文档中，它强调了本身面向企业应用而生的理由：

• 企业但愿跟身份肯定的人作生意，而非像公链那样彻底匿名的对手方
• 并不是人人均可加入的商业网络
• 交易的私密性，好比，对于不一样的渠道或经销商，他们各自拿到的折扣不同，这些信息必须是私密的，相互隔离。
• 性能和交易确认的时延

能够看得出，相比起公链激进的作法，以Fabric为表明的联盟链要温和的多，而且也容易为企业所接受。加上其给出的若干限制，技术上的落地也相对容易不少。

Fabric中的主要组件

关于区块链自己的理论和介绍，目前已经烂大街了，在此也就是再也不赘述。在本节，让咱们来看看Fabric是如何经过主要组件完成技术落地的。

从大的方面讲，Fabric的主要组件大体可划分红这几个部分：

• 分布式帐本，解决数据共享问题，让全部参与方拥有共同的交易历史。
• 智能合约，解决应用与帐本的交互问题，包括查询和更新。
• 共识机制，解决数据同步问题，基于Endorsement Policy实现交易的传播。
• 成员服务，解决参与方身份问题，只有可信成员之间才能完成交易。

分布式帐本

Fabric的分布式帐本状态由两部分组成：世界状态（World State）和区块链。前者表明帐本的当前状态，变动和查询频繁，每每以数据库形式实现；后者则用来捕获前者的每次变动，做为交易的变动记录，没法修改且极少查询，经常实现为文件形式。

对于世界状态的DB载体，当前版本有两个选择：内置的LevelDB和外置的CouchDB，若是想要得到更灵活的查询能力，选择后者。由此你们应该能够猜出：世界状态中保存的数据是以KV对的形式存在。

对于区块链来说，它以Block的hash链组成，每一个Block包含一组有序的交易。这个顺序是交易顺序，很是关键。

除了这两个组件，Fabric还引入了一个独特的设计：Channel，用来解决不一样组织间的帐本共享问题。假如组织A同时与组织B和组织C作生意，而且组织B和组织C是竞争对手，那么经过创建不一样的Channel能够实现A和B，A和C分别共享各自的帐本。利用Channel，很好地解决了常见的B2B场景。

Channel抽象出了业务参与方的沟通，可视为业务网络的子网，实现了交易的相互隔离和业务私密性。

智能合约

Fabric的智能合约以“链码（Chaincode）”的形式存在，外部客户端利用它来完成对世界状态的更改。与以太坊不一样，链码支持使用通用编程语言来书写，当前版本支持Go和Node.js，但从Fabric Java SDK的源码中能够看出，离支持Java应该也不远了：

public enum Type {
    JAVA,
    GO_LANG,
    NODE
}

对于初学者须要注意的是：链码 != Fabric SDK。前者运行于Fabric环境，执行业务逻辑。后者则由被客户端程序用来与链码完成交互。打个相似的比方：

• 将Fabric环境视为Tomcat这样的容器。
• 链码则可视为运行于其中的Servlet。
• Fabric SDK则相似HttpClient这样的类库被Java客户端利用发起请求，实现于Servlet的交互。

由此可知，链码自己其实是一个应用，其生命周期可分为：package、install、instantiate、upgrade。一样，链码能够绑定任意任意数量的Channel，并独立运行。

关于链码的教程，文档已经给出了详细的说明，在此就再也不啰嗦。

共识机制

Fabric中有三类节点：

• Client，表明最终用户向endorser提交事务调用（Transaction Invocation），向ordering service广播事务提议（Transaction Proposal）。
• Peer，提交事务，维护世界状态和帐本副本（区块链）。其中，有一类特殊的Peer是Endorser。
• Orderer，提供节点间的通讯服务，保证消息的交付和顺序，典型如Kafka队列。

整个事务流程在文档中有介绍：

1. client发起事务提议。
2. endorser peer验证并执行。
3. client检查事务提议的响应。
4. 若endorsement policy知足，client将endorsement打包进事务，提交给ordering service。消息包括：endorser签名、读写集和channel id。
5. 事务被orderer提交给channel上全部的peer，它们会检查并提交事务。
6. 帐本更新。

从上面的流程能够看出，Fabric的共识机制创建在endorsement policy之上，它能够经过命令行参数进行配置，并不须要Channel的全部Peer参与。

成员服务

成员服务负责参与方的身份许可和验证，它创建于数字证书和信任链基础之上。所谓成员，既能够是组织（Org），也能够是组织部门（OU）。Fabric的成员服务配置能够出如今两处：Local（节点）和Channel（Channel级）。

从开发角度来说，引入成员服务带来的做用就是：若是应用（Client和Chaincode）要参与到区块链网络中，则须要相应签名和证书。

Fabric的开发套路

老实讲，从上面的简单介绍已经看出，Fabric的开发并不简单，它至少涉及：

• Client，提供UI、链码交互以及其余辅助功能。
• 链码，负责执行业务逻辑。
• 业务网络，定义参与方、Channel和Endorsement Policy。
• 成员管理，定义组织及其成员映射，这涉及到一系列证书的发放。
• 应用部署，将上面的各部分部署到Fabric环境。

这还不算完，如何测试也是一个大麻烦，相比起简单的CRUD应用，光搭建Fabric的环境就让人生畏。假如你对本身的要求更高点，想要实现一个持续集成环境，该怎么办？

此外，开发以后的运维成本也不会低，除了Fabric自己的基础设施，链码的平滑升级也对开发和运维提出了高标准。

鉴于这些麻烦的事情，假如你没有办法说服业务合做方也一样部署一套Fabric，我以为彻底没有必要去基于它来开发应用。单组织内的区块链应用，我我的认为是一个伪命题，没有存在的价值。

关于示例教程，Fabric的文档已经给出了范例，各位能够仔细阅读。

为了下降区块链应用的开发难度，超级帐本项目又引入了Composer。其目的在于加速应用的开发和部署，目前已经支持Fabric，当前处于孵化阶段。它创建在诸多框架和工具之上：

• node.js + angular，帮助开发者完成全栈区块链解决方案的开发。
• yeoman，利用其模板功能快速搭建应用框架。
• 一套开发环境，实现应用的打包部署以及暴露成Restful Service。

看起来很不错！

写在最后

对于一个初学者来说，写这篇文章真不容易！如文章存在错误，不要客气，只管指出，:)。关于下一周的周记，我会去写一个实际的Fabric应用的例子，同时给出Composer的例子，请保持关注。

附注：在写此文的过程当中，我还找到了一篇吐槽Fabric的文章，这里一并给出连接，方便你们客观评定。