初识Hyperledger Fabric

Hyperledger 顶级项目

Hyperledger Sawtooth：一个创建、部署和运行分布式账本的模块化平台。包含一个新奇的共识算法——经历时间证明（Proof of Elapsed Time，简称PoET），面向大型分布式验证器群，消耗最少的资源。
Hyperledger Iroha：为了将分布式账本技术简单容易地与基础架构项目集成而设计的一个区块链框架项目。
Hyperledger Indy：特别为去中心化的身份而建立的一种分布式账本。它提供了基于区块链或者其它分布式账本互操作来创建和使用独立数字身份的工具、代码库和可以重用的组件。
Hyperledger Burrow：一个支持许可的智能合约机，burrow提供了一个模块化的区块链客户端，带一个经许可的智能合约解释器，它部分建立在以太坊虚拟机（EVM）规范的基础上。
Hyperledger Fabric：一个带有准入机制的企业级联盟链项目，它的前身是IBM贡献的OpenBlockchain。
Hyperledger Explorer：由Intel、DTCC、IBM推出的使用nodejs制作的面向web的UI，可以方便的看到区块、节点等统计信息，很方便地进行数据的展示。
Hyperledger Cello：由IBM推出的区块链操作系统，使用Python和JavaScript开发，支持多种底层基础设施，高性能，可扩展，可插拔。
Hyperledger Caliper：由华为推出的，使用nodejs开发，可以评估fabric、sawtooth等性能。
Hyperledger Usra：由Fujitsu、Sovrin、Intel等推出，使用rust开发，包含两个子项目：Base Crypto和Z-Mix。
Hyperledger Grid：由Cargil、Intel、Bitwise Io推出，使用Python开发，专注于供应链领域，可以方便的开发出供应链领域的区块链应用。

Fabric 名词解释

Membership Services：成员服务，用来在许可的区块链网络上认证、授权和管理身份。
Ordering Service：排序或者共识服务，确认交易，并将交易排序放入block。
Ledger：账本，交易状态的持久化。
Node：节点，一个网络实体用来维护Ledger，执行合约的容器。
SDK：用来和区块链网络进行交互。

Fabric 架构

fabric 架构图.png

Fabric 交易流程

fabric交易流程.png

应用向单个或多个节点（Peer）发送对交易的背书提案（Proposal），提案包括本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等；
背书（Endorsing）节点验证签名并确定提交者是否有权执行操作，同时根据背书策略模拟执行智能合约；
背书节点将结果及其各自的CA证书签名返还给应用程序客户端；
应用程序客户端收到背书（Endorsing）节点返回的信息后，判断提案结果是否一致，以及是否参照指定的背书策略执行，如果没有足够的背书，则中止处理；否则，应用程序客户端把数据打包到一起组成一个交易并签名，发送给Ordering-Service；
Ordering-Service对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，发送给记账（Committting）节点；
记账（Committting）节点收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，修改WorldState；
记账节点通知应用程序客户端。

Peer节点

fabric peer.png

Fabric是联盟链，Peer代表一系列组织，Peers是整个区块链网络的基础，因为它是账本和智能合约的载体。通过智能合约，账本通过不可篡改的方式记录了交易的全过程。

对于不能的公司来说，是有不同的业务的，不同的业务又与不同的公司相关联，需要创建多个联盟链，因此就需要创建多个channel，channel是多个特定成员之间以机密交易为目的建立的私网，一个peer可以加入多个channel，每个channel维护自己的账本，账本和账本之间是隔离的，每个channel可以维护一个或多个账本。所以为了满足复杂的交易需求，每个peer上可以安装不同的智能合约，当peer交易完成时，会发送事件通知Client。peer上还有一个Local MSP（成员服务提供器）服务，提供身份认证和加密签名等功能。

Leader Peer和Anchor Peer

Leader Peer
- 连接ordering service并拉取新的区块
- 分配交易给组织中的其它committing peers
- 一个组织可以有一个或多个leader peer
- 成为leader peer的方式（Election）：
  - Static：由系统管理员手动配置一个peer成为leader，可以定义一个或多个gossip:useLeaderElection:false orgLeader:true
  - Dynamic：peers执行一个leader选举程序，useLeaderEection:true orgLeader:false election:leaderAliveThreshold:10s，被选中的peer必须向其它peers发送活着的信息，来证明是活着的节点，否则重新选举。
