Hyperledger Fabric原理详解与实战5

本文主要内容如下，爱看不看～

❝

「高能提醒」

要理解本章内容，必须对非对称加密、PKI（公钥、私钥、证书和CA等）概念和原理有一定的了解。否则后面的学习会遇到很大的障碍。

❞

许可准入问题

我们知道，比特币钱包用的是密钥对，用来对交易进行校验或签名。而Fabric用的是证书。

证书就是指的PKI证书。我们常见的PKI证书是用在网站服务器上，用来开启HTTPS的。也就SSL证书，用于加密传输。

但证书还有非常非常重要的应用，就是数字签名。

Fabric中的证书也是同样的作用。因为证书本质上也是密钥对，只是多了一个第三方认证机构—CA。

为什么不直接使用密钥对，而要用证书呢？

原因很简单，因为Fabric是联盟链呀！

联盟链也被称为“许可链”，就是说，必须经过允许才能访问。

常见的许可方式就是账号认证，拿账号密码来确定是否为合法用户。

而Fabric是这样做的：

所有Fabric网络的参与者（包括管理orderer的组织）都要事先声明，哪些CA是你们受信任的CA。

受信任的CA一旦确定，那么只要是持有这些CA颁发的有效证书来访问网络，就认为是合法用户。这样就实现了许可准入的需求。

生成证书

获取证书有两种方式：

1. 第一种是CA颁发，生产环境中一般采用这种方式。
   CA服务可以自己部署，比如，Fabric CA。也可以用主流的第三方机构，如：Symantec、Thawte、GeoTrust、GlobalSign等。

2. 第二种是使用Fabric自带的工具（cryptogen）生成。

我们先采用工具生成，等再熟悉一些概念后，再加入Fabric CA。

使用cryptogen生成证书

先准备一个配置文件：crypto-config.yaml 。

❝

「NOTE」

配置文件都很长，直接贴在文章里影响阅读体验。
所以我将他们拆成一段段分开讲解。
完整的配置文件和操作命令我会放到另一篇专门的文章《操作指南》里。

❞

片段1. orderer集群可以由多个组织管理，每个组织贡献自己的orderer节点，均在下面配置里体现

# crypto-config.yaml
OrdererOrgs:   # 以下定义Orderer节点的域名和主机名
    - Name: Orderer  # 名称，随便起，不重复就行
      Domain: mid.org  # 该组织域名
      Specs:   # 下面指定orderer节点的主机名，完整的主机名是 Hostname + Domain
        - Hostname: order0  # order0.mid.org
        - Hostname: order1
        - Hostname: order2

片段2. 下面定义参与者组织的peer节点主机名和用户

# crypto-config.yaml
PeerOrgs:   # 以下定义peer节点的域名和主机名
    - Name: Mcorp     # 名称，随便起，不重复就行
      Domain: m.com   # M公司域名
      EnableNodeOUs: true   # 设置为true就是了，后面再说明
      Specs:    # 下面指定peer节点的主机名，完整的主机名是 Hostname + Domain
        - Hostname: peer0  # peer0.m.com
        - Hostname: peer1
      Users:  # 指定该组织用户的数量，不包含管理员。OrdererOrgs下该选项无效。
        Count: 1
  
    - Name: RateCorp
      Domain: rate.com
      EnableNodeOUs: true
      Template:  # 主机名也可以按模板自动生成，只需指定节点数量
        Count: 2 # 自动生成peer0.rate.com，peer1.rate.com
      Users:
        Count: 1
  
    - Name: DbCorp
      Domain: db.com
      EnableNodeOUs: true
      Template:
        Count: 2
      Users:
        Count: 1            

保存配置文件后，执行命令：

cryptogen generate --config=./crypto-config.yaml --output="organizations"

# --config: 指定配置文件路径
# --output: 指定生成文件存放的目录

❝

「TIPs」

如何获得Fabric的程序，请参考《操作指南》

❞

命令执行成功后，会在organizations目录下生成一堆的文件，让人有点眼花，但结构是清晰的。

最重要的文件也只有几个而已，其他很多文件都是重复的。

