Hyperledger Fabric学习（零）入门

​       自从2008年中本聪发明了比特币以来，区块链行业被越来越多的人所关注。区块链具有分布式对等、数据块链式、不可伪造和防篡改、透明可信、高可靠性等关键特征。到目前为止，根据不同的应用场景和设计体系，区块链可以采用对应的开放共享节点权限方案，包括如下三种区块链部署模型：

• 公有链：所有人都可以随意使用，所有节点都可以随时加入退出，凡是加入的节点都会参与共识和数据的读写，该模型具有较强的中心化特征，比如我们现在熟知的比特币、以太坊；
• 联盟链：只有利益相关的特定区块链服务客户可以使用，节点只有经过授权许可之后方可接入网络，接入的节点按照规则参与共识和读写数据，具有较弱的去中心化特征，比如本门课程将要学习Fabric；
• 私链：仅由单个区块链服务客户使用，仅有授权的节点才能接入，并按照规则参与共识和读写数据；

​       本节实验将带大家一起开启联盟链Hyperledger Fabric的学习，通过本节内容，大家会学习并理解联盟链Fabric中的组织、成员、channel、链码、数据、msp、共识等重要的概念。

知识点

• Fabric的介绍
• Fabric的组织、成员概念
• Fabric的channel、链码概念
• Fabric中的数据存储
• Fabric的msp概念
• Fabric的共识方式

Fabric的介绍

​       2015年12月, 由Linux基金会牵头, IBM、Intel、Cisco等共同宣布了HyperLedger联合项目成立。超级账本项目为透明、公开、去中心化的企业级分布式账本技术提供开源参考实现。超级账本首次将区块链技术引入到分布式联盟账本的应用场景中，为未来基于区块链技术打造高效率的商业网络打下基础。目前，超级账本由面向不同目的和场景的八大顶级子项目构成。而Fabric是最早加入到超级账本项目中的顶级项目，面向企业的分布式账本平台,，引入了权限管理，支持可插拔、可扩展，由IBM、DIH等企业于2015年底提交到社区，是首个面向联盟链场景的开源项目，Fabric基于golang语言实现，目前已发布2.2版本。

它的github地址是：https://github.com/hyperledger/fabric

​        Fabric可以面向企业内部或多个企业之间的商业区块链应用场景，将区块链的维护节点和可见性限制在联盟内部，并用智能合约(链码)重点解决联盟成员间的信任或信息不对等问题，以提高经济活动效率。Fabric主要应用的场景有如下几个方面：

• 金融服务：Fabric可以有效降低交易成本和管控风险、减少跨组织的交易风险，其在金融领域的应用受到了不少银行和金融交易机构的主要推动。

• 征信和资产权属管理：Fabric可以促进数据的交易和流动；提供安全可靠的支持。特别是资产权属的管理，利用区块链平台建立的多方信任机制可以有效降低资产交易成本和违约风险。

• 国际自动化贸易和供应链管理：Fabric可以简化管理流程中繁琐的手续。利用智能合约，贸易中销售和法律合同可以数字化、可以实现货物监控和实时支付，大大降低了公司的运营成本。

​       通俗一点的来说，Fabric就是由少数的几个企业之间组成的一个弱分布式网络，每个企业定义为一个组织。企业与企业之间，也就是组织与组织之间，通过创建或者加入channel的方式，共享channel上的链码权限，所谓链码，也就是链上代码，是组织之间共同确认的业务代码，也通常被称为智能合约。因为链码一旦部署，不需要人为干预，只需要执行调用指定的方法，链码就会自动进行逻辑处理，将数据上传到联盟链中或者查询联盟链上的数据。

​ Fabric具有以下几个显著的特点：

