Hyperledger Fabric 核心概念与组件

要理解超级账本 Fabric 的设计，首先要掌握其最基本的核心概念与组件，如节点、交易、排序、共识、通道等。

弄清楚这些核心组件的功能，就可以准确把握 Fabric 的底层运行原理，深入理解其在架构上的设计初衷。知其然，进而可以知其所以然。

总体来看，超级账本 Fabric 面向不同角色的用户提供不同模块功能，这些模块自下而上可以分为三层。

●网络层模块：面向系统管理人员。实现 P2P 网络，提供底层构建区块链网络的基本能力，包括代表不同角色的节点和服务。

●共识机制和权限管理模块：面向联盟和组织的管理人员。基于网络层的连通，实现共识机制和权限管理，提供分布式账本的基础。

●业务层模块：面向业务应用开发人员。基于分布式账本，支持链码、交易等与业务相关的功能模块，提供更高一层的应用开发支持。

网络层相关组件

网络层通过软、硬件设备，实现了对分布式账本结构的连通支持，包括 Peer 节点、排序节点、客户端等参与角色，还包括成员身份管理、Gossip 协议等支持组件。

Peer 节点

节点的概念最早来自 P2P 分布式网络，意味着在网络中担任一定职能的服务或软件。节点功能可能是对等一致的，也可能是分工合作的。

Peer 节点是 Fabric 网络的基本单元，在网络中负责对交易提案进行背书，并接受排序后的交易来维护账本的一致性。这些实例可能运行在裸机、虚拟机甚至容器中。节点之间通过 gRPC 消息进行通信。

目前按照功能角色，Peer 可以分为两种类型：

●Endorser（背书节点），负责对来自客户端的交易提案进行检查和背书。只有部署了链码的 Peer 可以对交易进行背书。

●Committer（记账节点），负责检查交易请求，执行交易并维护区块链和账本结构。所有 Peer 都是记账节点。

这些角色是逻辑功能上的划分，彼此并不相互排斥。一般情况下，网络中所有节点都具备 Committer 功能；部分节点具备 Endorser 功能。

排序节点

排序节点负责在网络中对所收到的交易进行全局排序。

排序节点主要提供了 Broadcast 和 Deliver 两个接口。前者代表客户端将数据（交易）发给排序节点，后者代表从排序节点获取到排序后构造的区块结构。

排序节点可以支持多通道。不同通道之间彼此隔离，通道内与交易相关的信息将仅发往加入通道内的排序节点和 Peer 节点，从而提高隐私性和安全性。

从功能上看，排序节点的目的是对网络中的交易分配全局唯一的序号，实际上并不需要与交易相关的具体数据内容。因此为了进一步提高隐私性，发往排序节点的可以不是完整的交易数据，而是部分信息，比如交易加密处理后的结果，或者仅仅是交易的 Hash 值、ID 信息等。这些私密数据机制（参考 FAB-1151）会提高网络的隐私性保护。

客户端

客户端是用户和应用与区块链网络打交道的桥梁。客户端主要包括两大职能：

●操作 Fabric 网络，包括更新网络配置、启停节点等。

●操作运行在网络中的链码，包括部署链码、发起交易调用链码等。这些操作需要与 Peer 节点和排序节点打交道。特别是链码实例化、交易等涉及共识的操作，都需要发送交易到排序节点。

网络中的 Peer 和排序节点对应提供了 gRPC 远程服务访问接口，供客户端进行调用。

目前，除了基于命令行的客户端之外，超级账本 Fabric 已经拥有了多种语言的 SDK。这些 SDK 封装了对底层 gRPC 接口的调用，可以提供更完善的客户端和开发支持，包括 Node.js、Python、Java、Go 等多种实现。

成员身份管理

CA 节点（Fabric-CA）负责对 Fabric 网络中的成员身份进行管理。Fabric 网络目前采用数字证书机制来实现对身份的鉴别和权限控制，CA 节点则实现了 PKI 服务，主要负责对身份证书进行管理，包括生成、撤销等。

需要注意的是，CA 节点可以提前签发身份证书，发送给对应的成员实体，这些实体在部署证书后即可访问网络中的各项资源。后续访问过程中，实体无须再向 CA 节点进行请求。因此，CA 节点与网络中交易的处理过程是完全解耦的，不会造成性能瓶颈。

