区块链之超级账本Fabric 基于SDK应用开发

Posted 2023-04-03 @卓越俊逸_角立杰出@

一、Fabric 应用开发模型

Fabric开发包含客户端应用和智能合约（chaincode）开发
chaincode开发完成之后被部署到区块链网络的Peer节点上面。通过chaincode来操作账本，当调用一个交易transaction时，实际上是在调用chaincode中的一个函数方法，它实现业务逻辑，并对账本进行get, put, delete操作。
客户端应用提供用户交互界面，调用fabric SDK,完成区块链的操作和交易
本次培训侧重客户端应用的开发

二、Fabric SDK接口介绍
Fabric提供了SDK给应用程序调用，SDK包含了交易处理，成员管理，区块链查询和事件处理等接口

Fabric SDK具有以下特点： 底层接口调用很多都是异步返回，采用gRPC协议，能够很好的双向传输数据

gRPC结合Protocol Buffer能减少传输数据量，提高网络传输性能

支持语言有Go、Java、javascript、Python。本次配置我们以Java语言开发为例

和内部模块采用相同的接口，减少端口开放性，减少安全风险

整个Fabric网络，除了fabric-ca采用HTTP协议，其他都是GRPC协议

Fabric SDK接口模块
Fabric SDK定了两种模块的接口；一种访问fabric-ca接口，一种访问fabric网络接口，其中fabric-ca是可选的，可以选用其他成熟的第三方CA系统替换

Fabric SDK 提供的模块如下：
HFClient 模块：应用程序入口，提供通道管理，链码管理，数据存储，密码学相关的功能。每个HFC实例对应一个区块链网络，包含记账节点，排序节点等。如果应用层需要访问多个网络，可以建立多个HFC的实例

Config 模块：初始化HFC时需要离线获取配置信息，Config模块包含可信的根证书，排序服务节点证书和IP地址，记账节点证书和IP地址等。配置模块读取后传递给HFC

Channel 模块：对应通道实例，通道在配置了order和peer之后需要初始化，初始化的时候给order服务节点发送获取配置区块请求

Peer 模块：Peer节点是HFC模块发送背书请求、交易查询的节点。Peer实例包含了节点名称、地址、角色、注册证书等信息

Order模块：Order节点是HFC模块发送交易排序的节点。Order实例包含了排序服务节点的地址信息，定义了发送原子广播请求和获取区块的接口
User模块：代表了已经完成注册证书和签名密钥的实体，注册证书必须由区块链网络信任的CA颁发

用户身份(User Identity) 和 节点身份（Peer Identity）是有区别的，在SDK里面，用户身份可以访问秘钥信息，可以进行签名。而节点身份不能访问秘钥，只能验证签名

三、Fabric 应用开发流程

Fabric应用开发流程具有通用性 一般步骤如下：
1.在排序节点上创建通道
2.用户登记与注册
3.Peer节点加入通道
4.通过Peer节点安装实例化链码
5.发起交易并生成区块

发起交易如下图所示：

> 四、Fabric 应用开发流程

如果应用层直接和Fabric SDK打交道，流程并不简单，同时会有大量的冗余代码，一般情况下在应用层和Fabric SDK中间还会为区块链包装一个Framework,，简化应用层和区块链对接的难度，对应用层来说不用关心区块链底层的逻辑和流程

Fabric 源码介绍：


Fabric-CA 源码介绍：

api：CA 接口相关代码实现

cmd/fabric-ca-client： CA客户端相关代码实现

cmd/fabric-ca-server：CA服务端相关代码实现的功能的实现

lib/metadata:：数据库操作代码实现

五、Fabric应用开发注意事项

理解Fabric的运行，交易流程再开始应用开发，否则会摸不着门道

需要特别注意Fabric的配置选项,有加密,超时等

几乎每一个SDK或多或少的都会存在一些BUG,有些BUG大部分是SDK自身的，有些是Fabric的问题，那么遇到这些问题后，我们可以根据交易的流程来判断出哪一步出了问题，然后可以在每个节点修改日志级别来得到错误信息。再定位到SDK当中的某一行代码来进行调试

