Fabric官方文档:https://hyperledger-fabric.readthedocs.io/en/release-2.2/

0.前言

在前面主要介绍了fabric的安装，而fabric的一些关键概念和底层架构都不太了解，本文主要针对fabric的一些关键概念以及网络结构和交易流程进行阐述。

1.Fabric的一些优势

1.1 联盟链

传统的无许可的公链区块链（比特币、以太坊等），几乎人人都可以参加，并且每个参与者都是匿名的，为了保证安全性，使用POW、POS等资源消耗量巨大的共识协议。而Fabric是一个联盟链系统，它是一个有许可的区块链，参与者是相互认识的，而不是匿名的。许可区块链在一组已知、已识别且经常经过审查的参与者中运行区块链，这些参与者在产生一定程度信任的治理模型下运行。许可区块链提供了一种方法来保护具有共同目标但可能彼此不完全信任的一组实体之间的交互。通过依赖参与者的身份，许可区块链可以使用更传统的崩溃容错（CFT）或拜占庭容错（BFT）共识协议，这些协议不需要昂贵的挖掘。

1.2 新的交易架构

大多数现有的智能合约区块链平台都遵循 订单执行架构，其中共识协议：

  • 验证和订购交易，然后将它们传播到所有对等节点，

  • 然后每个对等点依次执行事务。

由于所有交易都是由所有节点顺序执行的，因此性能和规模是有限的。智能合约代码在系统中的每个节点上执行这一事实要求采取复杂的措施来保护整个系统免受潜在恶意合约的侵害，以确保整个系统的弹性。

Fabric 引入了一种新的交易架构，我们称之为 execute-order-validate。它通过将交易流分为三个步骤来解决订单执行模型面临的弹性、灵活性、可扩展性、性能和机密性挑战：

  • 执行交易并检查其正确性，从而为其背书，
  • 通过（可插入的）共识协议订购交易
  • 在将交易提交到分类账之前，根据特定于应用程序的背书策略验证交易

1.3 隐私和保密

在一个公共的、无需许可的区块链网络中，它利用 PoW 作为其共识模型，交易在每个节点上执行。这意味着合同本身及其处理的交易数据都不能保密。每笔交易以及实现它的代码对网络中的每个节点都是可见的。在这种情况下，我们将合约和数据的机密性换成了 PoW 提供的拜占庭容错共识。

Hyperledger Fabric 是一个许可平台，通过其通道架构和私有数据功能实现机密性。在通道中，Fabric 网络上的参与者建立一个子网络，其中每个成员都可以看到一组特定的交易。因此，只有参与通道的节点才能访问智能合约（链码）和交易的数据，从而保护两者的隐私和机密性。私有数据允许在通道上的成员之间进行收集，从而实现与通道相同的保护，而无需创建和维护单独通道的维护开销。

2.Fabric网络结构及简介

2.1 网络结构

下面展示一个fabric官网上的一个典型Fabric网络结构：

最初看到这个网络架构会非常迷茫，因为太多组件了，接下来将会一个个组件的进行介绍。

  • R1R2R3R4表示一个个的组织

  • O4表示排序节点

  • P1P2P3表示对等点（PEER）

  • CA表示证书机构

  • S5 S6表示安装在对等点的链码

  • L1 L2表示账本

  • CC1 CC2表示背书策略

  • NC4表示网络配置

