> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/blockchain_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/blockchain_guide/13_fabric_design/design.md).

# 架构设计

*注：本章架构设计主要基于 Fabric 1.x 及后续版本。随着版本的演进，架构在模块化和性能上不断优化，但核心的交易模型和节点角色设计保持了一致性。关于 2.x/3.0 引入的智能合约（链码）生命周期管理等新特性，详见后续《管理链上代码》章节。*

传统的区块链平台（如比特币、早期以太坊）通常采用 **排序-执行（Order-Execute）** 的架构。在这种架构中，网络中的所有节点必须按照一致的顺序，依序执行每一笔交易。这种设计虽然结构简单，但容易遇到明显的性能瓶颈，并且由于所有节点必须执行所有智能合约逻辑，对智能合约的确定性（如不能包含随机数、时间戳）提出了极高的要求。

为了突破这些限制，满足企业级高并发、高隐私保护的业务需求，Hyperledger Fabric 创新性地提出了 **执行-排序-验证（Execute-Order-Validate）** 的解耦架构。

Fabric 的整体重构围绕着以下核心组件展开：**Peer节点（包含背书节点、提交节点和 Gateway 服务）**、**排序服务节点（Orderer）**、**客户端（Client/Gateway API）** 以及 **成员身份管理服务（CA）**。

## 核心组件与角色分工

在现代 Fabric 架构中，节点的功能被清晰地解耦，不同的物理节点可以承担不同的网络角色：

### 1. 客户端节点（Client）

客户端代表最终用户（应用程序），是发起交易的源头。Fabric v2.4 之后推荐客户端使用 Fabric Gateway API（Go、Java、Node.js）连接一个受信任的 Gateway Peer，由 Gateway 服务代表客户端完成背书选择、背书收集、交易提交和提交状态查询。它的主要职责包括：

* 构造交易提案（Proposal），对提案或交易信封进行签名，并提交给 Gateway Peer。
* 在需要时指定目标背书组织；默认情况下由 Gateway 结合发现服务和背书策略选择合适的背书 Peer。
* 接收 Gateway 返回的已准备交易信封，完成签名后通过 Gateway 提交给排序服务。
* 等待提交状态事件或订阅链码事件，监听交易最终提交或验证失败的结果。

### 2. Peer 节点（Peer）

Peer 节点是 Fabric 网络的主体，负责维护账本数据（区块链和世界状态）以及执行智能合约（链码）。根据参与交易流程的不同阶段，Peer 节点在逻辑上可以细分为两类角色（同一个物理 Peer 节点可以同时扮演这两种角色）：

* **背书节点（Endorser）：** 背书节点负责对来自 Gateway 或兼容客户端的**交易提案进行模拟执行**。当收到提案后，Endorser 会在一个隔离的沙盒环境（通常是 Docker 容器）中运行对应的智能合约，对交易合法性和 ACL 权限进行校验，并生成模拟执行的结果，即**读写集（ReadWriteSet）**。此时交易并没有真正改变账本状态。Endorser 会对读写集进行密码学签名并返回给 Gateway 或兼容客户端。
* **提交节点（Committer）：** 提交节点负责维护最终的账本状态。**所有加入通道的 Peer 节点都是提交节点**。当 Committer 从排序服务拉取新区块，或在可选配置下通过 Gossip 接收到新区块后，会对每个交易的背书签名是否满足策略，以及交易读写集是否存在版本冲突（如双花问题）进行最终的**验证（Validate）**。验证通过的合法交易会被标记为有效，并更新到本地账本的历史区块和世界数据库中。

### 3. 排序节点（Orderer）

Orderer 节点组成了排序服务（Ordering Service），它们**不关心交易的具体内容，也不维护世界状态**，并且不执行智能合约逻辑。 排序服务的唯一核心职责是**达成共识并全局排序**：接收 Gateway 或兼容客户端提交的已背书交易，确定交易发生的全局顺序，将它们打包成区块，并通过 Deliver 服务供通道内有权限的 Peer 拉取。现代生产配置通常让 Peer 直接从排序服务拉取新区块；通过少数 Leader Peer 再用 Gossip 向组织内传播区块是可选配置。 Fabric 中的排序服务是可插拔的，现代版本默认且推荐使用的是基于 Raft 协议（Crash Fault Tolerant，CFT）的排序服务，以提供企业级的高可用性和一致性。自 **Fabric v3.0**（2024 年 9 月发布）起，正式引入了 **BFT（Byzantine Fault Tolerant）排序服务**，能够容忍最多 f 个恶意排序节点（需要至少 3f+1 个节点），适用于跨组织信任边界的排序集群场景。

### 4. 成员权限管理（Fabric CA）