Gossip 协议

Fabric 网络中的节点之间通过 Gossip 协议来进行状态同步和数据分发。

Gossip 协议是 P2P 领域的常见协议，用于进行网络内多个节点之间的数据分发或信息交换。由于其设计简单，容易实现，同时容错性比较高，而被广泛应用到许多分布式系统，例如，Cassandra 采用 Gossip 协议来实现集群失败检测和负载均衡。

Gossip 协议的基本思想十分简单，数据发送方从网络中随机选取若干节点，将数据发送过去；接收方重复这一过程（往往只选择发送方之外节点进行传播）。这一过程持续下去，网络中所有节点最终（时间复杂度为节点总个数的对数）都会达到一致。数据传输的方向可以是发送方发送或获取方拉取。

在 Fabric 网络中，节点会定期地利用 Gossip 协议发送它看到的账本的最新的数据，并对发送消息进行签名认证。通过使用该协议，主要实现如下功能：

●通道内成员的探测。新加入通道的节点可以获知其他节点的信息，并发送 Alive 信息宣布在线；离线节点经过一段时间后可以被其他节点感知。

●节点之间同步数据。多个节点之间彼此同步数据，保持一致性。另外，Leader 节点从排序节点拉取区块数据后，也可以通过 Gossip 传播给通道内其他节点。

共识机制相关组件

共识（consensus）概念来自分布式系统领域。在 Fabric 中，共识过程意味着区块链网络成员对于某一批交易的发生顺序、合法性以及它们对账本状态的更新结果，达成一致的观点。满足共识则意味着多个节点可以始终保证相同的状态，对于以同样顺序到达的交易可以进行一致的处理。具体来看，Fabric 中的共识包括背书、排序和验证三个环节的保障。

背书过程

背书（endorsement）是指背书节点对收到的来自客户端的请求（交易提案）按照自身的逻辑进行检查，以决策是否予以支持的过程。

通常情况下，背书过程意味着背书节点对请求提案和造成的状态变更（读写集）添加数字签名。

对于调用某个链码的交易来讲，它需要获得一定条件的背书才被认为合法。例如，必须是来自某些特定身份成员的一致同意；或者某个组织中超过一定数目的成员的支持；或者指定的某个成员个体的支持。这些规则由链码的背书策略来指定。背书策略内容是比较灵活的，可以使用多种规则进行自由组合，并在链码进行实例化（instantiate）的时候指定。

排序过程

排序（ordering）意味着对一段时间内的一批交易达成一个网络内全局一致的顺序，通常是由排序节点组成的集群来提供。

目前，排序服务采用了可拔插的架构，2.0 版本中使用 etcdRaft 类型的非拜占庭容错共识机制。另外，也有第三方实现了拜占庭容错共识。

排序服务除了负责达成一致顺序外，并不执行其他操作，这就避免其成为整个网络的处理瓶颈。同时，每个通道可以选择排序节点组，使得整个网络很容易进行横向扩展，提高整体的吞吐率。

验证过程

验证（validation）是对排序后的一批交易进行提交到账本之前最终检查的过程。

验证过程包括：检查交易结构自身完整性，检查交易所带背书签名是否满足预设的背书策略，检查交易的读写集是否满足多版本并发控制（Multi-VersionConcurrency Control，MVCC）的相关要求等。

交易在验证环节如果包括状态写操作，则对应读集合中所有状态的当前版本必须与执行背书时一致。否则该交易会被标记为不合法（invalid），对应交易不会被执行，也不会影响到世界状态。

确认前的验证过程是十分有必要的，可以避免交易并发时的状态更新冲突，确保交易发生后所有节点看到的结果都是一致的。

权限管理相关组件

权限管理是超级账本 Fabric 项目对区块链领域的一大贡献。Fabric 中提出了成员服务提供者（Membership Service Provider，MSP）的概念，抽象代表了一个身份验证的实体。基于 MSP 可以实现对不同资源进行基于身份证书的权限验证。

成员身份服务

身份是实现权限管理的基础。Fabric 中在访问任何资源实体（成员、节点、组织等）时都会通过签名进行身份验证，确保系统的安全性。身份基于成员服务提供者实现。一个资源实体（用户、组织、Peer、Orderer 等）的 MSP 结构中往往包括签名和验证算法，以及一组符合 X.509 格式的证书（信任相同的根证书）。典型 MSP 结构包括：