**在上图中，我们考虑，现在有R1、R2、R3 和 R4 四个组织一起开发一个联盟链，他们将建立和开发 Hyperledger Fabric 网络。**R4 已被指定为网络发起方——它已被授予设置网络初始版本的权力。R4 无意在网络上进行商业交易。R1 和 R2 需要在整个网络内进行专用通信，R2 和 R3 也是如此。组织 R1 有一个客户端应用程序，可以在通道 C1 内执行业务交易。组织 R2 有一个客户端应用程序，它可以在通道 C1 和 C2 中执行类似的工作。组织 R3 有一个客户端应用程序可以在通道 C2 上执行此操作。对等节点 P1 维护与 C1 关联的分类帐 L1 的副本。对等节点 P2 维护与 C1 关联的账本 L1 的副本和与 C2 相关联的账本 L2 的副本。对等节点 P3 维护与 C2 关联的账本 L2 的副本。网络根据网络配置 NC4 中指定的策略规则进行管理，网络受组织 R1 和 R4 的控制。通道 C1 根据通道配置 CC1 中指定的策略规则进行管理；通道受组织 R1 和 R2 控制。通道 C2 根据通道配置 CC2 中指定的策略规则进行管理；通道受组织 R2 和 R3 控制。有一个订购服务 O4，它作为 N 的网络管理点服务，并使用系统通道。订购服务还支持应用通道 C1 和 C2，用于将交易排序到区块中进行分发。这四个组织中的每一个都有一个首选的证书颁发机构。

2.2 排序节点

Fabric网络中，一个排序服务的启动，意味着网络形成了。上图中O4表示排序节点（ordering node），由组织R4创建起来，在上图中，他被R4通过网络配置策略创建，它用来给通道C1和C2中的所有交易进行排序，是维护共识的重要节点之一。

  • 交易数据需要先进行打包，然后再写入到区块中 （类似区块链中的矿工的工作）
  • 为什么要进行排序？
    • 解决双花问题。
    • 每发起一笔交易都会被orderer进行排序，通过特别的算法去解决双花问题。

除了他们的排序角色之外，排序者还维护允许创建频道的组织列表。这个组织列表被称为“联盟”，列表本身保存在“orderer system channel”（也称为“ordering system channel”）的配置中。默认情况下，此列表及其所在的频道只能由订购者管理员编辑。请注意，一个排序服务可能会保存多个这样的列表，这使得联盟成为 Fabric 多租户的载体。

2.3 CA

CA是证书颁发机构，它用于向管理员和网络节点颁发证书。Fabric是一个有许可的区块链，正需要这种身份保证。CA4在我们的网络中起着关键作用，因为它分发 X.509 证书，可用于将组件识别为属于组织 R4。CA 颁发的证书也可用于签署交易，以表明组织认可交易结果——这是其被接受到分类账上的先决条件。

证书到成员组织的映射是通过称为成员服务提供商 (MSP)的结构实现的 。网络配置 NC4 使用命名的 MSP 来标识 CA4 分发的证书的属性，这些证书将证书持有者与组织 R4 相关联。然后 NC4 可以在策略中使用这个 MSP 名称来授予来自 R4 的参与者对网络资源的特定权限。此类策略的一个示例是确定 R4 中可以向网络添加新成员组织的管理员。

2.4 对等节点(peer)

在上图中,P1P2P3分别为组织R1R2R3的对等节点，由各个组织创建，用来存储和同步账本数据，还有一些特殊的peer也有背书功能。在其上维护者账本l和S。在上图中，可以看到，P1有一个账本L1和一个链码S1，而P2有两个账本和两个链码，这是因为账本和链码是基于通道进行创建的，通道的概念请看下面。

  • 用户通过客户端工具对数据进行提交操作，数据写入到一个peer节点中。
  • peer节点之间的数据同步是Fabric框架做好的，不需要我们实现,具体实现机制后面会提到。

2.5 通道

通道是一种主要的通信机制，联盟成员可以通过它相互通信。通道最初由具有权限的网络配置者创建，一个网络中可以有多个通道，一个对等点可以加入多个通道。在上图中，P1和P2处在同一个通道C1中，P2和P3处在另一个通道C2中，通道内的通信外部是不可知的，就算是作为网络配置者的R4也不行。有效的保证的安全性，在同一个通道中，对等点的数量没有限制，所有的对等点在本地上通过共识维护一个一致性账本，同时通过链码的手段提供查询和修改账本的接口。其中，我们可以将 L1 视为物理托管在 P1 上，但 逻辑上托管在通道 C1 上。

