揭秘 Hyperledger Fabric(1/3):Fabric 架构

谈到私有区块链,Hyperledger Fabric 可能是最受欢迎和采用的区块链框架之一。 Hyperledger Fabric 已被多个行业采用,例如教育、医疗保健、物联网、物流、供应链等。 最近,NASA 发布了基于 Hyperledger Fabric 的用于安全、身份验证和隐私的空中交通管理区块链的提案。

为了支持未来的大规模采用,Hyperledger Fabric 刚刚发布了新版本 1.4,这是其第一个长期支持版本。此版本主要侧重于稳定性和生产运营。不可否认,Hyperledger Fabric 凭借其受欢迎程度和关键特性,吸引了许多软件开发人员、软件架构师、系统工程师等。

尽管如此,当我第一次学习 Hyperledger Fabric 时,我发现由于其庞大的技术堆栈,很难理解 Hyperledger Fabric 的真正工作原理。要真正理解它是如何工作的,学习者需要具备区块链技术、网络和系统架构、DevOps 运营、全栈软件开发、测试驱动和行为驱动开发、中级密码学、授权和访问控制,IT 安全方面、业务用例等多个方面的知识。

出于这个原因,我决定为 Hyperledger Fabric 初学者编写这个系列文章。如果您已经了解 Fabric 的底层架构,那么学习如何设计和开发 Hyperledger Fabric 网络和应用程序可能会更容易。因此,本系列文章不会涉及编程内容,而是专注于让读者了解 Hyperledger Fabric 架构。

本文目录:

  • Hyperledger Fabric 架构
  • Hyperledger Fabric 中的共识
  • Hyperledger Fabric 中的排序服务
  • 生产环境中的 Hyperledger Fabric
  • 总结

Hyperledger Fabric 架构

图 1. 两个组织加入同一频道的最简单的 Fabric 网络


在 Hyperledger Fabric 中,有一个通道(Channels)的概念,允许参与的组织相互加入和交流。通道(Channels)可能被认为是一个组织与加入同一通道的其他参与组织秘密通信的隧道。不参与相关通道的任何其他人永远无法访问与该通道相关的任何交易或信息。一个组织可以同时参与多个通道。上面的图 1 描述了最简单的 Hyperledger Fabric 网络,其中两个组织(即 Org1 和 Org2)加入了同一通道。下面我就对包括Peer、Orderer、CA、Client在内的Fabric组件一一简单介绍一下。

首先,Peer 是一个区块链节点,将所有交易存储在加入的通道上。每个 Peer 可以根据需要加入一个或多个频道。但是,同一Peer上不同通道的存储将是分开的。因此,组织可以确保机密信息仅在特定通道上共享给允许的参与者。

其次,排序节点(Orderer) 是 Fabric 共识机制中使用的最重要的组件之一。 排序节点(Orderer) 是一种服务,负责对交易进行排序,创建一个新的有序交易区块,并将新创建的区块分发给相关通道上的所有区块链节点(Peers)。关于 排序节点(Orderer) 的更多信息将在后面解释。

第三,证书颁发机构(Certificate Authority)CA 负责管理用户证书,例如用户注册、用户登记、用户注销等。更具体地说,Hyperledger Fabric 是一个需许可认证的区块链网络。这意味着只有获得许可的用户才能在授权通道上查询(query,访问信息)或调用(invoke,创建新交易)交易。 Hyperledger Fabric 使用 X.509 标准证书来表示每个用户的权限、角色和属性。换句话说,用户可以根据他/她拥有的权限、角色和属性,来查询或调用任何通道上的任何交易。

第四,Client 被认为是一个与 Fabric 区块链网络交互的应用程序。也就是说,Client可以根据其从其关联组织的 CA 服务器派生的证书上指定的权限、角色和属性与 Fabric 网络进行交互。

请注意,每个组件都涂有不同的颜色以区分不同的组织。大蓝框内的组件是链上 Fabric 网络实体,而蓝框外的组件被认为是链下实体。

图 2. 背书节点 对比 承诺节点

Fabric中有一个叫做链码(Chaincode)的智能合约(Smart Contract)概念。 目前,Golang、Node.js 和 Java 三种语言可以编写 Fabric 链码(Chaincode)。 要部署链码(Chaincode),网络管理员必须将链码(Chaincode)安装到目标节点(Peers)上,然后调用排序节点(Orderer)链码(Chaincode)实例化到特定通道(Channel)上。 在实例化链码(Chaincode)时,管理员可以为链码定义背书策略(endorsement policy)。 背书策略定义了哪些节点需要就交易结果达成一致,然后才能将交易添加到通道上所有节点的账本(Ledgers)中。

