Hyperledger Fabric系统架构

Hyperledger Fabric系统架构

一：名词解释

1.Raft共识机制

（1）：共识机制

共识算法可以让机群协同工作，并且可以容忍部分成员主机的故障。而通常主机的故障会分为两种情况：
  拜占庭故障： 出现故障后伪造信息恶意响应。
  非拜占庭故障： 出现故障但不会伪造信息。
  拜占庭将军问题的具体解释： 该问题为一个协议问题。军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开的，且其中存在叛徒。叛徒可以任意行动以达到以下目标：欺骗某些将军采取进攻行动；促进一个不是所有将军都同意的决定，如当将军们不希望进攻时促进进攻行动；或者迷惑某些将军，使他们无法做出决定。如果叛徒达到了这些目的，则行动必然失败。
   结论： 如果需要容忍n个叛国者，则必须保证将军总数大于3n。

(2)：Raft共识机制

核心思想：

如果多个数据库的初始状态一致，只要之后进行的操作一致，就能保证之后的数据一致。

节点状态

Raft算法将节点划分为三种状态：
Leader（主导状态）：所有对系统的修改都会先进行Leader，每个修改都会写一条日志。
Follower（跟随状态）：所有节点都以该状态开始，如果没有收到Leader消息则会变成Candidate状态
Candidate（候选状态）：会向其他节点“拉选票”，得到大部分票的则成为Leader。（Leader选举）

共识过程

该共识过程主要分为两个阶段：Leader的选举和在选举出的leader上进行正常操作。
Leader选举：
  当follow在选举时间内未收到leader的心跳消息，则转换为candidate状态。
  Raft系统中：
  1).任何一个服务器都可以成为一个候选者candidate，它会向其他服务器followe发送要求选举自己的请求。
  2).其他服务器同意了，发出ok。只要达到大多数票，候选人就可以成为leader。
  3).成为领导人之后，可以向选民（follower）发出指令
  4).一旦这个leader崩溃了，那么follower中有一个成为候选者，并发出邀票选举
  5).follower同意后，其成为leader，继续担任记账等指导工作
记账过程：
  1).假设leader领导人已经选出，这时客户端发出增加日志的要求
  2).leader要求follower遵从它的指令，都将这个新的日志内容追加到他们各自的日志之中。
  3).大多数follower服务器将交易记录写入账本之后，确认追加成功，发出确认成功的消息。
  4).在下一个心跳中，leader会通知所有的follower更新确认的项目。
  每个交易记录重复上述的过程。
  若发生网络通信故障，使得leader不能访问大多数的follower，则leader只能正常访问他能访问的，其他的follower因为没有leader，重新选举一个候选者作为leader，并与外界打交道。当网络恢复，原来的leader变为follower。在失联阶段，老leader任何更新都不能算确认，必须全部回滚，接收新leader的新的更新。

(3):应用原因

通过上述对Raft共识机制的介绍，可以知道Raft只能处理非拜占庭故障。而Hyperledger Fabric中不使用可以容忍拜占庭故障的共识机制是因为：如果可以容忍拜占庭故障，假设一个系统中可能同时有n个节点发生拜占庭故障，则至少要不是3n+1个节点存在。系统会设计的很复杂。而Raft只需要2n+1个节点来应对潜在的n个节点的非拜占庭故障。且在Hyperledger Fabric这种许可制的联盟链环境中，通常会使用数字证书等安全机制来增强安全性，因此存在恶意节点的可能性很小。

2.gRPC

gRPC是Google开发的高性能，通用的开源RPC框架。是面向移动应用开发并基于HTTP/2协议标准而设计，基于Protobuf序列化协议开发。

在gRPC中一个客户端可以像使用本地对象那样直接调用位于不同机器上的服务端应用的方法。gRPC是基于定义一个服务，在服务端，实现服务的接口然后运行一个gRPC服务来处理可出端的请求。在客户端，客户端拥有一个存根，提供与服务器相同的方法。

3.Gossip协议

P2P网络的核心技术。主要用在分布式数据库系统中各个副本节点同步数据之用。

（1）：六度分隔理论

简单的说：你和任何一个陌生人之间所间隔的人不会超过六个，也就是说，最多通过六个人你就可以认识任何一个陌生人。

（2）：原理

基本思想：一个节点想要分享一些信息给网络中的其他节点，于是，它周期性的随机选择一些节点，并把消息传递给这些节点。这些接收到信息的节点接下来会做同样的事情。一般来说，信息会周期性的传递给N个节点，而不只是一个。且信息不回传。由于不能保证某个时刻所有节点都收到消息，但是理论上最终所有节点都会收到消息，因此它是一个最终一致性协议。

（3）：用途

由上述原理可以知道：Gossip的主要用途就是信息传播和扩散。

二：体系架构

Fabric分为四大模块：成员服务，区块链服务，智能合约和应用编程接口。

1.成员服务

成员服务（MSP）主要提供证书发布，验证以及相关加密机制和协议。成员服务内置了Fabric CA证书颁发机构，提供基于PKI体系的身份证书管理服务，同时也允许第三方证书认证机构接入。
Fabric CA提供客户端和SDK两种方式与CA进行交互。每个Fabric CA都有一个根CA或者中间CA。为了保证CA的安全性，中间CA采用集群方式搭建。