• 去中心化：每一个创建或者加入了channel的组织，都会保存一份该channel中的数据，每次智能合约的成功调用导致的数据改动，都会及时同步到相关组织之中；像公链中的比特币一样，数据是去中心化保存的，具有很强的不可篡改性；
• 安全性：任何一个组织加入channel都需要获取现有channel中的组织投票表决半数以上的同意，一般来说一个组织代表的就是一个公司，创建一个组织需要创建许多相关的证书。组织与组织之间、组织与共识节点之间的通信，以及组织内的各种不同角色的成员管理，都需要生成对应身份的证书。在节点通信和成员管理中，都需要进行身份验证。在这种弱分布式网络中，一定程度上解决了公链中51%攻击的问题；
• 业务可控性：任何一个组织都可以在已加入的channel中创建智能合约，或者安装该channel中其他组织已经创建好的智能合约。安装并且实例化了某个智能合约的组织，可以随时调用智能合约中的方法实现具体业务。在Fabric中，调用智能合约需要根据实例化时指定的背书策略，寻找指定组织的背书节点进行背书。实际上这个背书就是模拟执行，这种背书机制是为了单个组织篡改节点数据。因为有了背书机制，如果某个组织篡改了节点数据，那么将会导致这个组织调用智能合约的结果与其他组织背书执行这个智能合约的结果不一致，调用不通过，数据也就无法修改；在一定程度上，解决了当前金融行业第三方信任机制强依赖的问题；

Fabric的组织、成员概念

组织

​       Fabric网络中的最大单元是组织，组织中可以包含peer、orderer两种节点，每种节点可以包含一个或多个，每个节点都可以看做一个正在运行的服务。它们的职责如下：

• peer节点：每个组织至少需要有一个peer节点，peer节点可以被指定为多个角色，承担多份责任，互不冲突。peer的各种角色及职责如下：
  • committer记账节点：每个peer节点都是记账节点，负责接收提案，修改状态数据库；
  • anchor锚节点：负责与其他组织的其他节点进行通信，比如指定其他组织选择背书节点对提案背书；
  • endorser背书节点：负责组织内的背书职责（链码模拟执行）；
• orderer节点：第一个创建的组织至少需要有一个orderer节点，后加入的组织可以有新的orderer节点加入到orderer集群中，也可以不创建新的orderer节点。orderer集群中的orderer节点负责每次提案的接收、排序、打包、分发个对应组织的peer节点；

成员

​       Fabric组织中的peer、orderer都有成员的概念。orderer节点中的成员只有一个，因为orderer集群中的节点可能是由不同的组织共同组成的，所以orderer节点创建的成员的目的就是标志一个唯一身份，Fabric会为这个orderer节点的唯一成员生成公私钥证书，如果开启了TLS通信方式，那么还会生成TLS证书。

​       在Fabric的组织的peer节点中，成员个数是通过配置文件制定的，一般来说，会包含一个Admin成员和多个User成员。某些操作的权限只有Admin成员才能执行，比如创建链码、部署链码等等；

Fabric的channel、链码概念

channel

​ channel创建的目的是隔离组织、隔离数据。

• 隔离组织：在一个存在三个组织A、B、C的联盟链中，可能A某些业务只与B共享，那么可以为A、B单独用一个channel，在这个channel上面部署智能合约，只有A和B才能部署并调用该合约，对组织C来说，是不可见的；
• 隔离数据：还是在一个存在三个组织A、B、C的联盟链中，A、B、C都是用相同的智能合约。组织B与组织C相互不需要通信，都是只与组织A有业务往来。现在由于组织A属于银行，跟组织B的链上数据不想被组织C看到，同样跟组织C的链上数据也不想被组织B看到。因此可以计划原来把链码部署在同一个channel中，为了组织A数据的安全性，分别为组织A和组织B、组织A和组织C创建channel，在两个channel中部署相同的智能合约；这样对于组织B和组织C来说，与组织A的业务是相同的，但是彼此之间由于不在一个channel中，数据是隔离的；

链码