我们一级级目录来看：

一级目录下，很明显，分成了orderer相关和peer相关。

二级目录，每个组织都会有对应的目录。

每个组织对应的文件夹下都会有这样几个目录：

• ca：存放组织的CA的根证书和私钥。
• tlsca：存放颁发TLS证书的CA的根证书和私钥。
• msp：重点概念，下一节详述。
• peers或orderers：存放每一个orderer或peer节点相关的证书文件。
• users：存放组织下每一个user相关证书文件。

如上图，以db.com为例，配置文件里指定了2个peer节点和一个用户，在这里都有对应的目录体现。

用户中还有一个管理员，每个组织都有的。

我们再来看看peer节点和user目录下有什么？

眼睛别看花了哈！看红线标注的目录下。用户和网络节点目录下的文件结构是一样的，都包含msp和tls两个目录。

「重点来了哈！」

什么是MSP

如果新手从到到尾的看官方文档，MSP这个概念绝对把你整蒙逼。

我当时就为弄清楚这个概念到底是什么东西，断断续续把官网上大部分文档看完才基本理解了。

当然，现在最新的文档已经说得更清楚一些了，但还是需要对整个体系有所把握才能完全理解。

先来感受下官方给的定义：

❝

The Membership Service Provider (MSP) refers to an abstract component of the system that provides credentials to clients, and peers for them to participate in a Hyperledger Fabric network.

Membership Service Provider(MSP)是指一个抽象的系统组件，它提供凭证给客户端和peer，以让它们参与Hyperledger Fabric网络。

❞

看完这个定义后之后，感觉它应该是一个具体的服务。

可并不是，它只是定义了接口，用来完成参与者的认证、授权和交易的签名、校验等工作。

MSP包含了一系列的接口定义和操作机制，我们这里只需要简单理解–它就是上一节我们看到的那一堆证书文件。准确的说，就是msp这个文件夹里的文件。

来看看里面有什么？

如下图，MSP是有一定的目录结构的。我们在上一节中生成的msp目录结构并不全面，有些文件夹是没有的（因为不是必须的）。

所以我贴上官方文档给的图片。里面文件的名称与我们生成的不同，但文件夹的名称是一样的。

• config.yaml: 还记得crypto-config.yaml配置文件里有个 EnableNodeOUs 吗？如果设置为true的话，会生成该文件。内容和含义如下图，如果看不懂，就接着看后面的内容。 执行这个命令，可以查看证书内容： openssl x509 -noout -text -in ./organizations/peerOrganizations/m.com/peers/peer0.m.com/msp/signcerts/peer0.m.com-cert.pem

• cacerts: 该目录下存放组织信任的根CA证书，可以有多个。

  细心的话，会发现它和对应的组织域名目录下ca目录里的证书是一样的。
  这个目录很重要，只要持有组织信任的CA颁发的证书来访问Fabric网络，就认为是合法的身份。

  当然，有没有权限访问网络里的资源，还需要通过相应的策略验证。

• intermediatecerts: 该目录下存放中间CA的证书。设置中间CA可以将角色和用户权限设置得更灵活。

• admincerts: 存放管理员的用户证书。Fabric v1.4.3以后已被废弃，建议使用config.yaml中的设置来区分管理员角色的证书。

• signcert: 该目录存放CA颁发的证书，包含用于验证签名的公钥。

• keystore: 存放与公钥对应的私钥文件，用于签名。

• tlscacerts: 该目录下存放组织信任的颁发TLS证书的根CA证书，可以有多个。类似cacerts。只是作用不同。signcert用于签名，tls用于ssl安全通信。

• tlsintermediatecacerts: 该目录下存放组织信任的颁发TLS证书的中间CA的证书。

• operationscerts: 该目录存放访问Fabric运营服务时所需的证书文件。

后续在讲到Channel MSP的时候还会涉及到一个revocation_list的配置，存放被吊销证书的列表信息。

MSP如何使用

喂～！还有人在吗？希望没把你们吓跑。上面这一堆的文件和说明，我看着都

不过好在，这些东西不用死记硬背，重在理解。没有什么知识是举一个好的例子理解不了的，如果有，那就两个。

