hyperledger fabric项目概述

Hyperledger，中文名为超级账本。是Linux基金会于2015年发起的推进区块链数字技术和交易验证的开源项目。Hyperledger的目标是让成员共同合作、共建开放平台以满足来自多个不同行业各种用户的需求，同时能大大简化业务流程。

随着hyperledger项目的不断扩大，单一的项目无法满足业务的需求，因此hyperledger逐步由一个单一的项目发展成一个项目组。而hyperledger fabric就是其中一个项目。hyperledger项目组主要的项目如下：
在这里插入图片描述

fabric的特点

相对于公有链，fabric更适合于企业级业务。
高度模块化和可配置的结构，可为各行各业的业务提供创新性、多样性和优化。
支持通用编程语言编写智能合约。
参与者的身份不能是匿名或者不可信任的
可拔插共识协议，使得平台能够更有效地进行定制，以适应特定的业务场景和信任模型
不需要原生加密货币的共识协议来激励挖矿或者推动智能合约的执行，降低了系统的风险，并且可以与其他分布式系统大致相同的运营成本部署平台

fabric的关键组件

节点(Peer)

节点是区块链交易处理和账本维护的主体，主要负责参与共识过程和通过执行链码实现对账本的读写操作。Peer根据功能的不同可以分为背书节点(Endorser Peer)、提交节点(Committer Peer)、根据通信不同分为锚节点(Anchor Peer)、主节点(Leader Peer)。

背书节点：背书节点负责根据事先设定策略对交易进行签名背书，在链码实例化的时候设置背书策略，指定哪些节点用于背书。当客户端向节点发起交易背书时，该节点才有背书功能，否则只是普通的记账节点。
提交节点：该节点负责维护状态数据和账本的副本。
锚节点：锚节点是随通道存在的，是能被其他通道发现的节点，每个通道上有一个或多个锚节点。
主节点：主节点负责与Orderer通信，把共识后的区块传输到其他节点。

排序服务(Orderer)

排序服务为区块链网络中不同通道产生的交易进行排序，并广播给节点。排序服务独立于节点流程之外，并以先到先处理的方式为网络上所有通道做交易排序。排序服务是以可插拔组件的方式实现的，目前默认实现了solo、Kafka和Raft。排序服务与整个网络相绑定，包含与每个成员相关的加密材料。

排序服务又可以称为共识，是计算机科学深入研究的一个领域，有许多方法可以实现它，每种方法都有不同的权衡。例如PBFT（实用拜占庭容错）可以为文件副本提供一种相互通信的机制，使其能够保持各个副本的一致性，即使在发生损坏的情况下也是如此。又如在比特币中，通过工作量证明（POW）进行排序，在这个过程中，相互竞争的计算机竞相解决一个密码难题，这个谜题定义了所有过程随后建立的顺序。

客户端（Client）

客户端是与fabric网络组件发送请求进行交行的接口，包括：

Fabric-CA客户端：负责节点注册登记，包括登记注册用户信息、获取注册证书与私钥信息等。
- CA节点：CA(Certificate Authority)节点类似于证书机构，提供用户身份注册服务，基于数字证书与标准的PKI服务管理fabric网络中的成员身份信息，管理证书生命周期如创建、撤销、认证等操作，以及身份鉴别与权限控制功能，包括Ecerts（身份证书）、Tcerts（交易证书）等。
Fabric客户端：负责网络配置与节点管理，包括初始化与更新配置、启动和停止节点等。同时，还负责通道管理（创建、更新、查询等）与链码生命周期管理（安装、实例化、调用、升级等），能通过Peer节点服务客户端发送消息给背书节点与排序服务请求处理，包括交易背书、创建通道、更新通道配置、交易排序、请求区块数据等。
- 目前fabric客户端包括CLI命令行和多种语言的SDK(例如：Node.js、Go、Java、Python等)。SDK提供了与其他服务节点进行交互的API接口，包括了配置操作、通道操作、链码操作、节点操作、日志操作等。支持开发丰富的应用程序。

链码(Chaincode)

链码就是fabric的智能合约，其应用了一种新的架构：执行—排序—验证。解决了顺序执行模型面临的弹性、灵活性、可伸缩性、性能和机密性的问题。并且在交易达成最终一致前执行交易。其执行交易的执行流程分为三个步骤：

执行一个交易并检查其正确性，从而给它背书。
通过共识协议将交易排序
提交交易到账本前先根据特定的应用程序的背书策略验证交易

fabric的智能合约分为系统链码和用户链码。通常情况下，链码要经过安装和实例化步骤之后才能正常调用，同时必须实现Chaincode类型接口的Init()方法与Invoke()方法。