​       链上代码，简称链码，又称智能合约。一般是指由开发人员使用Go语言（也支持Java等语言）编写的应用程序代码，提供分布式账本的状态处理逻辑。链码被部署在Fabric的网络节点中，能够独立运行在具有安全特性的受保护的Docker 容器中，以 gRPC 协议与相应的 peer 节点进行通信，以操作（初始化或管理）分布式账本中的数据。可以根据不同的需求开发出不同的复杂的应用。

​       链码的部署需要指定组织、该组织加入的channel、该组织中加入了该channel的peer节点这三个最基本的条件。除此之外，链码需要定义链码名称和链码版本。

​       链码的部署大致分为两步：安装和实例化。

• 安装：链码的安装实际上是把打包好的链码文件进行一定的处理保存到指定了的peer节点容器中的某个文件目录下。
• 实例化：链码的实例化由Fabric的系统链码完成，Fabric会对链码文件进行指定的Dockerfile格式编译成docker镜像并运行该镜像。在同一个组织中，同一个channel下的同一个链码需要部署到组织中的多个peer节点上，第一个安装了该链码的peer节点在部署的时候需要实例化该链码，后续部署该链码的peer节点就只需要安装，不需要再实例化了。总结起来就是，链码只会在一个组织中被实例化一次。

​​       另外，链码属于业务逻辑代码，因此可能会需要修改。Fabric提供了链码升级的功能，不过因为链码在实例化的时候指定了背书策略，如果在多个组织共同部署了同一个链码的情况下，某个组织单独修改链码项目，升级链码，会出现调用该链码的时候因为与其他组织背书结果不相同而调用失败；所以，在链码需要升级的时候，需要部署了该链码的所有组织都同步升级。

Fabric中的数据存储

​       Fabric数据存储在peer节点和orderer节点中。一次链码调用会产生一个提案，该提案由背书节点验证，发到orderer集群中，由orderer集群存储该提案信息。orderer集群会对所有提案进行排序、打包，最后广播给相关的peer节点，peer节点会根据提案的信息，修改本地存储的状态数据。

​       因此，我们可以总结一下：peer节点负责存储状态数据，orderer集群负责存储提案，如果用传统型数据库mysql来类比的话，peer存的数据就是我们能够通过select查到的表数据，orderer集群存储的就是我们进行insert、update、delete时的记录；

Fabric的msp概念

​       在Fabric中，MSP是Membership Service Provider的缩写，直译为成员关系服务提供者。我们可以简单的理解为，MSP就是提供了一组用来维护我们上述所说的组织和成员身份信息的生成、验证的接口。除了在Fabric内部基于MSP接口实现的一套msp服务，hyperledger组织另外还开发了一个Fabric-CA项目，不管使用哪一种，它们都是实现了MSP的接口，都是用来管理Fabric的组织、成员之间的身份信息的生成和验证的。

​       Fabric的身份信息的生成使用了基于标准的x.509标准生成证书的方式。Fabric会创建一个私有的CA根证书，多个组织都由这个根证书颁发中间证书。组织中的成员证书则是由组织的中间证书生成的下一级证书。证书生成的算法目前默认指定了SW，也就是SHA256方式。

Fabric的共识方式

​        Fabric的orderer集群负责接收提案、排序、打包、广播等工作。orderer集群的orderer既属于某个组织，也属于该集群，每个orderer节点都需要参与orderer集群的共识。目前Fabric支持的共识方式有两种：

• 基于raft的Etcdraft共识：它是一种基于 etcd 的崩溃容错排序服务。raft 遵循 "领导者和追随者"模型，其中领导者在通道中的orderer节点之间动态选出，该领导者将消息复制到跟随者节点，只有领导者对外提供服务。如果领导者节点服务失效，orderer集群会基于raft算法迅速投票选举处新的领导者。
• Kafka共识：Kafka是一种支持多通道分区的集群时序服务，可以容忍部分节点失效，但不能容忍恶意节点。Kafka基于Zookeeper进行Paxos算法选举，支持2f+1节点集群，f代表失效节点个数。即Kafka可以容忍少于半数的共识节点失效。