超级账本HyperLeder

Hyperledger Fabric原理详解(交易流程及MSP)

2020-05-21  本文已影响0人  小蜗牛爬楼梯

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

❝

「高能提醒」

要理解本章内容，必须对非对称加密、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.yamlOrdererOrgs:   # 以下定义Orderer节点的域名和主机名    - Name: Orderer  # 名称，随便起，不重复就行      Domain: mid.org  # 该组织域名      Specs:   # 下面指定orderer节点的主机名，完整的主机名是 Hostname + Domain        - Hostname: order0  # order0.mid.org        - Hostname: order1        - Hostname: order2复制代码

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

# crypto-config.yamlPeerOrgs:   # 以下定义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相关。

二级目录

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

三级目录

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

四级目录

如上图，以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目录结构并不全面，有些文件夹是没有的（因为不是必须的）。

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

MSP目录结构 
 执行这个命令，可以查看证书内容： `openssl x509 -noout -text -in ./organizations/peerOrganizations/m.com/peers/peer0.m.com/msp/signcerts/peer0.m.com-cert.pem`
image.png

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

MSP如何使用

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

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

MSP存在何处

存在于两个地方：

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

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

本地MSP

  1. 通道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何时使用

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


Fabric交易过程

对照上一节中的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和交易中各方的签名）。

MSP目录结构

TLS

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

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

TLS协议栈

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

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流程序员
链接：https://juejin.im/post/5e8c4d24f265da47bd1b9bc5
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

上一篇 下一篇

猜你喜欢

热点阅读