超全总结Hyperledger Fabric架构原理

Hyperledger Fabric概述

Hyperledger Fabric是由IBM公司主导开发的一个面向企业级客户的开源项目。与比特币和以太坊这类公有链不同，Hyperledger Fabric网络中的节点必须经过授权认证后才能加入，从而避免了POW资源开销，大幅提高了交易处理效率，满足企业级应用对处理性能的诉求。同时，为了满足灵活多变的应用场景，Hyperledger Fabric采用了高度模块化的系统设计理念，将权限认证模块（MSP）、共识服务模块（Ordering Service）、背书模块（Endorsing peers）、区块提交模块（committing peers）等进行分离部署，使开发者可以根据具体的业务场景替换模块，实现了模块的插件式管理（plug-in/plug-out）。所以，Hyperledger Fabric是一个私有链／联盟链的开发框架，而且系统的运行不需要token支持。

基本概念

Ledger：账本，节点维护的区块链和状态数据库
World state：世界状态，经过数次交易后最新的键值对，世界状态是一个数据库，存储的是账本当前值。作用是能够快速获取账本最新值而不必根据交易日志从头开始计算。世界状态中还有一个属性——版本号，版本号从0开始，每当状态更新时版本号就递增。状态更新时会首先检查版本号，以确保当前状态的版本与背书时的版本一致（避免并发更新）。
Channel: 通道，私有的子网络，通道中的节点共同维护账本，实现数据的隔离和保密。每个channel对应一个账本，由加入该channel的peer维护，一个peer可以加入多个channel，维护多个账本。
Org：Orginazation，管理一系列成员的组织。一个channel内可以有多个组织。
Chaincode：链码(智能合约)，运行在节点内的程序，提供业务逻辑接口，对账本进行查询或更新
Endorse：背书，指一个节点执行了一个交易并对结果进行签名后返回响应的过程。
Ordering Service：排序服务，将交易排序后放入区块中，并广播给网络各节点
PKI：Public Key Infrastructure，一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范
MSP：Membership Service Provider，成员管理服务，基于PKI实现，为网络成员生成证书，并管理身份

Fabric v0.6和v1.x架构差异

节点：在Fabric v1.x中把节点分为peer节点（维护state和ledger）,Order节点（负责共识或者排序账本中的交易）和背书节点（负责执行交易和链码）而在Fabric v0.6中则没有这些概念，只有一个peer节点，peer节点同时完成上述所有的功能。

这样设计的优势

链码（Chaincode）执行信任的可伸缩性，将用户自己开发的链码和系统提供的Order服务拆分，用户开发的链码和系统提供的Order服务不再是一一对应的关系，Order也可以适当容忍错误的出现，增强了系统的鲁棒性。
可扩展性，拆分链码和Order的串行执行，在原有架构中，当链码执行非常耗时的时候，Order将会处于闲置状态，不利于提高系统的吞吐量，拆分以后链码和order可以并行执行。
共识机制可以单独实现（Order）。

Hyperledger Fabric Network的共识算法

在所有peers中，交易信息必须按照一致的顺序写入账本（区块链的基本原则）。例如，比特币通过POW机制，由最先完成数学难题的节点决定本次区块中的信息顺序，并广播给全网所有节点，以此来达成账本的共识。而Hyperledger Fabric采用了更加灵活、高效的共识算法，以适应企业场景下，对高TPS的要求。目前，Hyperledger Fabric有三种交易排序算法可以选择。

SOLO：只有一个order服务节点负责接收交易信息并排序，这是最简单的一种排序算法，一般用在实验室测试环境中。Sole属于中心化的处理方式。

Kafka：是Apache的一个开源项目，主要提供分布式的消息处理／分发服务，每个kafka集群由多个服务节点组成。Hyperledger Fabric利用kafka对交易信息进行排序处理，提供高吞吐、低延时的处理能力，并且在集群内部支持节点故障容错。

SBFT：简单拜占庭算法，相比于kafka，提供更加可靠的排序算法，包括容忍节点故障以及一定数量的恶意节点。目前，Hyperledger Fabric社区正在开发该算法。

各种节点

节点（peer）是区块链的通信实体，是一个逻辑概念，不同类型的多个节点可以运行在同一个物理服务器上。节点主要有以下四种：

客户端节点

客户端必须连接到某一个peer节点或排序服务节点上才能与区块链网络进行通信。客户端向背书节点（endorser）提交交易提案（transaction proposal），当收集到足够背书后，向排序服务广播交易提案，进行排序，生成区块。

普通节点peer

peer节点根据所承担的角色又可以分为记账节点（committer）、背书节点（endorser）、主节点（leader）和锚节点（anchor）。

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

排序服务节点orderer

接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给peer节点。排序服务提供的是原子广播，保证同一个链上的节点接收到相同的信息，并且有相同的逻辑顺序。

CA节点

fabric1.0的证书颁发机构，由服务器和客户端组成。CA节点接收客户端的注册申请，返回注册密码用于用户登录，以便获取身份证书。区块链上的所有操作都需要验证用户身份。

原文链接：https://blog.csdn.net/ASN_forever/article/details/86538915

交易流程

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

1.发送交易提案

客户端发送交易提案（Proposal）到背书节点（peer节点），提案中包含交易所需参数。

2.模拟执行交易提案