背书策略(endorsement policy)中指定的节点称为背书节点(Endorsing peer),它由已安装的链码(Chaincode)和其上的本地账本组成,而承诺节点(Committing peer)将只有本地账本。 图 2 区分了背书节点和承诺节点。 当我们达到 Fabric 共识部分时,将讨论更多关于此的内容。

图 3. 节点账本的内部组件

如图 3 所示,节点账本的内部组件包括区块链(Blockchain)和 世界状态(World State)。 区块链(Blockchain)保存特定通道上每个链码的所有交易历史。世界状态(World State)为每个特定的链码维护变量的当前状态。

Fabric 目前支持的两种类型的世界状态(World State)数据库包括 LevelDB 和 CouchDB。 LevelDB 是基于 Fabric Peer的默认键值数据库,而 CouchDB 是基于 JSON 的数据库,支持基于 JSON 对象的丰富查询操作。 例如,CouchDB 允许我们使用特定键设置资产并使用 JSON 查询语法查询过滤后的资产。 链码开发人员在开发链码时必须选择使用 LevelDBCouchDB

图 4. 附有链码和账本的 Fabric 网络

之前的 Fabric 网络可以用链码和账本装饰,如图 4 所示。 如您所见,Org1 的节点和 Org2 的 节点相互加入同一个通道。可以在同一个通道上实例化多个链码。此外,如果需要,可以升级实例化的链码。这使得链码可更新(updatable)或可修补(patchable)。

让我们关注排序节点(Orderer)排序节点(Orderer) 有特殊的系统链码(System chaincodes)和账本。系统链码收集网络(System chaincodes collect network)、通道和底层系统配置,使 Fabric 虚拟机正常工作;他们反对在单独的 docker 容器中运行的用户链码。

事实上,系统链码也在引导时注册和部署在节点上,但为了简单起见,它们没有放在图 4 中。系统链码包括但不限于:

  • QSCC(Query System Chaincode,查询系统链码)用于账本和Fabric相关的查询
  • 有助于规范访问控制的 CSCC(Configuration System Chaincode,配置系统链码)
  • LSCC(Lifecycle System Chaincode,生命周期系统链码),定义了通道的规则
  • ESCC(Endorsement System Chaincode,背书系统链码)用于背书交易
  • 用于验证交易的 VSCC(Validation System Chaincode,验证系统链码)
图 5. 具有多个通道的更复杂的 Fabric 网络

图 5 说明了具有多个通道的更复杂的 Fabric 网络。 Org1 的节点和Org2的节点 一起加入 Channel A,而 Org2 的节点 和 Org3 的节点加入 Channel B。通过单独的通道,加入同一通道的组织可以秘密地共享业务交易信息。

此外,一个链码可以在同一通道上调用另一个链码。 此外,一个链码还可以在不同的通道上调用另一个链码,以防在加入这两个相关通道的背书节点上执行调用链码,就像 Org2 的 节点 正在做的那样。


Hyperledger Fabric 中的共识

Fabric 共识具有丰富的多阶段和多层次的背书、有效性和版本控制检查。 在将交易区块写入账本之前,有多个阶段来确保所有参与者的许可、背书、数据同步、交易顺序和变更的正确性。

Hyperledger Fabric 使用基于许可投票的共识,该共识假设网络中的所有参与者都是部分信任的。 共识可以分为以下三个阶段。

  1. 背书(Endorsement)(下面图 6 中的步骤 1-3)
  2. 排序(Ordering)(下面图 6 中的步骤 4–5)
  3. 验证和承诺(Validation and Commitment)(下面图 6 中的步骤 6)
图 6. Fabric 交易调用工作流