Anchor Peer：gossip协议利用Anchor Peer使得不同组织中的peers相互认识

Block

block.png

区块头
- 区块数字
- 当前区块哈希，由当前区块数据的所有交易生成
- 前一个区块哈希
区块数据
区块元数据，包括区块写入的时间、写入的人、签名

Transaction

transaction.png

Header：交易头，包含ChainCode的名字、版本等信息
Signature：客户端用户（发请求者）的签名
Proposal：客户端给背书节点发送的请求
Response：智能合约执行的结构
Endorsements：每个背书节点返回的结果

World State

WorldState 以key-value的形式，维护着当前账本的当前信息。

WorldState.png

智能合约和链码

智能合约（Smart Contract）是区块链的核心，定义了各个不同组织间的业务规范，创建交易并记录在账本里。多个智能合约可以打包到一个链码中。只有链码（Chaincode）部署之后，智能合约才能被应用使用。

智能合约和账本

智能合约和账本.png

链码的生命周期

链码生命周期.png

打包 peer chaincode package
- 链码部署规则（CDS），包含链码的源码、名称、版本
- 初始化policy，可以指定由谁来实例化
- 签名，指定链码的所有者 peer chaincode signpackage
安装 peer chaincode install
- 安装到peer节点
- 一个peer可以安装多个链码
- 必须把链码安装到这个channel所有的背书节点上
实例化 peer chaincode instantiate
- 在一个channel上创建并初始化一个链码
- 设置背书策略（endorsement policy）
运行 peer chaincode query||peer chaincode invoke
- 客户端提交交易
- 智能合约处理交易，更新账本并返回响应
- 客户端接收响应
更新 peer chaincode upgrade
- 链码可以在任何时候通过修改版本进行更新
- 在更新之前，必须把新版本安装到所有的背书节点上
- 类似于实例化过程，每次只影响一个channel

系统链码

不同于一般的链码运行在一个独立的容器，系统链码运行在peer进程上，实现了一些系统行为。

生命周期系统链码（LSCC）：用来处理应用链码的生命周期请求
配置系统链码（CSCC）：在peer端处理channel的配置
查询系统链码（QSCC）：提供了获取区块和交易的账本查询API

Gossip Protocol

Fabric为了优化网络性能，提高安全性和可扩展性，将每个交易分到Endorsing Peer、Ording-Service和Committting Peer三个部分，这就需要一种安全的，可信的和可扩展的数据传输协议——Gossip Protocol。Gossip传输协议以随机的方式将信息散播到网络中，主要执行三个功能：

维护和管理channel的peers成员，发现新的peer不断探测新peer的状态并更新channel的membership
给channel上所有的peers传播账本数据
对于新的peers，允许peer-to-peer传输数据来更新账本

Gossip Messaging

在线的peers会不断的向周围播放“alive”信息来证明是活着的
peers通过收集这些“alive”信息来维护channel的成员信息
当leader从ordering service拿到新的区块交易信息，会传播其它的peer，每个peer拿到新的交易信息，存到账本，并自动不断的散发给其它peer
每个peer会和周围的peers询问状态是否匹配，假如验证不同，则从channel上的其它peers上拉取最新的区块，来修复自己的状态
一个channel上的peers不能和其它channel的peers发送和共享信息

私有数据

机密数据存贮在每个授权peer的私有数据库
私有数据收集策略来定义授权peers
Ordering service不会看到私有数据
私有数据通过gossip协议peer-to-peer发送

带私有数据的交易流程

私有数据交易流程.png

客户端向背书节点（Endorsing Peer）提交一个带私有数据的请求
背书节点模拟交易执行，并把私有数据存储在临时数据库中，同时通过gossip协议，把私有数据向其它有权限的peers传播
当传播到指定数量时，背书节点对响应签名并返回给客户端，响应不包含私有数据，只是私有数据的keys和values的哈希
客户端把响应再提交给排序服务（Ordering-Service）
Ordering-Service把交易信息传递给记账节点（Committing Peer）
Committing Peer对带有私有数据哈希的交易和临时数据库中存储的数据进行验证比较，验证无误后，将私有数据存储到真实的私有数据库中，提交交易和区块到Worldstate中
Committing Peers通知客户端