系统链码在节点启动或者初始化新链结构（节点加入通道、节点启动恢复等）时完成部署，用于支持配置管理、背书签名、链码生命周期管理等系统功能，并运行在goroutine中，有一下五类系统链码：
- CSCC（Configuration System Chaincode）：配置系统链码，负责管理系统配置，支持的命令包括JoinChain节点加入应用通道、GetConfigBlock获取通道配置区块、UpdateConfigBlock更新通道配置区块、GetChannels获取节点加入的通道列表等。
- ESCC（Endorsement System Chiancode）：背书管理系统链码，负责对模拟执行结果背书签名，并创建提案响应消息，同时设置管理背书策略。
- LSCC（Lifecycle System Chaincode）：生命周期系统链码，负责管理用户链码的生命周期，如打包、安装、实例化、升级、调用、查询等链码操作。
- QSCC（Query System Chaincode）：查询系统链码，负责查询账本和区块链信息，支持的命令包括：GetChainInfo获取区块链信息、GetBlockByNumber获取指定区块号的区块数据、GetBlockByHash获取指定区块头哈希值的区块数据、GetTransactionByID获取指定交易ID的交易数据、GetBlockByTxID获取指定交易TxID的区块数据等。
- VSCC（Verification System Chaincode）：验证系统链码，负责对交易数据进行验证，并检查签名背书信息是否满足预定的背书策略。
用户链码是指用户编写的智能合约代码，通常运行在Docker容器内，支持打包、安装、实例化、升级、调用等链码操作。

通道（Channel）

通道是用于数据隔离和保密的一个私有区块链。通道中的节点共享该通道的账本，交易方必须通过该通道的授权才能与账本进行交互。通道是由一个配置区块来定义的。 fabric的通道分为应用通道和系统通道：

应用通道：保存应用程序的配置等，为应用程序处理交易提供隔离机制，在指定通道的组织成员间共享账本数据。客户端向Orderer节点发送通道配置交易信息创建应用通道，并生成该通道的创世块，同时还可以提交新的通道配置交易信息以更新通道配置。另外，应用通道账本上还保存了应用通道的创世块、配置区块与普通交易区块。fabric创建或更新应用通道时，必须制定通道配置交易文件。
系统通道：保存Orderer配置（共识组件类型、服务地址、出块规则、通道数量等）、系统通道的创世块及其更新的配置区块。基于系统通道配置与应用通道配置交易消息创建新的应用通道，并将其注册到Orderer的多通道注册器Registrar对象上，同时启动通道共识组件链对象，从而能够正常处理应用通道上的交易消息请求。

账本（Ledger）

账本记录着业务的当前状态，就像一个交易日记。它呈现了一组账本状态的当前值，同时记录了促成了账本状态的交易历史。fabric的账本由世界状态和区块链两部分组成。

世界状态：世界状态是一个数据库，它存储了一组账本状态的当前值。通过世界状态，程序可以直接访问一个账本状态的当前值，不需要遍历整个交易日志来记录当前值。默认情况下，账本状态是以键值对的方式表示的。
区块链：区块链是交易日志，它记录了促成当前世界状态的所有改变。交易被收集在附加到区块链的区块中，能帮助我们理解所有促成当前世界状态的改变历史。其中每个区块结构如下：
- 区块头：区块头包含三个字段，这些字段在创建一个区块时被写入：
  - 区块编号：编号从0开始，每在区块链上增加一个新的区块，编号就会加1
  - 当前区块的哈希值：当前区块中包含所有交易的哈希值
  - 前一个区块头的哈希值：区块链中一个区块头的哈希值
- 区块数据：这部分包含了一个有序的交易列表。区块数据是在排序服务创建区块时被写入的：
  - 交易头：记录了关于交易的一些重要元数据，比如相关链码的名字以及版本
  - 交易签名：包含了一个由客户端应用程序创建的加密签名。该字段是用来检查交易细节是否被修改，因为交易签名的生成需要用到应用程序的私钥。
  - 交易提案：负责对应用程序提供会给智能合约输入参数的进行编码，随后该智能合约生成提案账本更新。在智能合约运行时，这个提案提供了一套输入参数，这些参数同当前的世界状态一起决定了新的账本的世界状态。
  - 交易响应：它是以读写集的形式记录下世界状态之前和之后的值。交易响应是智能合约的输出，如果交易验证成功，那么该交易会被应用到账本上，从而更新世界状态。
  - 交易背书：它指的是一组签名交易响应，这些签名都来自背书策略规定的相关组织，并且这些组织的数量必须满足背书策略的要求。
- 区块元数据：这个部分包含了区块被写入的时间、区块写入者的证书、公钥以及签名。随后，区块的提交者也会为每一笔交易添加一个有效或无效的标记，但由于这一信息与区块同时产生，所以它不会被包含在哈希中

账本具有以下特征：

查询和使用基于键的查找更新账本、范围查询和组合键查询
使用富查询语言的只读查询（需使用CouchDB作为状态数据库）
只读历史查询——查询某一个键的账本历史记录
交易由链码中读取的键/值版本和链码中写入的键/值的版本组成
交易包含每个背书节点的签名，并提交给排序服务
交易排序后进入区块，并从排序服务广播到通道的节点上
节点根据背书策略验证交易并执行这些策略
在添加区块之前，执行版本控制检查，以确保所读取的资产的状态自链码执行时间以来没有更改
一旦交易被验证和提交，就不可更改
通道的账本包含一个定义的了策略、访问控制列表和其他相关信息的区块配置
通道包含成员服务提供者实例，允许从不同的证书颁发机构派发加密材料