●一组信任的根证书，是整个组织证书信任的基础，根证书可以签发中间层证书。

●MSP 的管理员身份证书，管理员可以对 MSP 中证书进行管理。

●一组信任的中间证书（可选），中间证书由根证书签发。

●一组信任的 TLS 根证书和中间层证书（可选），启用 TLS 时候作为其验证基础。

●证书撤销列表（可选），被吊销的证书名单。

注意：MSP 中各实体资源的证书必须被证书信任树上的叶子节点签名。中间层签名的证书会被认为是非法实体证书。

组织

组织（organization）代表一组拥有共同根证书（可以为根 CA 证书或中间 CA 证书）的成员，可以对应到业务逻辑中的同一个企业、部门或团队。

这些成员由于共享同样的信任根，彼此之间信任度很高，可以相互交换比较敏感的内容。同一个组织的成员节点在网络中可以认为是同一个组织身份，代表组织进行签名。组织中成员可以分为普通成员角色或者管理员角色，后者拥有更高的权限，可以对组织配置进行修改。

组织在网络中一般包括名称、ID、MSP 信息、管理策略、认证采用的密码库类型、锚点节点位置等信息。不同组织之间为了进行业务沟通和数据共享，可以加入同一个应用通道。

联盟

联盟（consortium）是由若干组织构成的集合，是联盟链场景所独有的结构形式。联盟一般用于多个组织相互合作的场景，例如，某联盟中指定需要所有参与方同时对交易背书，才允许在网络中进行交易。

联盟中的组织成员使用同一个系统通道，并且遵循相同的通道创建策略（channelcreationpolicy）。通道在创建时也必须指定所绑定的联盟信息。例如，某个联盟内可能定义必须所有成员都同意才能创建新的通道；或者任何成员都可以自行创建新的通道。

在设置联盟时候，每个组织都需要指定自己的 ID 信息，该信息必须与该组织所关联的 MSP ID 一致。此外，通道之间是独立的，应用通道创建之后，可以邀请联盟外的成员加入通道。

证书机制

证书（certif icate）是 Fabric 中权限管理的基础。目前采用了基于 ECDSA 算法的非对称加密算法来生成公钥和私钥，证书格式则采用了 X.509 的标准规范。Fabric 中采用单独的 Fabric CA 项目来管理证书的生成。每一个实体、组织都可以拥有自己的身份证书，并且证书也遵循了组织结构，方便基于组织实现灵活的权限管理。

业务层相关组件

对于应用开发人员来说，很多时候无须了解底层网络的实现细节，但十分有必要学习和掌握业务层的相关概念。交易、区块、链码、通道、链结构、账本等概念，体现了基于区块链技术的分布式账本平台的特点，支撑了上层的分布式应用。

交易

交易（transaction）是超级账本 Fabric 项目中的一个基础概念。交易意味着通过调用链码对账本状态进行一次改变。客户端可以通过发送交易请求来让分布式账本记录信息。

通常来说，要构造一次交易，首先要创建交易提案（transaction proposal）。当一个交易提案获得足够的背书支持时，可以构造出合法的交易请求，进而可以发给排序节点进行排序。

交易消息经过排序节点的排序后，会广播到网络中的各个节点进行确认。如果节点对交易进行本地验证通过，则对应接受该交易指定的状态变更，最终更新本地账本。

区块

区块（Block）意味着一组进行排序后的交易的集合。区块链以区块为单位对多个交易组进行共识，并将其历史进行链接。通过调整区块大小可以取得吞吐量和延迟之间的平衡。

区块包括区块头（Header）、数据（Data）、元数据（Metadata）三部分.

其中，Header 用于构建链式结构，包括 Number、PreviousHash、DataHash 三个域，共 72 字节。

●Number：记录了区块的序号，8 字节。初始区块的编号为 0。

●PreviousHash：记录前一个区块头结构（Header）的 SHA256 Hash 值，32 字节。初始区块中设为空值（nil）。

●DataHash：区块 Data 域的 Hash 值，32 字节。

注意区块头结构的 Hash 值为 SHA256 (Number+PreviousHash+DataHash)，可以唯一确定区块内容（包括头结构和数据，但不包括元数据）。

