区块链学习
一、基本概念
1、区块链的基本概念：
区块链实际是一种分布式数据存储、点对点传输（P2P）、共识算法、加密算法等计算机技术的新型应用模式。具有分布式对等、数据块链式、不可伪造和防篡改、透明可信、高可靠等特征。
区块链部署模型：
1、公有链：任意客户都能使用、任意节点均可接入，所有节点共同参与共识和读写数据，具有较强的去中心化特征，比特币和以太坊
2、联盟链：只有利益相关的特定区块链服务客户才能使用，节点只有经过授权许可后方可接入网络，接入节点按照规则参与共识和读写数据，具有较弱的去中心化的特征，如Hyperledger Fabric
3、私有链：仅由单个区块链服务客户使用，仅有授权的节点才能接入，并按照规则参与共识和读写数据
目前，区块链系统包括共识机制、安全机制、存储机制、P2P通信机制、智能合约等核心技术
2、共识机制
在区块链系统中，共识机制是指实现不同信任主体节点之间建立信任、获取权益的数学算法，提供给分布式网络参识节点以用于确认交易动作引起的账本中的状态数据变化，并且能够达成最终一致性
常见的共识机制包括PoW、PoS、DPoS、PBFT等
PoW(Proof of Work,工作量证明) // 待补充
PoS(Proof of Stake，权益证明)
DPos(Delegated Proof of Stake,股份授权证明)
PBFT(Practical Byzantine Fault Tolerance,实用拜占庭容错)
3、P2P
PeerToPeer 节点之间直接通过交换方式共享信息，又被称为对等计算
Hyperledger Fabric采用gRPC库与Gossip消息协议构建P2P通信机制
4、智能合约
HyperledgerFabric采用Docker容器等作为智能合约执行的虚拟机，所有智能合约（Hyperledger Fabric称之为chaincode，即链上代码或链码）都必须实现Init()与Invoke()方法。
二、Peer节点
peer节点提供背书、交易验证、提交账本等服务功能的逻辑节点（包括Endorser背书节点、Committer记账节点）
1、Endorser背书节点
负责接收来自客户端的签名提案消息请求，检查消息后模拟执行交易提案，并对模拟执行结果签名背书，即使用私钥对请求提案、状态变更（读写集）等签名，表示Endorser背书节点认为此次交易是合法有效的，然后将签名背书信息等打包成提案响应消息回复给客户端；
2、Committer记账节点
负责检查交易消息结构的完整性与合法性、调用VSCC验证交易背书策略、执行MVCC检查读写集冲突等，标记交易的有效性并提交账本，更新本地账本数据库与文件，包括区块数据文件、隐私数据库、区块索引数据库、状态数据库、历史数据库等。
三、Orderor节点
Orderer排序节点同样属于逻辑节点，负责管理系统通道与应用通道，维护通道账本与配置，提供Broadcast交易广播服务、Orderer共识排序服务、Deliver区块分发服务等
Orderer节点通过Broadcast()服务接口接收与处理交易消息请求（普通交易消息与配置交易消息），过滤检查后提交共识组件进行排序，并添加到本地待处理的缓存交易消息列表，按照约定的交易出块规则（如配置出块时间、配置出块字节数限制、通道配置消息单独出块等）切割打包成新区块，再保存到本地账本的区块数据文件中
Orderer节点通过Deliver()服务接口接收与处理区块请求消息，从本地账本中获取请求范围内的区块数据回复给请求节点
四、客户端Client
1、Fabric-CA客户端
负责节点注册登记，包括登记注册用户信息、获取注册证书与私钥信息等；
2、Fabric客户端
负责网络配置与节点管理，包括初始化与更新配置、启动和停止节点等。同时，还负责通道管理（创建、更新、查询等）与链码生命周期管理（安装、实例化、调用、升级等），能够通过Peer节点服务客户端发送消息给Endorser节点与Orderer节点请求处理，包括交易背书、创建通道、更新通道配置、交易排序、请求区块数据等。负责与其他服务节点进行交互，提供配置操作、通道操作、链码操作、节点操作、日志操作等相关API接口，支持开发丰富的应用程序
五、CA节点
CA节点CA（Certificate Authority）节点类似于证书机构，提供用户身份注册服务，基于数字证书与标准的PKI服务管理Fabric网络中的成员身份信息，管理证书生命周期如创建、撤销、认证等操作，以及身份鉴别与权限控制功能，包括Ecerts（身份证书）、Tcerts（交易证书）等。目前，Fabric中的身份证书符合X.509标准规范[17]，并且基于ECDSA算法生成公钥与私钥。通常情况下，任何合法的成员实体都需要在接入网络前获取认证签署的身份证书等，而不需要在运行过程中一直访问CA节点。因此，Fabric-CA节点是相对独立的组件，不会在网络运行时影响到其他流程和节点的状态
六、Gossip消息协议
Gossip消息协议（流言算法）[22]自20世纪70年代提出到现在已经有40多年的历史，该算法简单高效，具有良好的可扩展性和鲁棒性，被广泛应用于分布式定位、数据库复制等领域，如分布式系统Cassandra用于实现集群失败检测与负载均衡。Gossip消息协议规定，节点采用随机选择近邻节点的方式进行路由并交换信息，近邻节点重复这一过程将其传播给没有数据的节点，直到所有节点收到数据为止。这种方式可以有效避免拥塞和路径失效问题，同时拥有节点数对数量级的较低时间复杂度，常见的数据传输模式包括push模式（主动推方式）、pull模式（主动拉方式）和push/pull模式（推拉结合方式）。
Fabric中的Gossip消息模块可以提供Gossip消息协议服务，负责在应用通道中的组织（通常对应于一个MSP对象）内探测节点成员、在节点间分发区块数据以及同步状态等，用于管理新加入的通道节点，发送成员关系请求消息获知其他节点信息，在组织内分发数据（区块数据与隐私数据）与同步状态，同时使用反熵算法周期性地从其他节点拉取本地缺失的数据（区块数据与隐私数据），以确保组织内所有节点上账本数据的一致性。
七、共识（Consensus）
Hyperledger Fabric达成共识的过程包含在交易背书阶段、交易排序阶段、交易验证阶段等。
共识服务：通过Endorser背书节点模拟执行提案消息，请求对模拟执行结果等签名进行背书，再提交到Orderer节点共识组件（Solo、Kafka等）对交易进行排序并打包出块，然后交由Committer记账节点验证交易并提交账本。同时，基于Gossip消息协议提供P2P网络通信机制，实现高效数据分发与状态同步，确保节点账本的一致性
1、背书阶段
Endorser背书节点负责检查签名提案消息并模拟执行，对模拟结果读写集等添加签名，表示予以背书支持，客户端只有收集到满足条件数量的背书信息之后，才允许构造交易请求提交给Orderer节点，同时会在交易验证阶段检查这些背书信息是否满足指定的背书策略，以确保交易背书的合法性；
2、排序阶段
目前，Orderer节点支持两类共识组件，包括Solo类型（用于单节点测试）与Kafka类型（基于Kafka集群）。这两类共识组件都是先利用Golang通道、Kafka集群等对接收到的合法消息（符合通道处理要求）进行排序，对交易顺序等达成一致再添加到缓存交易消息列表中，并按照约定的交易出块规则切割打包构造新区块，以保证全局一致的区块顺序、区块内交易顺序与交易数量等。另外，Fabric 0.6中测试的sbft共识组件则是参识节点先将交易分割打包到区块中，经过sbft共识算法（简外的BFT算法）确定区块顺序的一致性以达成共识，最后写入账本；
3、验证阶段
Committer记账节点负责验证排序后的交易数据，包括检查交易结构格式的正确性、调用VSCC链码验证交易背书签名是否满足预设指定的背书策略、执行MVCC检查交易数据读写集的版本冲突等，标记交易的有效性，并提交到区块数据文件中，建立索引更新到区块索引数据库
八、成员关系服务提供者
MSP（Membership Service Provider，成员关系服务提供者或成员关系服务模块）是Fabric中提供身份验证的实体抽象概念，基于X.509标准的身份证书实现对不同资源实体（成员、节点、组织、联盟等）进行认证等权限管理操作，同时提供数字签名算法与身份验证算法。Fabric中属于同一个MSP组件内的成员都拥有共同信任的根证书，支持共享敏感数据。一个组织或联盟都可以对应一个层级化的MSP实例，通常一个MSP对象负责一个组织或联盟对象。MSP对象包括MSP名称ID、信任的根证书、中间证书列表、管理员身份证书、组织单元列表、CRL（证书撤销列表）等。
九、交易与区块
1、交易
Transaction，或称为事务，是Fabric的核心概念，通常是指通过调用链码（智能合约）改变账本状态数据的一次操作。对账本状态的变更是用交易结果读写集来描述的，将交易集合经过Orderer节点排序后按规则打包到区块中。目前，Hyperledger Fabric包括普通交易消息、配置交易消息等，其中，普通交易消息封装了变更账本状态的执行交易结果，需要经过排序后打包成区块，配置交易消息则用于创建新的应用通道或更新通道配置，通常在排序后单独打包成区块，同时将最新配置区块号更新到最新的区块元数据中以便于索引查找。
2、区块
Block是指一段时间内发生的交易集合，经排序后按规则打包后并添加签名、哈希值、时间戳与其他元数据所构成的数据结构，而区块链就是以区块为基础按照时间顺序连接构成的链状数据结构。Fabric中的区块结构（Block类型）包括区块头Header、交易数据集合Data以及区块元数据Metadata三个部分，其中，区块头Header封装了区块号、前一个区块的哈希值、当前区块的哈希值，交易数据集合Data封装了打包的交易集合，区块元数据Metadata封装了如下4个元数据索引项，其中：
□ BlockMetadataIndex_SIGNATURES：区块签名；
□ BlockMetadataIndex_LAST_CONFIG：最新配置区块的区块号；□BlockMetadataIndex_TRANSACTIONS_FILTER：最新交易过滤器，封装了交易数据集合Data中所有交易对应的交易验证码，标识其交易的有效性。
□ BlockMetadataIndex_ORDERER:Orderer配置信息，如Kafka共识组件的初始化参数。
十、合约
链码（Chaincode）链码（Chaincode）或链上代码就是Hyperledger Fabric中的智能合约，分为系统链码和用户链码。
通常情况下，链码要经过安装和实例化（部署）步骤之后才能正常调用，同时必须实现Chaincode类型接口的Init()方法与Invoke()方法。
系统链码在节点启动或初始化新链结构（节点加入通道、节点启动恢复等）时完成部署，用于支持配置管理、背书签名、链码生命周期管理等系统功能，并运行在goroutine中，目前支持如下5类系统链码。
CSCC（Configuration System Chaincode）：配置系统链码，负责管理系统配置，支持的命令包括JoinChain节点加入应用通道、GetConfigBlock获取通道配置区块、UpdateConfigBlock更新通道配置区块、GetChannels获取节点加入的通道列表等；
ESCC（Endorsement System Chaincode）：背书管理系统链码，负责对模拟执行结果背书签名，并创建提案响应消息，同时管理背书策略；
LSCC（Lifecycle System Chaincode）：生命周期系统链码，负责管理用户链码的生命周期，如打包、安装、实例化（部署）、升级、调用、查询等链码操作；
QSCC（Query System Chaincode）：查询系统链码，负责查询账本和区块链信息，支持的命令包括GetChainInfo获取区块链信息、GetBlockByNumber获取指定区块号的区块数据、GetBlockByHash获取指定区块头哈希值的区块数据、GetTransactionByID获取指定交易ID的交易数据、GetBlockByTxID获取指定交易TxID的区块数据等；
VSCC（Verification System Chaincode）：验证系统链码，负责对交易数据进行验证，并检查签名背书信息是否满足预定的背书策略。
用户链码是用户编写的智能合约代码，通常运行在Docker容器中，支持打包、安装、实例化（部署）、升级、调用等链码操作
十一、账本
Fabric账本（Ledger）提供了多个数据库与文件用于存储账本数据，且每个通道都拥有物理或逻辑上独立的账本对象，具体如下。
idStore数据库：保存账本ID信息，将账本ID与创世区块字节数组构成的键值对保存到LevelDB数据库中；
区块数据文件：保存所有区块数据，用于存储所有交易状态发生变更的历史记录；
隐私数据库：保存隐私数据（明文），支持LevelDB数据库；
状态数据库：记录最新的世界状态（World State），即状态变更结果，保存有效交易的公共数据、隐私数据哈希值与隐私数据，支持LevelDB与CouchDB数据库；
历史数据库：记录交易（经过Endorser背书的有效交易）中每个状态数据的历史变化信息，支持LevelDB数据库
区块索引数据库：存放区块索引信息，支持按照区块头哈希值、区块号、区块交易ID检查区块的文件位置，支持按照交易ID、区块号与交易序号检查交易的文件位置等，支持LevelDB数据库；
transient隐私数据库：Fabric 1.1.0开始支持隐私数据集合的实验版本新特征（1.2.0及后续版本支持），用户可以在智能合约的交易执行中获取与保存隐私数据。Peer节点将通过Gossip协议传播的隐私数据交由transient隐私存储对象暂时保存到本地的transient隐私数据库（LevelDB），并在将区块更新提交到账本的隐私数据库时，再自动清理相关的隐私数据记录，以保持数据的时效性。
十二、Fabric交易流程
Hyperledger Fabric正常启动后，用户基于Client节点从Fabric CA节点或通过工具（cryptogen等）生成合法的身份证书、签名私钥等文件，获得合法的节点身份，认证之后进入Fabric网络。此时，用户就能正常发送交易到网络中请求处理
① 发送签名提案消息到Endorser背书节点请求处理Client节点构造签名提案消息（SignedProposal类型），通过调用Endorser背书服务客户端的ProcessProposal()接口，提交该消息到Endorser背书节点，请求模拟执行交易提案并签名背书。
② Endorser背书节点模拟执行交易提案并签名背书Endorser背书节点收到签名提案消息之后，进行如下处理。
□ 检查签名提案消息的格式合法性与签名有效性，包括通道头部、签名头部、签名域、交易ID、消息扩展域的ChaincodeId属性与PayloadVisibility可见性模式等；
□ 检查提案消息的创建者是否满足指定通道上的通道访问权限，即/Channel/Application/Writers写权限；
□ 检查并启动链码容器以模拟执行交易提案，并将模拟执行结果暂时保存在交易模拟器中，等待排序共识与交易验证，而不是直接更新到账本中。其中，交易模拟执行结果采用状态数据读写集（读数据的键和版本、写数据的键值）记录交易造成的状态变更结果；
□ 调用ESCC系统链码对该提案消息的模拟结果读写集等进行签名背书。
③ Endorser背书节点向客户端返回提案响应消息，并分发隐私数据明文。Endorser背书节点基于背书信息、模拟执行结果等构造提案响应消息（ProposalResponse类型），并回复给请求客户端。
目前，模拟执行结果读写集包含公有数据（包括公共数据与隐私数据哈希值）与私有数据（或隐私数据）。其中，公有数据交由Orderer节点进行排序出块，再提交到账本区块数据文件，并广播到该通道上的所有节点。如果模拟执行结果中还存在有效的隐私数据明文，则Endorser背书节点通过Gossip消息协议将隐私数据发送给通道内授权的其他节点（由隐私数据集合配置的签名策略决定），交由transient隐私数据存储对象暂时保存到本地的transient隐私数据库（LevelDB），并在提交账本时存储到隐私数据库（LevelDB），同时清理transient隐私数据库中的过期数据。
④ 处理提案响应消息Client节点解析Endorser背书节点回复的提案响应消息，获取背书结果并检查提案响应消息状态的合法性，以判断是否收集到了足够多的符合要求的背书签名信息。
⑤ 发送交易数据给Orderer服务节点请求排序当收集到足够多数量的符合要求的Endorser背书签名之后（由背书策略决定）,Client节点基于模拟执行结果、背书签名等构造合法的签名交易消息（Envelope类型），通过Broadcast()服务接口将该消息提交给Orderer节点，请求交易排序处理。其中，配置交易消息不需要经过Endorser节点处理。
⑥ Orderer服务节点对交易进行排序并构造新区块Orderer排序节点提供Solo类型（用于单节点测试）、Kafka类型（支持CFT容错）等共识组件，对符合通道处理要求的合法交易消息（普通交易消息、配置交易消息等）进行排序并达成一致观点，并对一段时间内接收的一批交易消息按照打包交易的出块规则（出块周期时间、区块字节数限制、配置交易单独出块等）构造新区块，创建应用通道或更新通道配置，同时提交账本。
⑦ Leader主节点请求Orderer服务节点发送通道账本区块Leader主节点通过Deliver()服务接口代表组织从Orderer节点请求通道账本上所有的区块数据，并通过Gossip消息协议分发到组织内的其他Peer节点。如果请求的区块数据不存在，则Orderer节点默认阻塞等待，直到指定区块创建完成并提交账本，再将该区块发送给Leader主节点。
⑧ Committer记账节点验证交易并提交账本Committer记账节点对区块与隐私数据（明文）执行如下检查，并提交至本地账本。如果不存在隐私数据明文，则跳过隐私数据的相关检查与提交账本的步骤。
□ 检查交易消息格式的正确性、签名合法性、交易内容是否篡改、消息头部的合法性等。
□ 调用VSCC系统链码，验证收集的签名背书结果是否符合指定的背书策略。
□ 对模拟结果中公有数据（即区块数据，含有公共数据与隐私数据哈希值）的读写集执行MVCC检查，针对单个键查询、键范围查询、隐私数据哈希值三种情况，检查读数据版本与交易时的账本是否一致，即是否存在读写冲突，并将存在冲突的交易标记为无效交易。
□ 验证模拟结果中隐私数据的正确性，遍历区块中有效交易的隐私数据读写集哈希值，取出对应交易的原始隐私数据读写集明文，重新计算其哈希值并对两者进行比较。如果两者完全相同，则说明该交易的隐私数据是真实有效的。
□ 保存所有的区块数据（即公有数据）到区块数据文件中，保存所有的私有数据（即隐私数据）读写集到隐私数据库（LevelDB）中，建立区块索引信息到区块索引数据库，将最新的有效交易数据（包含公共数据读写集、隐私数据读写集、隐私数据读写集哈希值）更新到状态数据库，最后将区块数据中经过Endorser背书的有效交易数据同步到历史数据库。同时，清理transient隐私数据库中的过期数据。
⑨ Leader主节点分发数据与状态同步Leader主节点基于Gossip消息协议将区块数据分发到组织内的其他节点上。同时，节点之间通过反熵算法等机制主动拉取缺失的数据（区块数据与隐私数据）、节点身份信息等，以确保组织内所有节点上的账本数据等信息保持同步。
⑩ Committer记账节点验证交易并提交账本（同步骤⑧）至此，Hyperledger Fabric系统上的一次完整交易处理流程即告结束。