MSP存在何处

存在于两个地方：

1. 本地MSP（Local MSP）：每一个orderer和peer节点上都必须有msp文件系统。

   如下图所示，我将上一节生成的文件的路径和对应的节点标识在图上了。在启动这些节点的时候，要将对应的文件拷贝到节点的文件系统中，至于拷贝到哪个路径，是可以自定义的，由程序的配置决定。

2. 通道MSP（Channel MSP）：每一个Channel的配置中都有其组成成员的MSP配置。

   配置的内容来自于对应组织目录下的msp目录。比如：M公司对应的目录是：“peerOrganizations/m.com/msp”。

   这个目录下包含了受信任的CA（包括根CA、中间CA、TLS根CA和TLS中间CA）的证书和node ou的配置（就是msp目录下config.yaml的内容）。

   还有其他的一些额外内容，后面我们会看到。

   哦，对了，这个配置是存在区块中的。导出成json格式后，是这个样子。

MSP何时使用

这又得回到我们说过的交易流程上来了。

对照上一节中的MSP目录结构图来看。（贴心如我，已经把图片贴在后面了，不用再往前翻找了☺）

1. 客户端以User1的身份发起交易请求，并对请求消息用私钥签名（私钥：peerOrganizations/m.com/users/User1@m.com/msp/keystore/signer.key），同时也要附上自己的证书：peerOrganizations/m.com/users/User1@m.com/msp/signcerts/signer.crt。

2. peer收到请求后，通过保存在通道MSP中的CA（包括中间CA和根CA）证书验证请求者证书，并确定其身份。

   然后执行智能合约后，得到执行结果。并用本地MSP的私钥对结果进行签名（同样要用到私钥和证书：msp/keystore/signer.key，msp/signcerts/signer.crt，下同），最后返回给客户端。

3. 客户端对结果进行比对，通过后，封装成交易并对其签名。然后，发送给orderer。

4. orderer收到交易后，通过通道MSP中配置的CA证书，验证并确定用户的身份。

   然后将交易打包到区块，同样使用本地MSP对区块进行签名。最后，分发给peer。

5. peer收到区块后，验证区块有效性。然后逐一对区块内的交易进行各种验证（通过通道MSP和交易中各方的签名）。

TLS

TLS是用于在两个通信应用程序之间提供保密性和数据完整性的通信协议。我们熟悉的HTTPS就是建立在TLS之上的HTTP协议。

Fabric客户端与节点、节点与节点之间的通讯，建议采用加密传输。

节点启用TLS，就需要有TLS CA颁发的证书和私钥，这两个文件存在与msp并列的tls目录下，如：

总结

这一节讲了挺多内容的，虽然操作上只有简单的一步，但涉及到两个知识点–MSP和TLS。

MSP是一个很核心的概念，跟channel一样，贯穿了整个Fabric的交易流程。后面我们还会反复涉及到这些内容。

Fabric是联盟链，而且是以组织为单位参与的，但是，执行具体操作和交易的是组织内的节点和用户（客户端），那系统如何区分用户或节点属于哪个组织？用户在组织中的角色又是什么？

利用PKI机制实现的MSP，既解决了身份认证问题，又利用证书里的OU字段区分了不同角色。

「但是」，请记住，MSP是只是一套接口，所以，除了PKI还有其他的实现方式，比如：Idemix。

客户端与节点、节点与节点之间的通讯，建议采用TLS加密。这需要一个TLS证书和颁发它的CA（可以与msp的CA是同一个）。

生产环境建议设置一个固定的CA服务，可以是组织自建或公共受信的。在增加或撤销用户和节点时方便操作。

当然，如果不用CA服务也可以用SSL等工具。

需要注意的是，一旦网络运行起来以后，不可以再使用cryptogen生成新节点或用户，因为每执行一次cryptogen，就会改变CA证书私钥内容，相当于换了一个新的CA。

❝

「切记！！！ cryptogen工具仅用于开发或测试环境。」

❞

我是2流程序员，我们下次再贱！

本文使用 mdnice 排版