超级账本Fabric的架构与设计

超级账本Fabric项目自诞生之日起就吸引了全球众多企业的密切关注。

超级账本Fabric架构上核心特性主要包括：

1. 解耦了原子排序环节与其他复杂处理环节，消除了网络处理瓶颈，提高可扩展性；

2. 解耦交易处理节点的逻辑角色为背书节点（Endorser）、确认节点（Committer），可以根据负载进行灵活部署；

3. 加强了身份证书管理服务，作为单独的Fabric CA项目，提供更多功能；

4. 支持多通道特性，不同通道之间的数据彼此隔离，提高隔离安全性；

5. 支持可拔插的架构，包括共识、权限管理、加解密、账本机制都模块，支持多种类型；

6. 引入系统链码来实现区块链系统的处理，支持可编程和第三方实现。

超级账本Fabric的整体架构如下图所示。

Fabric整体架构

Fabric为应用提供了gRPC API，以及封装API的SDK供应用调用。应用可以通过SDK访问Fabric网络中的多种资源，包括账本、交易、链码、事件、权限管理等。

应用开发者只需要跟这些资源打交道即可，无需关心如何实现。其中，账本是最核心的结构，记录应用信息，应用则通过发起交易来向账本中记录数据。

交易执行的逻辑通过链码来承载。整个网络运行中发生的事件可以被应用访问，以触发外部流程甚至其他系统。

权限管理则负责整个过程中的访问控制。

账本和交易进一步地依赖核心的区块链结构、数据库、共识机制等技术；链码则依赖容器、状态机等技术；权限管理利用了已有的PKI体系、数字证书、加解密算法等诸多安全技术。

底层由多个节点组成P2P网络，通过gRPC通道进行交互，利用Gossip协议进行同步。

层次化结构提高了架构的可扩展和可插拔性，方便开发者以模块为单位进行开发。

超级账本Fabric根据交易过程中不同环节的功能，在逻辑上将节点角色解耦为Endorser和Committer，让不同类型节点可以关注处理不同类型的工作负载。

典型的交易处理过程如下图所示。

示例交易处理过程

在整个交易过程中，各个组件的功能主要为：

1. 客户端（App）： 客户端应用使用SDK来跟Fabric网络打交道。首先，客户端从CA获取合法的身份证书来加入到网络内的应用通道。

发起正式交易前，需要先构造交易提案（Proposal）提交给Endorser进行背书（通过EndorserClient提供的ProcessProposal(ctx context.Context, signedProp *pb.SignedProposal)(*pb.ProposalResponse,error)接口）。

客户端收集到足够（背书策略决定）的背书支持后可以利用背书构造一个合法的交易请求，发给Orderer进行排序（通过BroadcastClient提供的Send(env *cb.Envelope)error接口）处理。

客户端还可以通过事件机制来监听网络中消息，来获知交易是否被成功接收。命令行客户端的主要实现代码在peer/chaincode目录下。

2. Endorser节点： 主要提供ProcessProposal(ctx context.Context,signedProp *pb.SignedProposal)(*pb.ProposalResponse,error)方法（代码在core/endorser/endorser.go文件）供客户端调用，完成对交易提案的背书（目前主要是签名）处理。

收到来自客户端的交易提案后，首先进行合法性和ACL权限检查，检查通过则模拟运行交易，对交易导致的状态变化（以读写集形式记录，包括所读状态的键和版本，所写状态的键值）进行背书并返回结果给客户端。

注意网络中可以只有部分节点担任Endorser角色。主要代码在core/endorser目录下。

3. Committer节点： 负责维护区块链和账本结构（包括状态DB、历史DB、索引DB等）。

该节点会定期地从Orderer获取排序后的批量交易区块结构，对这些交易进行落盘前的最终检查（包括交易消息结构、签名完整性、是否重复、读写集合版本是否匹配等）。

检查通过后执行合法的交易，将结果写入账本，同时构造新的区块，更新区块中BlockMetadata[2]（TRANSACTIONS_FILTER）记录交易是否合法等信息。

同一个物理节点可以仅作为Committer角色运行，也可以同时担任Endorser和Committer这两种角色。主要实现代码在core/committer目录下。

4. Orderer： 仅负责排序。

