fabric学习过程详细记录二
以下阅读笔记来自阅读《深度探索区块链 HYPERLEDGER技术与应用》
以下所有信息，适用于fabric1.0版本
客户端如何构造配置更新的请求
这个更新请求是如何被处理的，见下图
最后排序服务节点发出去的是一个全量的配置数据信封。（说明，最新配置区块都是全量的）
记账节点收到配置区块后，在提交账本前会检查头类型，发现是配置区块，获取链编号，更新该链原配置块为最新配置区块。
加入通道操作是由客户端应用程序将请求发送给记账节点。
系统链码CSCC，处理节点入链请求JoinChain。检查创世区块合法性，提交者身份验证和权限检查。
检查完毕后会在本地建立账本，节点的本地配置会在成为主节点联系到排序服务节点后同步。若不是主节点则从组织内部其他节点同步，具体过程见第五章。
CSCC（通道相关系统链码）
GetChannels查询某节点加入的通道的列表
GetConfigBlock 返回某节点本地维护的最新配置区块
如何获取最新配置区块？答：所有区块的元数据里都有最新配置区块的索引。从排序服务获取最新区块，解析元数据以获得最新配置区块高度，通过高度访问配置区块即可。
注：目前版本通道创建后不可停止和删除。节点加入通道无法退出。（这里的停止的意思应该是没有准备相应的重启方案。通道可以停止，账本数据暂时不会被销毁，仍旧可以查询数据）
可插拔的排序服务，它的实现方式提供了使用不同共识算法的可能。
目前提供，基于单进程（Solo）的排序服务，基于Kafka的排序服务。
1.4.1版本提供基于raft共识的raft排序服务
还支持SBFT算法
排序服务提供以下链相关的接口
Consenter 定义了后台的排序机制。可以创建新链的接口，内有函数HandleChain（返回处理链上交易的chain对象，传入参数support用于支持交易过滤、分割和区块签名等操作，metadata参数为排序服务相关的元数据。不同通道类型调用的是不同的handlechain函数）P109
Chain 链消息处理接口
其中的函数enqueue会根据排序服务类型提交给不同的链进行处理。（以下截图保护关键词blockcutter.Receiver，用于切割交易）
如果想要增加新的排序服务支持，需要在配置文件里添加相关信息，以及在排序服务节点的initializeMultiChainManager的consenter中添加映射使得能够识别新的参数。
基于单进程的排序服务（solo）
通过go内部并发机制构建一个接受消息的通道sendChan。在start()启动这个服务后，solo类型排序服务就是通过进程不断循环监听，接收发送到sendChan的消息，然后切割，区块写入。
若出现异常，给exitChan通道发送消息。外部应用程序可以监听到异常。
基于Karfka的排序服务
利用Karfka作为消息队列。一个通道对应一个topic。
排序节点在接受消息阶段为生产者。在处理消息阶段为消费者。
(此部分内容等看过karfka的官方文档后再回头看)
系统链的区块只有排序服务节点可见，系统链数据用于存储各种应用通道的配置，联盟链的组织信息等，系统链服务于多链这个功能
基于Karfka排序节点收到加入队列的请求（即收到交易）处理流程如下
Karfka集群是如何处理交易的，参考P114 图6-6
链消息过滤器（排序服务实现的过滤器）
经过过滤器后的消息状态分为转发，接收，拒绝
在交易切割中，会对交易消息过滤，不通过的交易会被丢弃
区块分割的策略，请参考P115（这页提到配置消息和普通消息的部分区别，系统链和应用链的部分区别）
关于多链的意义，以及该分几个部分去解释
第一点和第三点在前面的章节多少已经涉及了，主要看下链码部分。
链码的部署分为安装和实例化两个步骤
安装，实际是将链码打包保存在peer节点，与通道无关。所以，不同链的链码是没有隔离的，同名称和同版本的链码若已存在，可能导致安装失败。
实例化和链码升级。这个是在指定链完成。分为两步，第一步系统链码LSCC（链码生命周期系统链码）计算链码哈希ChaincodeData，存入状态数据库。第二步，文件系统读取链码源码，生成镜像，初始化操作。
镜像文件命名规则：
链码可以运行在同一容器中（也可以不），若如此，通过chainId进行逻辑隔离。
链码容器启动->与背书节点建立gRPC连接。
注意，链码容器本身不保存状态数据，所以说不同链码可以使用相同的链码容器。当链码需要读取或写入数据时，把请求发送给背书节点，让背书节点来处理。
那么背书节点如何知道这个链码是哪个链的呢？链码运行是通过交易号来标识的。而交易提案中包含了链标识信息，所以背书节点可以知道
背书节点内部维护了运行中链码映射表（ChaincodeID->链码运行环境chaincodeRTEnv(封装了Handler)）
Handler内部维护了交易上下文映射表（txID->transcationContext）
通过其中的chainID进行标识，txsimulator用于对不同的链状态数据进行操作。
具体的，链码的部署和调用是如何实现对多链的支持，参考P130
链码的缺陷：
- 业务逻辑线下确认，存在风险。
- 权限管理基于成员，而非基于资源，粒度粗。
链码的生命周期：打包，安装，实例化（instantiate），升级(upgrade)
(现在是打包-----安装----approve-----提交（commit）)
打包相关内容如下
链码包含三部分内容，源码（通过ChaincodeDeploymentSpec或CDS定义），实例化策略（类似背书策略，指明哪些身份可以实例化链码，也是由VSCC去验证），签名（验证身份，内容是否篡改）
链码创建（多所有者签名（创建链码包发送给多个所有者签名），单所有者签名）
链码签名
SignedChaincodeDeploymentSpec封装了ChaincodeDeploymentSpec