且实践中采用三级证书：根证书，业务证书，用户证书。根证书用来签发业务证书，业务证书用来签发具体的用户证书（不同的交易环节使用不同的交易证书：身份认证证书，交易签名证书，安全通讯证书。）。

2.区块链服务

区块链服务用于维护分布式账本。区块链服务包括P2P协议、分布式账本和共识机制管理。

1.P2P协议 Fabric网络中，Peer和Orderer采用gRPC（Google RPC）对外提供远程服务，供客户端进行调用。网络中的节点之间通过Gossip 协议来进行状态同步和分发。

2.共识机制 区块链网络中，不同参与者之间，交易必须按照发生的顺序写入到分布式账本中。为此必须建立事务的顺序，并且采用一种共识机制拒绝错误（或恶意）的交易数据。

Fabric允许根据实际业务需要选择合适的共识机制，目前支持SOLO、Kafka、Raft三种共识机制。

3.分布式账本 分布式账本包括两个组件：世界状态（world state）、事务日志，分布式账本是世界状态数据库和事务日志历史记录的组合。

世界状态（world state）组件记录的是最新的分布式账本状态，事务日志组件记录的是世界状态的更新历史。

3.智能合约服务

智能合约服务用于保证智能合约在网络节点上安全运行。

智能合约是一组运行在验证节点上的去中心化交易程序。在Fabric中智能合约被称为链码(chaincode)，由外部应用程序（比如网页、APP）与分布式账本进行交互。

Fabric的智能合约使用Docker存放链上的代码，而不需要依靠特定的虚拟机，Docker为链码执行提供了一个安全、轻便的语言执行环境。

4. 应用编程接口

应用编程接口提供SDK（开发工具包）和CLI（命令行）两种方式供开发人员使用区块链的各种服务。Fabric提供了一套易用、可灵活扩展的API接口。用户可以非常方便地使用SDK（开发工具包）和CLI（命令行）对分布式账本进行查询、更新。

三：核心组件

1.Fabric网络

在Fabric网络中，Peer和Orderer之间采用gRPC对外提供远程服务。网络中节点之间通过Gossip协议来进行状态同步和分发。

服务节点

Fabric网络中存在以下4种不同类型的服务节点，彼此协作完成整个区块链系统的功能。Fabric的一大创新就是对网络中节点角色进行解耦。
 背书节点（Endorser）： 负责对交易的提案（proposal）进行验证并模拟交易执行
 提交节点（Committer）： 负责在接受交易结果前再次检查合法性，接受合法交易对账本的修改，并写入区块结构
 排序节点（Orderer）： 对所有发往网络中的交易进行排序，将排序后的交易按照配置中的约定整理为区块，之后提交给确认节点进行处理。
 证书节点（CA）： 负责对网络中的证书进行管理，提供标准的PKI服务。
通常情况下，除了用户节点，Fabric网络所有的节点都具备Commiter功能，部分节点具有Endorser，Orderer功能。锚节点是一种外部可发现的节点，配置了对外服务的端口，如果某个peer节点被配置为锚节点，这意味着该节点可以被Orderer节点和其他任何节点发现。证书节点是一个相对独立证书管理机构，也可由第三方证书机构来承担这个角色。

2.Fabric共识

Fabric种广义的共识机制包含背书，排序和验证三个环节，狭义的共识指的是排序。

3.Fabric账本

在Fabric种：
  交易：存储相关的业务信息
  区块：一组排序后的交易集合，将区块通过密码算法连接起来就是区块链。
  账本：对区块链结构的进一步延伸，是Fabric种十分关键的一个结构。账本包含状态数据库和历史数据库。其中状态数据库记录的是变更记录的最新结果，方便查询；历史数据库记录的是区块链结构。
  在Fabric种，通道隔离了交易，因此每个通道拥有独立的账本。

4.Fabric链码

Fabric种将智能合约成为链码（chaincode）。可分为用户链码和系统链码。用户链码运行在单独的容器中，提供对上层应用的支持。系统链码则嵌在系统内，提供对系统进行配置，管理的支持。

一般提到的链码为用户链码，用户通过链码相关的API编写用户链码，即可对账本中状态进行更新操作。

系统链码有以下五个合约：
  CSCC：管理peer上通道相关的信息以及执行通道配置交易。
  LSCC：管理链码的生命周期——在peer上安装链码，在通道上实例化和升级链码，用户从运行中的链码获得信息。
  QSCC：运行在所有的peer上，提供帐区块查询，交易查询等API。
  ESCC：由背书节点调用，对一个交易相应进行密码签名。
  VSCC：由记账节点调用，包括检查背书策略和读写集版本。

四：交易流程

一个完整的交易要涉及到应用程序，证书服务，背书节点，提交节点和排序节点。

上图中，客户端（APP）使用SDK与Fabric网络进行交互。
1.客户端先通过证书服务获取合法的身份并加入到通道（channel）之中。
2.客户端构造交易请求（Proposal）提交到背书节点（Endorser）。
3.背书节点对交易进行验证和模拟之后（并不是正真更新账本），反馈给客户端。
4.客户端收到足够的背书支持后将交易发送到Orderer节点。
5.Orderer节点对网络中的交易进行全局排序，并将排序后的交易打包成区块，然后广播给网路中的提交节点（committer）。
6.提交节点负责维护区块链和账本结构，对交易进行最终检查（交易结构的合法性，交易背书签名是否符合背书策略），检查通过后写入账本。