HyperLedger Fabric 模块入门
这篇博客作为最近一段时间对 hyperledger 官方文档学习的一个总结，主要归纳一下 hyperledger 中一些重要组件的作用和重要功能的流程。
Fabric概览
一个 hyperldger 应用包含了这几个模块， 客户端应用（applications），节点（peers），组织（orgnizations），排序节点（orderer），成员关系服务提供者（MSP），渠道（channel），账本（ledger），智能合约（smart contract）等模块。
一个 Hyperledger 应用的大致流程主要是以下几个步骤 ：
- 应用（application ）发起一个请求（proposal）到 hyperledger 网络中，这个请求将被网络中指定的节点（peer）所验证并执行对应的链代码（chaincode）
- 网络中的节点（peers）需要提前安装（install）对应的链代码（chaincode），并在节点所属的渠道（channel）中进行初始化（instantiate）才能为客户端应用所调用。（应用是怎么确保请求数据为有权限的节点所接受并执行相应的 chaincode 逻辑？？？）
- 节点将根据请求数据作为输入的参数，调用 chaincode 执行相应的逻辑并封装成一个请求响应（proposal response）返回给客户端应用。 此时执行的逻辑并不会更改节点本地的账本（ledger）的状态
- 客户端接收到多个节点（peers）返回的请求响应数据，并把这些数据封装成一个交易对象（transaction），发送给网络中的排序节点（orderer）
- 网络中的排序节点（orderer）在接收到交易对象后，将通过 MSP 等对交易信息进行验证并排序，并将来自不同应用的交易对象进行排序，打包成块（block），并将打包的块分发（distribute）到渠道中的各个节点上进行验证。
- 当节点验证块中的交易数据后，将会更新自己本地维护的账本（ledger）的副本数据，并通过响应的通知机制通知客户端应用请求已被加入到账本中
这是一个 hyperldger 应用中大致的交易流程。接下来回顾一下在这个过程中将涉及到的一些模块组件。
身份 （Identity）
身份信息决定了一个角色在 hyperledger 网络中对网络资源和信息的访问权限。hyperledger 定义的原则（principle），即是身份和其附带的属性信息所构成。
这涉及到的两个知识点，包括 PKI 和 MSP， 在官方文档的例子中，PKI 就像提供了一张可用身份信息的列表，而 MSP 则决定了在这个列表中，有哪些身份信息是可以参与到网络中指定的机构中的。
PKI，即 public key infrastructure， 包含了
- 向机构分发数字证书（digital certificate）的证书机构（Certificate Authority），机构通过数字证书，来向其他机构验证自己在网络中的身份信息。
- 一个 CRL ，certificate revocation list，废除证书列表，通过这个列表可以查询到已经不再使用的列表 （这个和证书过期是不太一样的）。
- 一个公钥（public key）和私钥（private key）的架构。
这里注意的是，证书机构 （ca），是可以分成根机构（Root CA）和中间机构（Intermediate CA）的。根机构可以通过向中间机构签发证书的形式拓展下级中间机构，下级中间机构还可以继续拓展自己的中间机构从而形成一条证书机构连。因此，一个证书机构要么是一个根机构，要么就是可以通过机构链回溯到根机构的中间机构。
链代码（ChainCode）和账本（Ledger）
ChainCode 和 Ledger ，构成了 Hyperledger Fabric 网络中的核心。
ChainCode 和合约 （Contract）的关系，可以理解为一个 ChainCode 包含了多个 Contract， Contract 包含了控制交易的逻辑，而 ChainCode 则负责打包 Contract 并将其部署到网络节点上并为客户端应用所调用。
账本包含了两个独立的模块，一个是区块链（Blockchain），这个是存储了整个不可被改变的交易历史的数据结构，和一个全局状态（world state），保存了由历史交易产生的状态的当前的值，通过这个模块，可以直接查询到账本中的当前状态值而不同通过回溯整个账本去计算。
这里涉及到一个认证策略（endorsement policy）， 认证策略是关联在每一个 chaincode 中，并应用到所有 chaincode 所包含的 contract 中的，其代表的是一个由该合约所产生的交易必须要经过网络中指定的机构（ organization）的签名才能被网络标志位有效的交易。
注意，所有的由排序节点分发的块都会被拼接到网络中的账本（ledger）中，不管是有效的还是无效的，只是增加了一个有效和无效的标志
排序服务（Ordering Service）
排序节点的引入是为了解决分布式区块链中，例如以太坊或者比特币这种没有权限限制的网络中，由于各个节点同时参与交易的排序和块的打包，最终可能导致分叉（fork）的情况。多个排序节点共同构成一个排序服务。
- 排序节点和通道配置
排序节点的另一个作用就是维护一个允许创建渠道（channel）的组织列表，这个列表即所说的联盟（consortium），这里列表是保存在排序系统渠道配置（orderer system channel 或
ordering system channel）中的。默认这个列表和列表依赖的配置，只能被系统管理员修改。
排序节点也限制了对各个通道的读，写和配置的权限。修改一个通道的配置元素需要对应于创建时所对应的政策和管理员设置。一个配置事务（Configuration Transaction）需要经过排序节点的验证后，才能被分发到渠道中的节点中，最终才能被渠道中的节点所验证并执行。
- 排序节点和身份验证
与区块链网络交互的所有内容（包括peer，application，admin和排序节点）都会从其数字证书及其成员服务提供商（MSP）定义中获取对应的组织身份。
和 peer 节点一样， 排序节点也属于一个组织机构
- 排序节点在交易流程中的作用
一个应用在需要对网络中的账本进行修改的时候，首先请求网络中部署了智能合约的节点，
获取对应的请求响应（proposal response），在将这些返回的响应传递给排序节点进行验证，打包和分发排序节点在接收到应用的请求数据时，对来自各个应用的交易进行验证，并对其排序并打包到一个块中，之后将打包的数据分发到通道中。
排序节点所连接的 peer 节点，在接收到排序节点分发的块之后，对其进行验证，并最终更新到当前节点保存的通道中的账本的副本中，并返回响应给请求的应用。
Fabric 提供了 solo， Raft 和 Kafka 模式的排序服务的实现。具体可查看官网解释。
成员关系（Membership）
在 HyperLedger Fabric 中，PKI 提供了一个可验证的身份信息，这些身份信息可以用来验证节点是否网络中的被信任的成员。
而这就是MSP（Membership Service Provider）所做的事情。MSP验证了哪个根证书机构（Root CA）或者中间证书机构（Intermediate CA）可以用来定义一个组织的成员关系。此外，MSP还定义了一个成员在一个网络中所扮演的角色并设置在了网络或者渠道中的访问权限（例如：读，写）。
MSP的配置被广播到所有MSP所代表的组织的成员所参与的通道中，这个称为渠道MSP（Channel MSP）。与此同时，像节点和排序节点，也会维护一个MSP，用于验证当前通道之外的成员信息，来定义对特定资源的访问权限（例如：是否可以在节点上部署ChainCode）。
本地和渠道MSP之间的关键区别不在于它们如何运作 - 都是将身份转变为角色 - 而是他们的作用范围。
MSP 大致分为四种：
- 网络MSP ：定义了网络中的成员
- 通道MSP ：定义了通道中的成员
- 节点MSP ：只用于定义该MSP的节点中，最常见的使用场景是 chaincode 在节点中的安装
- 排序节点MSP ：只用于定义该MSP的节点中，用于列举信任的节点和角色
成员关系的验证，除了 CA 和 MSP 之外，还包括了其他的组件。
功能描述参考官网对 Membership 的详述
