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队列。

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

client发起事务提议。
endorser peer验证并执行。
client检查事务提议的响应。
若endorsement policy满足，client将endorsement打包进事务，提交给ordering service。消息包括：endorser签名、读写集和channel id。
事务被orderer提交给channel上所有的peer，它们会检查并提交事务。
账本更新。

从上面的流程可以看出，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的文章，这里一并给出链接，方便大家客观评定。