区块链网络

区块链网络是为应用程序提供账本和智能合约服务的技术基础设施。首先，智能合约用于生产交易，这些交易随后被分发到网络中的每一个节点，并在每个节点的账本副本上记录下来并且是不可篡改的。这个应用程序的用户可能是客户端应用的最终用户，或者是一个区块链网络的管理员

在大多数情况下，多个组织作为一个联盟聚集在一起形成网络，它们的权限由一组策略决定，这些策略在最初配置网络时由联盟决定。网络的策略也可以进行改变，这取决于联盟中组织的协议

fabric架构

fabric 逻辑架构

在这里插入图片描述 fabric的架构分为网络层、核心层和接口层。

核心层

成员服务（Membership Services）：提供成员服务功能，包括注册、登记、申请证书等功能。节点只有获得证书才能加入到区块链网络中。在1.0版本以后，由可拔插的Fabric CA组件进行处理。
区块链服务（BlockChain Services）：负责账本的计算和存储、节点间的排序服务、背书验证管理以及账本存储方式等功能的实现，是区块链的核心组成部分，为区块链的主体功能提供了底层支撑。
链码服务（Chaincode Services）：链码和底层账本是解耦的，链码的更新不会影响原有的数据。运行与单独的容器内，安装和实例化后通过gRPC与同一通道内的节点进行连接。

接口层

接口层给第三方应用提供API进行调用，方便开发。可以通过SDK或者CLI方式进行安装并调用链码。同时通过Events监听区块链网络中发生的事件。

网络层

fabric使用gRPC和Gossip协议进行网络通信。

fabric的网络结构

在这里插入图片描述 N：fabric网络、R：组织、A：应用程序、CA：CA节点、S：智能合约、L：账本、P：节点、C：通道、O：排序服务

该网络中有R1、R2、R3、R4四个组织。其中R4是为初始网络管理员，R1为后添加的网络管理员。R1和R4有着相同的网络权限。O4为R4组织创建的排序服务，对通道C1和C2的的交易进行排序。R1和R2在通道C1中、R2和R3在通道C2中。这两个通道内的数据相互隔离、互不可见。L为节点P上的账本、S为节点P上的智能合约。Ax是对应组织的应用程序。CAx为对应组织的证书认证机构。

fabric 交易流程

在这里插入图片描述 1. 客户端发送签名提案消息到背书节点，请求背书节点进行处理。
Client节点构造签名提案消息（SignedProposal类型），通过调用背书服务客户端的ProcessProposal()接口提交该消息到背书节点，请求模拟执行交易提案并签名背书。
2. 背书节点模拟执行交易提案并签名背书。有以下操作：

检查签名提案消息的格式合法性与签名有效性，包括头部通道、签名头部、签名域、交易ID、消息扩展域的ChaincodeId属性与PayloadVisibility可见性模式等。
检查提案消息的创建者是否满足指定通道上的通道访问权限。
检查并启动链码容器以模拟执行交易提案，并将模拟执行结果暂时保存在交易模拟器中，等待排序共识与交易验证，而不是直接更新到账本中。
调用ESCC系统链码对该提案消息的模拟结果读写集进行签名背书。

背书节点向客户端返回提案响应消息，并分发隐私数据明文。
处理提案响应消息。
- 客户端节点解析背书节点回复的提案响应消息，获取背书结果并检查提案响应消息状态的合法性，以判断是否收集了足够多的符合要求的背书签名信息。
发送交易数据给Orderer排序节点请求排序。
- 当收集到足够多符合要求的背书签名之后，客户端节点基于模拟执行结果、背书签名等构造合法的签名交易消息，通过Broadcast()服务接口将该消息提交给Orderer排序节点。请求交易排序。
Orderer服务节点对交易进行排序并构造新区块。
- Ordere排序节点提供solo类型、kafka类型等共识组件，对符合通道处理要求的合法交易信息（普通交易信息、配置交易信息等）进行排序并达成一致观点，并对一段时间内接收到一批交易消息按照打包交易的出块规则构造新区块，创建应用通道或更新配置通道，同时提交账本。
Leader主节点请求Orderer服务节点发送通道账本区块
- Leader主节点通过Deliver()服务接口代表组织从Orderer节点请求通道账本上所有的区块数据，并通过Gossip消息协议分发到组织内的其他Peer节点。
Committer记账节点验证交易并提交账本。
Leader主节点分发数据与状态同步。
- Leader主节点基于Gossip消息协议将区块数据分发到组织内的其他节点上。同时，节点之间通过反熵算法等机制主动拉取缺失的数据、节点身份信息等。以确保组织内所有节点上的账本数据等信息保存同步。
Committer记账节点验证交易并提交账本。