Fabric基础理论

Fabric基础

Fabric是基于联盟链（参与需要联盟许可）模型设计的，抛去公链的挖矿和无准入门槛。采用外部激励和较小的网络规模提高并发量。

Fabric的网络分为channel和联盟，其中一个channel包含几个信息共享的组织，每个组织又有自己的其他小圈子，所以各个圈子错综复杂构成了整个联盟链。

Fabric交易流程
- proposal - 建议
用户向各组织的Peer节点发送交易请求
- Peer节点根据背书策略运行智能合约。
- 运行成功后，签名回传给用户。
- 用户整合签名，打包广播发送给orderer节点
- Orderer节点对接收到的所以交易进行全排序
- Orderer节点将排序好的区块发送给Peer节点
- Peer验证区块交易，通过的区块被提交到账本
- 最后Peer向用户发送消息，告知交易已提交
应用开发

开发者只需关注application的UI逻辑设计和核心chainCode也就是背书策略和智能合约的执行代码。
- 寻找应用场景
- 细化生命周期（状态、数据转移）
- 数据结构
- 智能合约设计
- 前端与SDK交互

Peer 节点按照作用的不同可分为两种：Endorser背书节点和Committer记账节点。

Endorser节点模拟执行交易，不管失败成功，然后签名（ESCC）返回客户端。

commentter节点根据（VSCC）验证签名，再根据设置的背书策略判断交易是否合理。

背书策略在chaincode实例化时指定

其语法包括：AND、OR、OutOf、E （可嵌套）

智能合约的权限包括：member、admin、client、peer

如OR(org1.member,org2.member) 意为：只要组织1的member或者组织2的member同意即可满足要求。

Fabric的账本（有序不可修改的交易记录）
1. blockchain： channel的配置信息、历史交易记录
2. world state：维护账本当前状态，方便app进行快速查询

chaincode 智能合约

不同组织之间执行的同一个规则代码，是Fabric的核心，由chaincode的将交易打包到区块。
- 开发者开发智能合约和配套的Application
- 智能合约通过API调用操作world state，其中get直接返回数据不会生成交易记录。put、del会修改world state的同时在block chain上增加新的交易记录。
智能合约的开发流程：打包、安装、实例化、运行、更新、运行….
```
1. 编写合约
 2. 打包合约
```
打包时可以指定源码、name、版本、背书策略、签名
1. 安装合约
  
  一个channel可以安装多个不同的合约、合约必须安装在整个channel所有的背书peer上
- system chainCode
  
  系统合约代码运行在peer节点上
  1. LSCC（lifecycle system chaincode）处理chainCode包括：打包、安装….
  2. CSCC（configuration system chaincode）处理channel 在peer上的系统配置
  3. QSCC（query system chaincode）提供查询API，包括区块和交易记录

Gossip 信息传输协议 : 最终一致性

像流行病和绯闻一样在网络中传播，非法数据会在第一时间被停止传播
- 负责Peer的发现管理和channel成员的状态
- Peer节点对账本的传播
- 对数据落后的peer采取点对点更新

Leader Peer 和 Anchor Peer

leader peer 可以联系Ordering service 获取新区块，然后传播给其他committing peer，其他committing peer再继续散播

leader peer可以静态指定也可以基于选举

Anchor Peer 基于Gossip协议使channel上各节点相互认识：A —> B 只需要 A —> A’Anchor Peer —> B’Anchor Peer —>B

private data 私有数据

将需要自己或极个别组织知道的数据单独存到一个private data数据库，根据private data数据库的策略来进行访问限制，即使是Ordering service也不能访问该数据，该数据也用Gossip协议传输。

Fabric网络
- 配置、启动Ordering service
- 配置、启动Peer 节点
- 在Peer节点上安装chaincode
- 创建channel
- Peer节点加入channel
- 实例化chaincode、指定背书策略

全排序 total order

各Orderer出的区块必须保证一致，且允许Orderer的容错（挂掉）

具有强一致性，不同于公链的概率一致性

Orderer不是拜占庭容错而是CFT容错，但整个Chain是拜占庭容错

channels
- 系统初始创建一个Genesis block 其中包括System channel的配置
- 所有的Order都需要同样的配置启动。
- 启动之后，系统会自动创建一个system channel运行在每一个Orderer上
- 当创建一个新的channel A时相当于向system channel 发送一个新交易
- 并且将新channel 的配置信息作为新channel的Genesis block启动，运行在每一个Peer上。
Orderer的排序策略
- Solo 仅供试验：使用一个节点排序序列化完成出块。
- Kafka ：基于Kafka集群的排序（消息队列 —> 先来先得）
  
  因为Kafka已经对交易做了时间排序，但是为了保证每个区块出块相同，需要Orderer向Kafka发送一个TTC消息。
1. Orderer 向 Kafka 发送一个TTC消息

2. Orderer接收到Kafka的消息

3. Orderer 将TTC 之前的交易打包成区块

由于每个Orderer得到的消息相同，所以出的块也是相同的。

为了解决更新配置时导致Kafka消息鉴定失败的问题，为消息添加了Version，Orderer得到版本不对的消息时重新鉴定并发送回Kafka共识。
- Raft
  
  基于 Etcd/raft library
  
  Raft与Kafka一样实现了CFT的共识算法，简单易部署去除了Kafka和zookeeper的依赖。
  
  基于Block做共识而不同于Kafka使用交易进行共识。Raft中只有Leader节点产生区块，Follower同步区块。