Data 结构中以 Envelope 结构记录区块内的多个交易信息。这些交易可以采用默尔克树结构进行组织。在目前的实现中，Fabric 采用了单层（宽度为 math.MaxUint32）的默尔克树结构，实际上已退化为线性数组结构。

Metadata 结构中记录了一些辅助信息。

●BlockMetadataIndex_SIGNATURES=0：签名信息。目前对最新配置块索引和共识元数据（BlockMetadata，包括 OSN 和 Raft Id 之间的映射列表、下一个加入集群的节点的 Raft ID、当前区块的 Raft 索引）进行签名。被排序节点添加。

●BlockMetadataIndex_LAST_CONFIG=1：通道最新配置区块的序号。被排序节点添加，在 Raft 共识中弃用。

●BlockMetadataIndex_TRANSACTIONS_FILTER=2：交易状态标记。包括合法状态和一系列错误状态，在 protos/peer/transaction.pb.go 中定义。被 Peer 节点本地提交时添加。

●BlockMetadataIndex_ORDERER=3：通道的排序服务信息，被排序节点添加。Kakfa 模式下包括已处理的最后一条 Kafka 消息的 offset 等信息；Raft 共识中记录节点的 Raft ID 和下一个加入共识的序号。

●BlockMetadataIndex_COMMIT_HASH=4：2.0 版本中引入，包括对提交区块（txValidation Code 长度、txValidationCode 列表、所有写操作的排序字节组、上个区块的提交 Hash 值）的 SHA256 Hash 值。在 Peer 节点提交时候添加。

链码

链码即链上代码，是 Fabric 中十分关键的一个概念。链码源自智能合约的思想，并进行了进一步扩展，支持多种高级编程语言。

目前 Fabric 中支持两种类型的链码：用户链码和系统链码。前者运行在单独的容器中或由外部运行，提供对上层应用的支持，后者则嵌入在系统内，支持对系统进行配置和管理。

一般所说的链码为用户链码，通过提供可编程能力提供了对上层应用的支持。用户通过链码相关的 API 编写用户链码，即可对账本中状态进行更新操作。

链码经过部署操作后，即可被调用。在安装时，需要指定具体安装到哪个 Peer 节点（Endorser），安装包最终存放到 $CORE_PEER_FILESYSTEMPATH/chaincodes/ 路径下；启用链码时还需要指定通道名称。链码之间还可以通过互相调用来创建更灵活的应用逻辑。

Fabric 目前主要支持基于 Go、Java 和 Node.JS 语言的链码。

注意：在跨通道调用情况下，被调用链码暂时仅支持读操作。

通道

通道是网络中彼此隔离的数据共享渠道。每个通道拥有独立的账本，不同的 Peer 节点和排序节点可以加入不同的通道内。

通道与绑定到该通道上的配置和数据（包括交易、账本、链码实例、成员身份等），一起构成了一条完整的区块链。这些数据只会被加入通道内的组织成员所感知和访问，通道外的成员无法访问通道内数据。由于通道与账本（链结构 + 状态数据）是一一对应的，有时候两者概念可以混用。

目前，通道包括应用通道（application channel）和系统通道（systemchannel）两种类型。前者供用户应用使用，负责承载各种交易，同一个网络可以有多条应用通道，各条应用通道彼此完全独立；后者由排序节点维护，负责对网络层面的配置和应用通道进行管理。

通道在创建时，会指定所关联的访问策略、初始所包括的组织身份（证书范围等，通过 MSP 检验）、锚节点、排序节点信息等。通道创建后会构成一条区块链结构，初始区块中包含初始配置相关的信息。通道的配置信息可以由更新配置区块（reconf iguration block）进行更新。

加入应用通道内的节点需要指定或选举出代表节点（leading peer），负责代表组织从排序节点处拉取排序后的区块信息，然后通过 Gossip 协议传播给组织（准确地说，同一个 MSP）内其他节点。同时，每个组织可以指定锚节点（anchorpeer），负责代表组织与其他组织的成员进行数据交换。Raft 共识机制下，应用通道可以指定进行排序的排序节点集合（共识组），每个共识组在该通道上会动态选举出 Raft Leader。

特别地，所有排序节点都会加入系统通道内。该通道负责网络层面的配置管理（如联盟成员、排序参数）和应用通道的创建，并且是 Fabric 网络中启动时所创建的首个通道.