Fabric的详细解析，做个记录

一.Hyperledger Fabric概述

Hyperledger Fabric是由IBM公司主导开发的一个面向企业级客户的开源项目。与比特币和以太坊这类公有链不同，Hyperledger Fabric网络中的节点必须经过授权认证后才能加入，从而避免了POW资源开销，大幅提高了交易处理效率。

二.基本概念

Ledger：fabric中的ledger分为两部分内容，一部分是基于文件的存储，基于文件的存储满足区块链不可篡改的特性，此种方式存储基本是采用Merkle Tree，整个存储的方式是只能追加，不能删除和修改。另一部分则是使用数据库进行存储此种方式在fabric中叫做world state，如leveldb、couchdb等K-V数据库，使用此类数据库的优势是数据库只存储当前的最新值，便于业务的拓展，这样可以很快的查找到当前的值，而无需通过遍历的方式来查找。
Channel: 通道，私有的子网络，通道中的节点共同维护账本，实现数据的隔离和保密。每个channel对应一个账本，由加入该channel的peer维护，一个peer可以加入多个channel，维护多个账本。
Org：Orginazation，管理一系列成员的组织。一个channel内可以有多个组织。
Chaincode：链码(智能合约)，运行在节点内的程序，提供业务逻辑接口，对账本进行查询或更新。
Endorse：背书，指一个节点执行了一个交易并对结果进行签名后返回响应的过程。
Ordering Service：排序服务，将交易排序后放入区块中，并广播给网络各节点。
PKI：Public Key Infrastructure(公钥基础设施)，一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。
MSP：Membership Service Provider，成员管理服务，基于PKI实现，为网络成员生成证书，并管理身份。

三.Hyperledger Fabric Network的共识算法

由于fabric是分布式的系统，因此需要共识机制来保障各个节点以相同的顺序状态保存账本，达成一致性。在当前fabric1.4版本中，存在三种共识机制，分别是solo，kafka，Raft。交易的共识包括3个阶段的处理：提议阶段、打包阶段和验证阶段。
fabric的共识分成三个阶段：
①提议阶段：客户端向交易背书节点发送一个交易提案，背书节点通过交易模拟执行后返回给客户端背书结果及签名
②打包阶段：客户端将背书后的结果及签名交给排序节点排序
③验证阶段：排序节点生成区块向全网广播，记账节点收到这些区块后，先验证其正确性，验证通过后存入本地帐本中。

Solo 共识模式
Solo共识模式指网络环境中只有一个排序节点，从Peer节点发送来的消息由一个排序节点进行排序和产生区块；由于排序服务只有一个排序节点为所有Peer节点服务，没有高可用性和可扩展性，不适合用于生产环境，通常用于开发和测试环境。
Raft 共识模式
它是一种基于etcd的崩溃容错（CFT）排序服务。Raft 遵循 “领导者和追随者” 模型，其中每个通道都会选举一个 leader，而且它的决策会复制给follower。和基于 Kafka 的排序服务相比，基于 Raft 的排序服务将变得更容易设置和管理，并且它的设计允许遍布全球的组织成为分散的排序服务贡献节点。
详情看这篇

四.Hyperledger Fabric中的各种节点

客户端节点:
客户端必须连接到某一个peer节点或排序服务节点上才能与区块链网络进行通信。客户端向背书节点（endorser）提交交易提案（transaction proposal），收集到足够背书(可理解为担保)后，向排序服务广播交易提案，进行排序，生成区块。
peer节点(Committer,Endorser,Leader,Anchor):

记账节点(Committer)：所有的peer节点都是记账节点（committer），负责验证排序服务节点区块里的交易，维护状态和Ledger的副本。记账节点使用基于Gossip的p2p数据分发，节点会定期跟其他节点交换信息。如果在这个过程中有节点发生故障，则会从存活的节点中删除这个节点的信息。对于故障节点，还会定时检查是否已经恢复，恢复存活的节点会更新到存活节点列表中。如果有新加入的节点，也能通过节点信息的交换获取到，添加到存活列表中，广播给其他节点。committer节点无法通过配置文件配置，需要在当前客户端或者命令行发起交易请求的时候手动指定相关的committer节点。记账节点可以有多个。
背书节点(Endorser)：部分节点还会执行交易并对结果进行签名背书，充当背书节点（endorser）的角色。背书节点是动态的角色，是与具体链码绑定的。每个链码在实例化的时候都会设置背书策略，指定哪些节点对交易背书后交易才是有效的。并且只有应用程序向它发起交易背书请求的时候才是背书节点，其他时候都是普通的记账节点，只负责验证交易并记账。背书节点也无法通过配置文件指定，而是由发起交易请求的客户端指定。背书节点可以有多个。
主节点(Leader)：peer节点还可以是主节点（leader peer），能与排序服务节点orderer通信，负责从排序服务节点获取最新的区块并在组织内部同步。主节点在整个组织中只能有一个.。
锚节点(Anchor)：peer节点还可以是锚节点（anchor peer），锚节点主要负责代表组织和其他组织进行信息交换。每个组织都有一个锚节点，锚节点对于组织来说非常重要，如果锚节点出现问题，当前组织就会与其他组织失去联系。锚节点的配置信息是在configtxgen模块的配置文件configtx.yaml中配置的。

排序服务节点orderer:
接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给peer节点。排序服务提供的是原子广播，保证同一个链上的节点接收到相同的信息，并且有相同的逻辑顺序。
CA(Certificate Authority 证书颁发机构)节点:
CA节点接收客户端的注册申请，返回注册密码用于用户登录，以便获取身份证书。区块链上的所有操作都需要验证用户身份。

五.交易流程

以下是fabric的经典交易流程，所有涉及到对账本数据更新的操作都是基于这个交易流程来完成的。
在这里插入图片描述

发送交易提案：
应用程序使用相应的 SDK（Node，Java，Python）提供的 API 构建交易提案并提交给相应的背书节点，交易提案中包含：

channelID：通道信息
chaincodeID：要调用的链码信息
timestamp：时间戳
sign：客户端的签名
txPayload：提交的事务本身包含的内容，包含两项：
operation：要调用的链码的函数及相应的参数
metadata：调用的相关属性

背书节点模拟执行交易提案：
在接收来自客户端的消息时，背书节点首先验证客户端的签名clientSig(使用MSP)，然后模拟事务。背书节点会调用链码模拟执行交易提案，产生包括响应值、读写集的事务结果(读写集是交易中记录的主要内容)。这些执行不会更新账本。
返回提案响应：
背书节点会对读写集进行背书(Endorse)签名，生成提案响应(Proposal response)并返回给应用程序。
交易排序：
应用程序根据接收到的提案响应生成交易，并发送给排序服务节点(Orderer节点)。交易请求被提交到Ordering服务节点，该事务将包含读/写集，背书签名和通道ID；Orderer节点接收到事务请求之后，并不需要检查交易中的具体数据，它只是从网络中的所有通道接收交易，按时间顺序对它们进行排序，并创建交易区块。之后广播给同一通道内所有组织的leader节点。
交易验证并提交：
记账节点对接收到的区块进行验证（交易消息结构是否正确、是否重复、是否有足够的背书、读写集版本），通过验证后将结果写入到本地的分类账本中。验证不通过的交易会被标记无效（Invalid）。
账本更新：每个peer节点都会将该块附加到通道链中，并且对于每个有效事务，写集都将提交到当前状态数据库。发出一个事件，以通知客户端应用程序交易（调用）已被不可变地附加到链上，并通知交易是否有效或无效。