为网络中所有合法交易进行全局排序，并将一批排序后的交易组合生成区块结构。

Orderer一般不需要跟账本和交易内容直接打交道。主要实现代码在orderer目录下。对外主要提供Broadcast(srv ab.AtomicBroadcast_BroadcastServer)error和Deliver(srv ab.AtomicBroadcast_DeliverServer)error两个RPC方法（代码在orderer/server.go文件）。

5. CA： 负责网络中所有证书的管理（分发、撤销等），实现标准的PKI架构。

主要代码在单独的fabric-ca项目中。CA在签发证书后，自身不参与到网络中的交易过程。

核心概念与组件

超级账本Fabric采用了模块化功能设计，整体的功能模块结构如下图所示。

Fabric核心组件

超级账本Fabric面向不同的开发人员提供了不同层面的功能，自下而上可以分为三层：

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

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

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

下面介绍网络层相关组件的功能和作用。

网络层相关组件

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

节点（Peer）的概念最早来自P2P分布式网络，意味着在网络中担任一定职能的服务或软件。

节点功能可能是对等一致的，也可能是分工合作的。

在超级账本Fabric网络中，Peer意味着在网络中负责接受交易请求、维护一致账本的各个fabric-peer实例。这些实例可能运行在裸机、虚拟机甚至容器中。

节点之间彼此通过gRPC消息进行通信。按照功能角色划分，Peer可以包括三种类型：

1. Endorser（背书节点）： 负责对来自客户端的交易提案进行检查和背书；

2. Committer（确认节点）： 负责检查交易请求，执行交易并维护区块链和账本结构；

3. Submitter（提交节点）： 负责接收交易，转发给排序者，目前未单独出现。

这些角色是功能上的划分，彼此并不相互排斥。一般情况下，网络中所有节点都具备Committer功能；部分节点具有Endorser功能；Submitter功能则往往集成在客户端（SDK）进行实现。

Peer节点相关的主要数据结构包括PeerEndpoint和endorserClient。前者代表一个Peer节点在网络中的接入端点；后者实现EndorserClient接口，代表连接到Peer节点的客户端句柄，提供对Endorser角色实现的ProcessProposal(ctx context.Context,signedProp *pb.SignedProposal)(*pb.ProposalResponse, error)方法的访问。如下图所示。

Peer节点相关数据结构

排序者（Orderer）， 或称为排序节点，负责对所收到的交易在网络中进行全局排序。

Orderer主要提供了Broadcast(srv ab.AtomicBroadcast_BroadcastServer) error和Deliver(srv ab.AtomicBroadcast_DeliverServer) error两个接口。

前者代表客户端将数据（交易）发给Orderer，后者代表从Orderer获取到排序后构造的区块结构。

客户端可以使用atomicBroadcastClient结构访问这两个接口。

atomicBroadcastClient结构如下图所示，维持了一个gRPC的双向通道。

atomicBroadcastClient结构

Orderer可以支持多通道。 不同通道之间彼此隔离，通道内交易相关信息将仅发往加入到通道内的Peer（同样基于gRPC消息），从而提高隐私性和安全性。

在目前的设计中，所有的交易信息都会从Orderer经过，因此，Orderer节点在网络中必须处于可靠、可信的地位。

从功能上看，Orderer的目的是对网络中的交易分配全局唯一的序号，实际上并不需要交易相关的具体数据内容。因此为了进一步提高隐私性，发往Orderer的可以不是完整的交易数据，而是部分信息，比如交易加密处理后的结果，或者仅仅是交易的Hash值、Id信息等。

这些改进设计会降低对Orderer节点可靠性和安全性的需求。社区目前也已经有了一些类似的设计讨论（参考FAB-1151：Side DB-Private Channel Data）。

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

1. 操作Fabric网络： 包括更新网络配置、启停节点等；

2. 操作运行在网络中的链码： 包括安装、实例化、发起交易调用链码等。

这些操作需要跟Peer节点和Orderer节点打交道。特别是链码实例化、交易等涉及到共识的操作，需要跟Orderer交互，因此，客户端往往也需要具备Submitter的能力。网络中的Peer和Orderer等节点则对应提供了gRPC远程服务访问接口，供客户端进行调用。