简介
HypeLedger（超级账本）是由Linux基金会2015年创建的首个面向企业应用场景的开源分布式账本平台。
- HypeLedger Fabric是HypeLedger种的区块链项目之一
- HypeLedger Fabric引入权限管理
- 在架构设计上支持可插拔、可扩展
- 是首个面向联盟链场景的开源项目
Fabric对比其他区块链系统
相同点
- 分布式账本
- 智能合约
- 参与者管理交易
不同点
- 私有化
- 具有权限许可网络
特别之处
- 多语言智能合约
- 可插拔机制，多存储方式，多共识机制
- 通道机制，允许一组参与者创建各自的交易账本
Fabric架构
成员管理
区块链服务
智能合约
智能合约是一组运行在验证节点上的去中心化交易程序。
在Fabric中智能合约被称为链码（chaincode），由外部应用程序（比如网页、APP）与分布式账本进行交互。
应用编程接口
应用编程接口是二进制码在机器层面相互交互的接口。
应用编程接口提供SDK（开发工具包）和CLI（命令行）两种方式供开发人员使用区块链的各种服务。Fabric提供了一套易用、可灵活扩展的API接口。用户可以非常方便地使用SDK和CLI对分布式账本进行查询、更新。
事件机制
点对点网络
点对点网络是区块链的网络特征，Fabric作为联盟链，其点对点网络与公链的主要区别在于其点对点网络间通信存在认证机制，只有联盟内的经过验证的节点才能互相通信。
核心概念
账本
账本是Fabric对区块链结构的延伸，所以Fabric账本包含两部分，世界状态和区块链。
链码
智能合约在Fabric中也被称为链码（chaincode），Fabric项目中的链码包括用户链码和系统链码两种。
通道
Fabric的通道是两个或多个特定网络成员之间通信的专用“子网‘，用于进行私有和机密的交易。
组织
组织（Organization）也被称为“成员”，是现实企业、机构等实体在Fabric中的映射，一个组织应包含CA、Peer。
排序服务
背书策略
背书是指特定节点执行链码交易并返回一个提案响应给客户端应用的过程。
MSP
成员服务提供者MSP是Fabric用于颁发证书和验证身份的一组可插拔的加密机制和协议。
私有数据集的组成与模式
私有数据集可以让通道上的一组组织对其他组织保持数据私有，私有数据集运行通道上定义的组织子集可以背书、提交、查询私有数据，而无需创建单独的通道。
核心组件
网络模块
网络模块用于定义Fabric网络拓扑、提供P2P网络支持。
链码模块
应用层的智能合约执行，需要依赖底层链码服务的实现。
共识模块
共识服务是区块链的核心组件，需要确保区块里面每一个交易数据的有效性和有序性，网络上不同节点之间数据的一致性。
账本模块
账本管理
账本数据结构
Fabric的账本数据结构分为：
- 区块链数据（Blockchain Data）
- 状态数据（State Database）
- 索引数据（Index Database）
区块链数据
世界状态
索引数据库
可插拔共识
Fabric提出了可插拔共识实现共识体系，其中从系统层面采用模块化共识，根据不同的业务来定制不同的共识算法，方便企业加入自己要的共识算法。
Kafka
Kafka构建可在系统或应用程序之间可靠获取数据的实时流数据管道。
Kafka构建转换或响应数据流的实时流应用程序。
Kafka作为一个运行在一个或多个数据中心服务器上的集群。
Kafka集群以称为topics主题的类别存储记录流。
Kafka中每条记录都包含一个键，一个值和一个时间戳。
排序服务
Fabric的共识过程通过排序实现
Fabric排序服务依赖于确定性共识算法，即参与共识的Peer节点所验证的区块都是最终且正确的，不会出现分叉的现象。
Fabric排序有Raft、Kafka、Solo三种实现方式
Kafka是一个崩溃容错（简称CFT）的实现，Kafka利用一个ZooKeeper进行管理。
多链
多链由多个通道、多个共享账本、多个Peer节点组成，不同链可以将参与者的数据和链码进行隔离。
多通道
多通道即Fabric网络中包含多个通道，多个Peer节点加入不同的应用通道实现多个账本。
数据分发
Gossip数据分发协议
Gossip数据分发协议是一种安全、可靠、可拓展的数据分发协议用来保证数据的一致性和完整性。
通信方式
Peer节点基于gossip的数据广播操作接收通道中其他节点的信息，并将这些信息随机发送给通道上的其他节点。
PUSH
PULL
PUSH/PULL
优点
扩展性
一致性收敛
容错
简单
去中心化
缺点
消息冗余
消息延迟
私有数据分发协议
私有数据允许在通道上定义的组织子集可以背书、提交或查询私有数据，而无需创建单独的通道，降低了实现私有数据的管理开销。
辅助分发
为了辅助分发，在集合定义中的maxPeerCount和RequiredPeerCount属性控制了在背书的时候分发的数量。
尝试会持续一个可配置的时间长度，在时间内可以通过节点配置文件core.yaml中的属性peer.gpssip.pvtData.pullRetryThreshold进行配置。
使用pullRetryThreshold的时候需要考虑的问题：
主节点选举机制
主节点的选举机制用于在每一个组织中选举出一个用于链接排序服务和开始分发新区块的节点。
主节点选举使得系统可以有效地利用排序服务的带宽。
模式
以选举模式进行归类
静态模式
系统管理员手动配置一个节点为组织的主节点。
动态模式
组织中的节点自己选举出一个主节点。
锚节点同步机制
gossip利用锚节点来保证不同组织间的互相通信，通道配置中至少有一个锚节点且不一定是主节点。
一个组织中有一个节点连接到了锚节点，锚节点就可以获取通道中所有节点的信息。
节点类型
对等节点
对等（Peer）节点是参与交易的主体，代表了每个参与到链上的成员，负责共识环节中的执行智能合约。
对等（Peer）节点包含两种类型的节点，背书节点（Endorser）和提交节点（Committer）。
提交节点
通道中的每个对等节点都是一个提交节点，提交（Committer）节点又称为记账节点，负责验证从排序服务节点接收的区块里的交易，然后将块提交（写入/追加）到其通道账本的副本。
提交节点使用基于Gossip的P2P数据分发，节点会定期跟其他节点交换信息。
背书节点
具有智能合约的每个对等节点都可以是背书节点。
背书（Endorser）节点在接收到客户端的交易提案（Transaction Proposal）后，会验证交易签名，模拟执行交易，并且对结果执行签名背书，然后把经过背书的交易发送回客户端。
领导节点
领导（Leader）节点又称为主节点，主节点负责和排序服务节点（Orderer）通信，从排序服务节点处获取最新的区块并在组织内部同步。
排序节点
功能
排序服务节点（Orderer），主体功能便是对交易排序从而保证各Peer节点上的数据的一致性，也包含了ACL进行访问控制。
工作流程
交易模型
交易生命周期
- 执行：交易（通过智能合约）以任意顺序执行，甚至可以并行执行。
- 排序：交易通过背书策略扩散到Fabric网络中，所有节点被按顺序推向Kafka集群中的topic的过程。
- 验证：每个节点验证并按顺序执行交易，最终更新账本。
交易的执行和账本的更新拆分的好处：
- 链码不必开放给所有的节点，提升系统的性能
- 交易可以在排序之前执行，提高系统吞吐量
- Fabric可以使用非确定性的链码，提高系统的灵活性
交易流程图
发起交易
- 定义网络
- 创建通道
- 完成组织的注册和登记并且拿到加密材料
- 链码实例化
- 设置背书策略
验证签名
背书节点对提案进行验证，验证内容包括：
- 交易提案格式
- 验证重复提交
- 验证签名有效
- 验证发起者权限
执行交易
检查提案响应
应用程序验证背书节点的签名，并比较这些提案响应，以确定其是否相同。
背书结果打包
应用程序将交易提案和“交易消息”中的交易响应“广播”给排序服务。
验证和提交交易
账本更新
每个Peer节点都将区块追加到通道的链上，对于每个有效的交易，写集都提交到当前状态数据库。