需要注意SDK版本和Fabric平台版本的匹配，不同版本会出现不兼容现象

建议初学者从Fabric自带的E2E例子开始学习会事半功倍

区块链之联盟链（三） 认识Fabric

参考技术A Fabric 是超级账本联盟推出的核心区块链框架，它适合在复杂的企业内和企业间搭建联盟链。根据超级账本联盟的目标， Fabric 被建设为一个模块化的、支持可插拔组件的基础联盟链框架。；

与以太坊系的Quorum不同，Fabric从一开始就只考虑企业间的应用。其独有的channel概念，将企业根据业务目的不同以不同的子网连接起来， 每一个子网对应一个channel，而每个channel有自己独立的区块链。而Quorum很显然是只有一个公网（所有企业节点都加入进去），企业与企业间的私有业务是通过Private Manager 完成的。

理解channel的最简单方法就是，将它类比为一个消息服务提供的Topic，实际上Fabic最早就是基于Kafka 的分布式消息服务来实现。

       在Fabric网络中，一个企业可以有一个或多个节点加入整个联盟链；一个企业可以加入1个或者多个Channel（子网）；  一个节点可以加入1个或者多个channel。每个channel构成一个子网，所以Fabric 是 一种由子网组成的网络。

那么Fabric是怎么实现智能合约的执行和完成业务上链（将事务结果记录在区块链里）的呢？

与其它框架不同， Fabric 将整个过程分成了三个阶段：

业务背书阶段 ： 客户的请求发送的背书节点，通过智能合约完成业务的计算（但不更新状态），并完成背书；将背书结果返回个客户端。

业务的排序阶段 ： 客户端将背书结果通过Channel被发送到排序节点（orderer），在排序节点完成事务的排序，并打包到block里，最后下发给所有连接到channel的节点。

业务验证并写入账本阶段 : 通过Gossip 网络，所有Channel的节点都会接收到新的block，节点会验证block中的每一个事务，确定是否有效：有效地将会跟新world state，无效的将会标志为“无效”，不会更新World state，但整个block会被完整的加入到帐本中（包括无效的事务）。

根据以上的描述，Fabric 节点实际可以分为  ，普通节点和Order节点：

 Peer, 普通节点, 完成背书（包括只能合约的执行）和验证.

orderer,  排序节点，完成排序。

加入orderer节点的Fabric网络可以被描述如下：

每一个Channel，都定义了所有属于channel的节点，但是并不需要所有节点都连接到Orderer 节点（节点间可以通过gossip 协议通讯来传播私有数据或事务）.

       在区块链中，共识是区块链的基础。与公有链不同，联盟链的共识要求所有加入账本的事务是确定的、最终的，也就是不可以有分叉，区块与区块间的顺序是一定的，只存在唯一条链。在Fabric 中，这个客观需求正是由排序实现的，所有的事务将被提交给orderer节点获得确定的顺序，并最终打包成block进入帐本。 Fabric 从1.4.1开始支持基于Raft实现排序服务,  可以认为基于Raft实现共识。

基于RAFT的排序服务相对于早期的Kafka 具有更好的分布性，配置更加简单，是联盟链里常用的一个常用的达成共识的算法，Quorum就 默认使用RAFT作为共识层。简单的说，RAFT是一个leader和follower的模式， 所有加入RAFT网络的节点，任意时候都有一个leader,  只有这个leader有权决定事务的顺序，并打包成Block，其它节点只能作为follower提交事务和同步block。

基于FAFT网络，每个企业可以有一个或多个节点参与到Orderer中去。在Frabric中企业间的网络连接可以变化成如下形式：

       区块链的使用用户在以太网中被称作EOA（External of Account）, EOA的载体是钱包。我们沿用这个概念，来看看Fabric是如何实现用户和发起事务的。Fabric中EOA是一个CA中心发布的certificate（x.509），一个Certificate代表一个Identity（这与以太坊还是有很大区别的， 以太坊中一个EOA其实是一个hash地址），EOA能够参与的channel以及被授权的操作是有channel的MSP（ Membership Service  Provider）决定的（如下图）。