图 6 描述了 Fabric 事务调用的工作流程:

  1. 客户端(Client)提出交易提议,用用户(User)的证书签署交易提议,并将交易提议发送到特定通道(Channel)上的一组预先确定的背书节点(Endorsing Peers)
  2. 每个背书节点(Endorsing Peers)从交易提议的有效负载中验证用户的身份和授权。如果验证检查通过,则背书节点(Endorsing Peers)模拟交易,生成响应和读写结合,并使用其证书对生成的响应进行背书。
  3. 客户端(Client)积聚并检查来自背书节点(Endorsing Peers)的已背书交易提议响应。
  4. 客户端(Client)将附有背书交易提议响应的交易发送给排序节点(Orderer)
  5. 排序节点(Orderer) 对接收到的交易进行排序,生成一个新的有序交易区块,并用其证书对生成的块进行签名。
  6. 排序节点(Orderer)将生成的区块广播给相关通道上的所有节点(同时向背书节点(Endorsing Peers)和 承诺节点(Comitting Peers))。然后,每个节点确保接收到的区块中的每笔交易都由适当的背书节点(Endorsing Peers)签名(即,从调用的链码的背书策略中确定)并且存在足够的背书。之后,将进行版本检查(称为多版本并发控制(MVCC)检查)以验证接收到的区块中每个交易的正确性。也就是说,每个节点都会将每个交易的 readset 与其账本的世界状态(World state)进行比较。如果验证检查通过,则交易被标记为有效,并且每个节点的世界状态(World state)都会更新。否则,交易被标记为无效而不更新世界状态(World state)。最后,无论该区块是否包含任何无效交易,接收到的区块都会附加到每个节点的本地区块链中。
  7. 客户端(Client)EventHub 服务接收任何订阅的事件。

Hyperledger Fabric 中的排序服务

排序节点(Orderer)可能是 Hyperledger Fabric 中最重要的组件之一。它充当将交易区块分发给相关通道上的所有节点的中心。出于这个原因,Orderer 可能被认为是 Fabric 网络中的最弱点。

Fabric Orderer 的当前实现支持两种类型的排序服务,即 Solo 和 Kafka。建议仅在开发环境中使用基于 Solo 的排序服务,因为这种服务由为所有客户端提供服务的单个进程组成。这很容易成为生产环境中的单点故障。

在生产中,打算使用基于 Kafka 的排序服务。借助 Kafka,我们可以建立一个 Kafka 集群和一个 ZooKeeper 集成,以提供崩溃容错的排序服务。

尽管 Kafka 会向 排序节点(Orderer) 提供 Crash Fault Tolerance (CFT) 共识,但仍然只能由一个组织来完全控制排序服务。然而,一个组织策划 排序节点(Orderer) 是不够的,因为该组织可能不值得信赖。

幸运的是,Fabric 排序服务被设计为可插拔的。目前,Byzantine Fault Tolerant (BFT)共识正在开发中。基于 BFT 的共识将使网络的参与组织能够共同控制排序服务,防止系统在恶意行为者或故障节点的情况下达成协议。


生产环境中的Hyperledger Fabric

Figure 7. 生产环境中的Fabric网络


在生产环境中,仍然可以有多个与 Fabric 相关的组件进行协作。图 7 总结了生产环境中 Fabric 网络的部署模型。

客户端应用程序可以通过两种方式与 Fabric 区块链网络交互:通过 Fabric SDK 或 Fabric CLI(命令行界面)。 Fabric SDK 提供了一套丰富的功能,适合在生产环境中使用。通常,客户端应用程序(图 7 中的 1 号客户端)通过连接到 RESTful API Server 的方式与 Fabric 网络进行交互,RESTful API Server 使用 Fabric SDK 作为库与区块链网络进行通信。 Fabric SDK 目前支持 Node.js 和 Java 语言。此外,Python、Golang 和 REST SDK 版本正在开发中。 Fabric CLI 适用于开发或维护模式(图 7 中的客户端 2)。

在 Fabric 中,CA 用于用户管理和证书颁发任务。有两种部署 Fabric CA 的方法。首先,在不扩展 LDAP 服务器的情况下设置 Fabric CA。通过此配置,Fabric CA 将用于注册用户、验证用户和颁发用户证书(即用户注册)。其次,通过扩展 LDAP 服务器设置 Fabric CA。使用此配置,Fabric CA 将仅用于颁发用户证书。而 Fabric CA 会委托 LDAP Server 来管理其他任务,例如注册用户、验证用户、注销用户等。 第二个选项适用于将 Fabric CA 与组织现有的 AD、LDAP 或 Radius 服务器连接。

CouchDB 可能是在生产环境中用作节点账本的世界状态(World state)数据库的最佳选择,因为它支持多种丰富的功能,例如 JSON 查询操作、数据库索引、数据复制、ACID 属性等。而 LevelDB 仅支持有限的操作.

为了支持 Fabric 排序服务的Crash Fault Tolerance (CFT,崩溃容错) 共识,使用 Kafka 代理集群扩展排序节点Orderer 是生产环境中的一种选择。为了使 Kafka 集群正常工作,需要一个 ZooKeeper 集群来协调分布式 Kafka 代理之间的本地任务。


总结

在本文中,您了解了 Hyperledger Fabric 的架构、Fabric 共识和排序服务的工作方式以及如何在生产环境中部署 Fabric 网络。 希望你喜欢我的内容并学习新的东西。