背书节点会调用链码模拟执行交易提案(Proposal)，这些执行不会更新账本。

每个执行都会产生对状态数据读出和写入的数据集合，叫做读写集（RWsets），读写集是交易中记录的主要内容。

3.返回提案响应

背书节点会对读写集进行背书(Endorse)签名，生成提案响应(Proposal response)并返回给应用程序。

4.交易排序

应用程序根据接收到的提案响应生成交易，并发送给排序服务节==（Order节点）==。排序服务打包一组交易到一个区块后，分发给各记账节点。

5.交易验证并提交

每个节点会对区块中的所有交易进行验证，包括验证背书策略以及版本冲突验证（防止双花），验证不通过的交易会被标记会无效（Invalid）。

账本更新：节点将读写集更新到状态数据库，将区块提交到区块链上。

6.通知交易结果给客户端

各记账节点通知应用程序交易的成功与否，交易完成。

在Fabric v1.0中，仅在网络上发送签名和读写集，所以可伸缩性和性能得到了优化，因为只有背书者和提交者能看到交易，所以整个网络所需要的信任更低，提供了更高的安全性。

每个ChainCode在部署时，都需要和背书（ESCC）和验证（VSCC）的系统ChainCode关联。

ESCC决定如何对proposal进⾏背书。

VSCC决定事务的有效性（包括背书的正确性）。

交易有两种类型

链码的部署是通过一个带参数的交易来进行的，当执行成功则一个链码被部署到区块链上
调用部署好的链码修改相应的状态并且返回
即两种，部署交易（deploy transaction）和调用交易（invoke transaction）。

blockchain数据结构

状态（State）

区块链最新的未被持久化的状态是带版本号的键值对（KVS），这些状态被智能合约通过put，get方法操作，并且会被日志记录，如果有其他的RDBMS解决方案都可以灵活的替换。

智能合约可以根据key的名字来识别是属于哪个智能合约，原则上一个合约可以读取所有属于它自身的所有key。跨合约交易（cross-transactions）修改state目前还不支持，属于v1后续版本。

账本（Ledger）

账本提供了所有state成功修改和对state不成功修改的尝试的记录。

账本通过order把所有有效和无效的交易构建了一个完全有序的链，而其中的每一个block中的交易又是完全有序的，这样就保证了所有交易的有序性。

账本保存在Peer或者可以保存在order的子集中，二者唯一的区别是Peer中保存的账本可以通过bitmask来区分交易的有效性。

Ledger允许重做所有transactions的历史记录，并且重建state。

fabric系统逻辑结构图

通道channel

fabric的数据存储结构被设计成多账本体系，每个账本在fabric中被称为channel。每个channel中都有一个完全独立的账本。同一个channel中的所有peer节点都保存一份相同的数据。

通道是两个或多个特定网络成员之间进行通信的专用“子网”，用于进行私有和机密事务。通道由成员（组织）、每个成员的锚节点、账本、链码应用程序和排序服务节点定义。网络上的每个交易都是在一个通道上执行的，在该通道上，每一方都必须经过身份验证和授权才能在该通道上进行交易。加入通道的每一个peer都有其自己的身份，由成员服务提供者（MSP）提供。

为通道上的每个成员选择主节点，用于代表该成员与排序服务进行通信。算法会自动选出主节点。共识服务对交易进行排序打包成区块，并把区块它发送给主节点。然后主节点根据gossip协议将区块分发给通道中的成员。

尽管一个锚节点可以属于多个通道，因此能够维护多个账本，但是任何账本数据都不能从一个通道传递到另一个通道。这种用通道对账本进行隔离的方式是由配置链码、成员身份服务和gossip数据分发协议共同定义和实现的。通道上只有具备验证成员资格功能的节点才有权限进行数据分发。这种将peers和账本数据进行通道隔离的方式使得网络成员能够在同一个区块链中进行私密交易（只有自己通道的成员才知道交易信息）。

https://zhuanlan.zhihu.com/p/55341714
https://zhuanlan.zhihu.com/p/38289914

网络及配置

网络则主要包括两大部分：用户证书和链码。

接口主要是fabric sdk，比如fabric java sdk和fabric node sdk。

网络基础配置=证书+yaml文件

网络的基本单元是容器，网络是由一个个的容器组成的，如peer容器，orderer容器等。其中，容器是由yaml文件和证书两部分组成的。

yaml文件和docker联系紧密，所以你需要掌握docker的使用方法。yaml文件描述了peer的配置，而peer是网络的重要组成部分，所以如何实现动态的增加用户(peer\user)，还得需要使用kubernates进行管理。

在用户证书这部分，由于官方1.1版本的的例子中使用的是cryptogen二进制工具，意思就是说官方1.1版本的例子只能安装事前配置的用户的数量生成相应数量的用户证书，所以没法实现动态生成peer\user证书从而动态增加用户(peer\user)。于是出现了fabric-ca，fabric-ca即是解决这样的需求的。通过使用fabric-ca动态生成证书，你将对fabric证书体系的理解更上一个层次。

在网络配置上运行着的是链码
就好像电线架好了，电就可以传输了一样，基础网络配置好了后，那在网络上运行着的便是链码了。

在fabric中链码和peer是独立的容器，因此你可以独立编辑的你的链码文件，只要实现了规定的链码接口，那么你这个链码便可以在peer上运行了，现在链码文件大都是go语言实现的。