注：certificate 是一种密码学上验证身份的通用做法； certificate包含了个人的信息，公钥以及发布这个certificate的CA的签名。验证方只需要拥有这个CA的证书（包含CA的公钥），就可以验证这个签名是否正确，certificate的内容是否有篡改。简单的说，通过CA和Certificate，我们可以获得一个可验证的的身份和信任链。

      如上图，fabric中通要使用Wallet作为EOA的载体，一个Wallet中可以包含多个Identity（x.509 certificate）。 Identity 通过 CA提供的信任链来验证正确性。

  验证了身份之后， Fabric 通过MSP在区块链网络中解决该身份是否代表组织的成员和在组织内具有什么角色。例如，channel首先会验证当前用户Identity是否是有效地身份，然后通过MSP查看其所处的企业和具有的角色，最终确定该用户是否有权执行操作。

可以说，Fabric的访问控制是通过MSP来完成的。在每一个需要访问控制的地方都需要定义一个MSP。  例如，每个channel都定义一个MSP，这个MSP规定了在channel范围内资源的访问权限。 MSP 是Fabric里一个晦涩难懂的概念，也是其赋予企业间安全访问的基础。

前文提到， Fabric 将业务处理和上网分成了三个部分， 背书，排序，验证后加入账本。

其中背书是Fabric执行智能合约的阶段。以太坊中，智能合约是在EVM中执行的，有多种语言支持。 在Fabric，智能合约被称为chaincode： 一个chaincode 可以理解为是智能合约的容器，可以包含一个或多个智能合约， 不用于EVM, chaincode是在 JVM 或NodeJS中执行。

客户应用程序通过智能合约来访问账本，每一个可访问的智能合约都被安装在客户端可以访问的节点上，并被定义在channel里。（有只能合约的节点被称为背书节点，没有只能合约的节点被称未提交节点，提交节点只维护账本）

客户应用提交一个交易请求， 请求到达背书节点， 背书节点首先会验证客户的签名，确保客户的身份有权执行本次交易，接着执行交易提及的智能合约（chaincode），并生成一个背书响应（或者叫做交易提案，tran-proposal）。这个背书响应中通常包含World state 的读集合，写集合， 以及节点对本次交易的签名。这里与以太坊系联盟链最主要的不同是： 背书阶段只模拟交易，并不真正更新交易结果。 而真正更新交易在第三阶段完成。背书节点最后将生成的背书响应fanhui给客户端， 智能合约部分的执行就结束了。

通常一个交易的执行需要多方的签名，所以客户端需要将一个交易发送给多个背书节点，这些背书节点的选择需要满足背书策略的要求。

下图是一个包含有客户、背书节点，提交节点的网络示意图。

根据Fabric官方的参考文档，客户交易的正果过程可使用下图描述。

如上图，从1到3，为背书阶段，4为排序阶段，4.1,4,2, 5为验证提交阶段。 参考 Frabic的节点 概念，可以了解更多在交易细节的概念。  

总的来看， Fabric 更专注于企业间，通过上文，可以让大家对Fabric的基本构成与概念有一个总的了解。  Fabric本身并不神秘，都是使用的现有的企业间的技术。要更好的了解，建议参考阅读分布式消息系统和企业的安全基础设施（CA相关）的支持。与以太坊系联盟链实现比较，  Fabric 的子网更概念对于复杂企业间应用适应更强，但是其复杂的安全考量，使得运营成本很高，另外，Fabric 使用Certificate做为用户身份，有很大的局限性，在新的2.0里，Fabric对于此处将有所改变。

下一篇，我们将来看看Sawtooth , 由Inter 提供的区块链框架。

区块链之联盟链(一) 认识以太坊

区块链之联盟链(二) 认识Quotum

区块链之联盟链(三) 认识Fabric

区块链之联盟链(四) 认识Sawtooth