2.6 账本

每个通道都有一个一致性账本，它物理托管在通道中所有的对等节点中（peer）。它包含两个部分，一部分为世界状态，世界状态在物理上实现为一个数据库，以提供简单高效的账本状态存储和检索。正如我们所见，账本状态可以有简单的或复合的值，为了适应这一点，世界状态数据库的实现可能会有所不同，从而允许有效地实现这些值。世界状态数据库的选项目前包括 LevelDB 和 CouchDB。

另一部分区块链，世界状态包含与一组业务对象的当前状态相关的一组事实，而区块链是关于这些对象如何到达其当前状态的事实的历史记录。区块链记录了每个分类帐状态的每个先前版本以及它是如何更改的。（注意，里面不是所有交易都是完成的，有一部分的交易被标记为无效，原因具体看交易流程）。

但是，将分类账呈现为一个单一的世界状态和单一的区块链，但这有点过于简单化了。实际上，每个链码都有自己的世界状态，与所有其他链码分开。世界状态位于命名空间中，因此只有同一链码中的智能合约才能访问给定的命名空间。

2.7 链码和客户端

链码和以太坊的智能合约非常相似，但是Fabric的链码可以通过GO、JAVA等语言进行编写，非常方便。链码编写后，和一致性账本一样，我们可以将链码 视为物理托管在对等节点 上，但 逻辑上部署在通道上。客户端可以使用fabric的SDK进行链码的调用，来查询或者更新通道上的一致性账本。

在上图中，A1A2A3表示的是客户，首先，客户也需要一个合理的身份，其身份由CA进行维护。在完成身份认证后，A就可以用自己的身份（不同身份具有不同权限）去调用通道上的链码来查询和更新账本了。

2.8 开发人员分组

3.Fabric交易流程

Fabric的交易流程可以理解为是 执行—排序—验证的三大步过程。

首先在交易前要明确几点：

  • 用户已经经过了CA认证，交易包括查数据或者写数据，不同的操作需要不同的身份权限。
  • 交易需要背书策略，背书策略可以是很简单的，也是可以很复杂的，由链码安装时保证，主要是为了保证此次交易满足一些特定条件，一个最简的背书策略如下：
    • 组织A中的成员必须同意
    • 组织B中的成员也必须同意

3.1 执行阶段：

  • 客户端给背书节点（peer节点中的一种）发送交易提案(就是发送调用链码功能的请求)

  • 背书节点对交易提案进行4点验证：

    • 格式是否正确；

    • 在之前没有被提交过；

    • (客户端的)签名是否有效；

    • 提交者/客户端是否被授权执行此次提案的操作。

  • 如果以上验证都通过，背书节点就将提案输入作为所调用链码函数的参数，对当前状态数据库模拟执行链码。

  • 执行完后，返回经过背书节点签名的执行结果(读写集)给客户端。

  • 然后客户端收集所有背书，直到满足所有的背书策略。

  • 如果应用程序的请求仅仅是查询账本，则应用程序将检查并提取查询响应信息，查询到此结束，更新账本还需要以下阶段。

3.2 排序阶段：

  • 客户端满足背书策略后，将提案、执行结果和背书组装成交易，发送给排序服务。
  • 排序服务不查看交易具体信息，只是简单的按通道、按时间顺序对接收的交易进行排序，并为每个通道创建区块(注意：排序服务接收到交易的顺序并不一定是交易被打包进入区块的顺序。且创建区块时，一般都是有一定数量的交易再一起打包，保证效率)。
  • 排序节点将区块发送到通道上的所有主节点(leader peer)，由主节点向其它peers分发交易。

3.3 验证阶段：

  • 当每个peer接收到新区块后，会对其中包含的交易进行验证，以确保满足背书策略，以及确保账本当前状态的”读集”变量没有变化(因为”读集”是由当前区块中的交易执行生成的)。
  • 然后每个peer将区块追加到本地的区块链副本上，并将”写集”提交到当前状态数据库。