企业级账本是带许可的（Permissioned），网络中的每一个实体（Peer, Orderer, Client）都必须拥有明确的数字身份（X.509 证书）。 Fabric CA 负责网络内的身份管理，提供注册（Registration）和登记（Enrollment）服务，为实体签发**注册证书（ECert）** 和用于加密通信的 **TLS 证书**。通过 MSP（Member Service Provider）组件，Fabric 网络在处理交易时强制校验身份的合法性，拦截任何未经授权的操作。

## 交易流程剖析

有了明确的角色分工后，我们可以清晰地梳理出 Fabric 中一笔交易从发起到最终确认的生命周期，也就是其引以为傲的 **“执行-排序-验证”** 流程。

![示例交易过程](/files/-M5y-SS41vSucPj7SG42)

交易的完整生命周期可分为三个主要阶段：

### 阶段一：提案与执行（Execute / Endorsement）

1. **发起提案**：客户端（Client）构造一个交易提案（Proposal），指定要调用的链码名称和函数参数，并使用自己的身份私钥进行签名。现代应用通常把提案发送给受信任的 Gateway Peer，由 Gateway 根据链码、私有数据集合和状态级背书策略计算并选择需要的背书 Peer。
2. **模拟执行**：背书节点收到提案后，首先验证客户端的签名及权限。然后，在当前的账本状态下，背书节点**模拟执行（Execute）** 指定的链码逻辑。
3. **生成读写集**：模拟执行不会立刻更新账本。链码执行过程中对状态数据库的所有读取（Read）和最终的写回意图（Write）会被记录下来，生成一个**读写集（ReadWriteSet）**。
4. **背书响应**：背书节点使用自身的私钥对这个包含了读写集的响应进行签名（这被称作“背书”），并返回给 Gateway；Gateway 收集足够背书后把待签名的交易信封返回给客户端。

### 阶段二：打包与排序（Order）

5. **收集确认**：Gateway 持续收集来自不同背书节点的响应。当有效背书签名满足背书策略后，Gateway 组装包含原始提案、读写集和背书签名的交易信封，并交给客户端签名。兼容旧流程的客户端仍可自行收集背书，但这不再是推荐的默认应用模型。
6. **提交排序**：客户端签名后，通常通过 Gateway 将完整交易发送给排序服务（Orderer）。
7. **全局共识与打包**：Orderer 不看交易内容，只是将并发到达的大量交易按照先后顺序排列好，打包生成新的区块。这样保证了全网上所有的 Peer 节点未来看到的交易顺序是绝对一致的。

### 阶段三：验证与提交（Validate / Commit）

8. **区块交付**：Peer 通过 Deliver 服务从排序服务拉取新区块并进入提交流程。旧式或特殊配置下，可以由组织内的 Leader Peer 拉取区块后再通过 Gossip 分发给其他 Peer；在 Fabric v2.2 之后的默认和推荐方向中，减少网络级联传播，让 Peer 直接从排序服务获取区块更常见。
9. **并发验证**：Committer 收到区块后，会对区块中的**每一笔**交易进行两道关键的**验证（Validate）**：
   * 验证这笔交易的背书签名是否真的满足了链码配置的背书策略（防止客户端伪造或背书数量不足）。
   * 验证交易的读写集版本号。即，从模拟执行（阶段一）到此时准备写入账本（阶段三）的时间差内，这笔交易读取过的状态有没有被其它并发的交易篡改过（多版本并发控制冲突检查）。
10. **最终提交与状态更新**：如果上述验证通过，该交易被标记为合法（Valid）；如果发生冲突，则标记为非法（Invalid）。最后，无论合法还是非法，该区块都会被追加到区块链的末尾（保证不可篡改的历史），但是**只有合法的交易对应的写集，才会被更新到 Peer 的世界状态数据库中**。
11. **事件通知**：Peer 节点产生事件通知，告知客户端交易已成功写入或者验证失败。

## 世界状态与账本存储

在上述流程中，Peer 节点维护的账本（Ledger）深刻体现了这种设计的合理性。每个 Peer 节点的账本在物理上实际上包含了两个不同的部分：

1. **底层区块链（Blockchain Log）：** 这是一个只能追加（Append-Only）的数据结构，通常存储在文件系统中。它记录了所有区块的串联历史，包含了所有发生过的交易记录，无论这笔交易在最后的验证环节是成功还是失败。这保证了极强的**审计性（Auditability）**，任何人都可以回放区块日志完全重构出当前的状态。
2. **世界状态数据库（World State）：** 这是一个键值对（Key-Value）数据库，只保存账本在当前时刻的最新状态（即所有合法交易执行后的最终结果集）。链码的执行和查询通常直接在世界状态数据库上进行以提升效率。目前 Fabric 支持 LevelDB（默认）和 CouchDB（支持更复杂的富查询如 JSON 选择器）两种状态数据库引擎。

通过将不可篡改的历史日志和最新的查询状态解耦，Fabric 兼顾了区块链的加密安全性和企业级应用查询性能的需求。