Hyperledger Fabric入门实战（三）——Fabric基础知识

1. Fabric基本概念

1.1 逻辑架构

Fabric架构的核心包括三部分：

• Identity - 身份管理
• Smart Contact - 智能合约
• Ledger及Transactions - 账本和交易

1. Identity

Identity，也就是身份管理，Fabric是目前为止在设计上最贴近联盟链思想的区块链。联盟链考虑到商业应用对安全、隐私、监管、审计、性能的需求，提高准入门槛，成员必须被许可才能加入网络。Fabric成员管理服务为整个区块链网络提供身份管理、隐私、保密和可审计的服务。成员管理服务通过公钥基础设施PKI和去中心化共识机制使得非许可的区块链变成许可制的区块链。

2. Smart Contract

Fabric的智能合约smart contract称为链码chaincode，是一段代码，它处理网络成员所同意的业务逻辑。和以太坊相比，Fabric链码和底层账本是分开的，升级链码时并不需要迁移账本数据到新链码当中，真正实现了逻辑与数据的分离。

链码可采用Go、Java、Node.js语言编写。链码被编译成一个独立的应用程序，fabric用Docker容器来运行chaincode，里面的base镜像都是经过签名验证的安全镜像，包括OS层和开发chaincode的语言、runtime和SDK层。一旦chaincode容器被启动，它就会通过gRPC与启动这个chaincode的Peer节点连接。

3. Ledger | Transactions

Fabric使用建立在HTTP/2上的P2P协议来管理分布式账本。采取可插拔的方式来根据具体需求来设置共识协议，比如PBFT，Raft，PoW和PoS等。

• Ledger

  账本Ledger主要包含两块：blockchain和state。blockchain就是一系列连在一起的block，用来记录历史交易。state对应账本的当前最新状态，它是一个key-value数据库，Fabric默认采用Level DB, 可以替换成其他的Key-value数据库，如Couch DB。举个例子。我们采用区块链实现一个弹珠交易的系统。我们开发了一个Chaincode, 每个弹珠有以下几个属性：Name, owner, color, size. 可以定义一个JSON对象，用name做KEY, JSON对象做Value，存储在Level DB或者CouchDB中。

• Transactions

  Fabric上的transction交易分两种，部署交易和调用交易。

  • 部署交易

    把Chaincode部署到peer节点上并准备好被调用，当一个部署交易成功执行时，Chaincode就被部署到各个peer节点上。好比把一个web service或者EJB部署到应用服务器上的不同实例上。

  • 调用交易

    客户端应用程序通过Fabric提供的API调用先前已部署好的某个chaincode的某个函数执行交易，并相应地读取和写入K-V数据库，返回是否成功或者失败。

APIs,Events,SDKs

站在程序猿的角度Fabric开发主要包括客户端和服务器端应用程序的编写

• 服务器端

  Fabric提供API方便应用开发，对服务端的ChainCode，目前支持用Go、Java或者Node.js开发。

• 客户端

  对客户端应用，Fabric目前提供Node.js和Java SDK, Go SDK。未来计划提供Python，Fabric还提供RESTAPI。

对于开发者，还可以通过CLI快速去测试chaincode，或者去查询交易状态。在区块链网络里，节点和chaincode会发送events来触发一些监听动作，方便与其他外部系统的集成。

Fabric 应用开发流程

如下图所示，开发者创建客户端应用和智能合约（chaincode），Chaincode被部署到区块链网络的Peer节点上面。通过chaincode来操作账本，当你调用一个交易transaction时，你实际上是在调用Chaincode中的一个函数方法，它实现业务逻辑，并对账本进行get, put, delete操作。客户端应用提供用户交互界面，并提交交易到区块链网络上。

• 成员管理（MemberShip）
  • 会员注册
    • 注册成功一个账号得到的不是用户名密码
    • 使用证书作用身份认证的标志
  • 身份保护
  • 交易审计
  • 内容保密
    • 可以多条区块链, 通过通道来区分的
• 账本管理
  • 区块链
    • 保存所有的交易记录
  • 世界状态
    • 数据的最新状态
    • 数据存储在当前节点的数据库中
      • 自带的默认数据库: levelDB, 也可以使用couchdb
        • 以键值对的方式进行存储 的
• 交易管理
  • 部署交易
    • 部署的是链码, 就是给节点安装链码 - chaincode
  • 调用交易
    • invoke
• 智能合约
  • 一段代码， 处理网络成员所同意的业务逻辑
  • 真正实现了链码和账本的分离（逻辑和数据分离）

1.2 基础概念

• 组织

  是指这样一个社会实体，它具有明确的目标导向和精心设计的结构与有意识协调的活动系统，同时又同外部环境保持密切的联系

  在Fabric中一个组织里边都有什么?

  • 有用户
  • 有进行数据处理 的节点 -> peer
    • put -> 写数据到区块链中
    • get -> 数据查询

• 节点

  • client

    进行交易管理(cli , node sdk, java sdk)

    • cli -> 通过linux的命令行进行通过, 使用的是shell命令对象数据进行提交和查询
    • node.js -> 通过node.js api 实现一个客户端
    • java -> 通过java api 实现一个客户端
    • go也可以

  • peer

    存储和同步账本数据

    • 用户通过客户端工具对数据进行put操作, 数据写入到一个节点里边
    • 数据同步是fabric框架实现的

  • orderer

    排序和分发交易

    • 为什么要排序?

      • 解决双花问题
      • 没发起一般交易都会在orderer节点进行排序

    • 交易数据需要先进行打包, 然后写入到区块中

• 通道 -> channel

  通道是有共识服务（ordering）提供的一种通讯机制，将peer和orderer连接在一起，形成一个个具有保密性的通讯链路（虚拟），实现了业务隔离的要求；通道也与账本（ledger）-状态（worldstate）紧密相关

consensus Server : orderer节点

三条不同颜色的线, 代表三个通道

一个peer节点是可以同时加入到不同的通道中的

peer节点每加入到一个新的通道, 存储数据的区块链就需要添加一条, 只要加入到通道中就可以拥有这个通道中的数据, 每个通道对应一个区块链.

• 交易流程

要完成交易, 这笔交易必须要有背书策略的, 假设:

• 组织A中的成员必须同意
• 组织B中的成员也必须同意

1. Application/SDK : 充当的是客户端的角色
   • 写数据
2. 客户端发起一个提案, 给到peer节点
   • 会发送给组织A和组织B中的节点
3. peer节点将交易进行预演, 会得到一个结果
4. peer节点将交易结果发送给客户端
   • 如果模拟交易失败, 整个交易流程终止
   • 成功, 继续
5. 客户端将交易提交给排序节点
6. 排序节点对交易打包
7. orderer节点将打包数据发送给peer, peer节点将数据写入区块中
   1. 打包数据的发送, 这不是时时的
   2. 有设定条件, 在配置文件中

背书策略:

• 要完成一笔交易, 这笔交易的完成过程叫背书

• 账本