如何入职京东、华为、IBM等大厂？你需要学懂这门语言

来源 | 《区块链技术进阶与实战》

作者 | 蔡亮、李启雷、梁秀波

编辑 | 乔治

出品 | 区块链大本营、人民邮电出版社

Hyperledger 是当前业界较为认可的联盟链实现，作为其最重要的子项目，Fabric 自然也备受关注。从开始孵化到发展至今，Fabric 的架构设计也在演进过程中逐渐地改进与完善。本文将深入探索 Fabric，对 Fabric 总体架构进行分析，并通过与过往架构对比的方式来探讨 Fabric 新架构的特点和优势。

如今包括华为、 IBM、京东在内的许多互联网大厂和一些中小企业都在使用联盟链超级账本，很显然，学懂 Fabric 很有必要，未来年薪百万不是梦

架构解读

Fabric 在架构设计上采用了模块化的设计理念，从下图整体逻辑架构来看，Fabric 主要由3个服务模块部组成，分别是成员服务（Membership Service）、区块链服务（Blockchain Service）和链码服务（Chaincode Service）。

• 成员服务提供会员注册、身份保护、内容保护、交易审计功能，以保证平台访问的安全性和权限管理。
• 区块链服务负责节点的共识管理、账本的分布式计算、账本的存储以及节点间的 P2P 协议功能的实现，是区块链的核心组成部分，为区块链的主体功能提供底层支撑。
• 链码服务则提供一个智能合约的执行引擎，为 Fabric 的合约代码（智能合约）程序提供部署运行环境。

同时在逻辑架构图中，还能看到事件流（Event Stream）贯穿三大服务组件间，它的功能是为各个组件的异步通信提供技术支持。

在 Fabric 的接口部分，提供了 API、SDK 和 CLI 这3种接口，用户可以用来对 Fabric 进行操作管理。

逻辑架构图

下面两张图展示了 Fabric 运行架构，v0.6版本的结构非常简单，应用-成员管理-Peer 呈现三角形关系，系统所有的业务功能均由 Peer 节点完成。

在v0.6版本中，Peer 节点承担了太多的业务功能，暴露出了扩展性、可维护性、安全性、业务隔离等方面的诸多问题。

v0.6运行时架构

因此，在v1.0版本中，官方对架构进行了改进和重构。可以清晰地看到，v1.0版本将共识服务部分从 Peer 节点中完全分离出来，独立形成一个新的节点提供共识服务和广播服务。同时v1.0版本引入了通道的概念，实现多通道结构和多链网络，带来更为灵活的业务适应性。同时还支持更强的配置功能和策略管理功能，进一步增强系统的灵活性。

v1.0运行时架构

相比v0.6版本，新的架构使得系统在很多方面有了很大的提升，主要有以下的四大优势。

• 合约代码信任的灵活性（chaincode trust flexibility） v1.0版本从架构上，将合约代码的信任假设（trust assumptions）与共识服务（ordering service）的信任假设进行了分离。新版本的共识服务可以由一组单独的节点（orderer）来提供，甚至允许出现一些失效节点或恶意节点。而对于合约代码程序而言，它可以指定不同的背书节点，这极大地增强了合约代码的灵活性。
• 可扩展性（scalability） 在新的架构下，负责为指定合约代码背书的背书节点与共识节点是一种正交的关系，所以相比原来v0.6架构所有业务功能都在Peer节点上执行，v1.0版本架构的扩展性有了很大的提升。尤其是当不同的合约代码所指定的背书节点不存在交集时，系统可以同时进行多个合约代码程序的背书操作，这很好地提高了系统处理的效率。
• 机密性（confidentiality） Mutichannel 的设计使得对内容和执行状态更新有机密性需求的合约代码的部署变得容易了。
• 共识模块性（consensus modularity） v1.0架构将共识服务从 Peer 节点分离出来独自成为共识节点，共识服务还被设计为可插拔的模块化组件，允许不同共识算法的实现来应用于复杂多样的商业场景。

成员服务

成员服务可以为 Fabric 的参与者提供网络上的身份管理、隐私、保密性和可审核性的服务。

下面重点介绍PKI体系的相关内容并介绍用户的注册过程。

1、PKI体系

PKI（Public Key Infrastructure，公钥基础设施）的目标就是实现不同成员在不见面的情况下进行安全通信，Fabric 当前采用的模型是基于可信的第三方机构，也就是证书颁发机构

（Certification Authority，CA）签发的证书。CA 会在确认申请者的身份后签发证书，同时会在线提供其所签发证书的最新吊销信息，这样使用者就可以验证证书是否仍然有效。

证书是一个包含公钥、申请者相关信息以及数字签名的文件。数字签名保证了证书中的内容不能被任何攻击者篡改，而且验证算法可以发现任何伪造的数字签名。这样公钥和身份被捆绑在一起，不能篡改，也不能伪造，就可以实现成员管理。

在非许可区块链中，参与者不需要经过授权，网络上的所有节点都可以拥有平等提交交易或

者记账的权利，网络中的节点并不存在角色区别，都是统一的对等实体。

但是成员服务把 PKI 体系和去中心化共识协议组合在一起，将非许可链转变为了一个许可区块链。在许可区块链中，实体需要注册来获取长期的身份证书（例如注册证书），并且这个身份证书还可以根据实体类型来进行区分。

对于用户而言，通过注册操作，交易证书颁发机构（Transaction Certificate Authority，TCA）会给注册的用户颁发一个匿名的证书，而对于交易来说，需要通过交易证书来对给需要提交的交易进行认证，并且交易证书会一直存储于区块链上。

成员服务实际上是一个认证中心，负责为用户提供证书认证和权限管理的功能，对区块链网络中的节点和交易进行管理和认证。

在 Fabric 的系统实现中，成员服务由几个基本实体组成，它们互相协作来管理网络上用户的

身份和隐私。这些实体有的负责验证用户的身份，有的负责在系统中为用户注册身份，有的为用户在进入网络或者调用交易时提供所需的证书凭据。PKI 是一个基于公钥加密的框架体系，它不仅可以确保网络上的数据安全交换，而且还可以用来确认管理对方的身份。同时在 Fabric 系统中，PKI 还被运用于管理密钥和数字证书的生成、分发以及撤销。

通常情况下，PKI 体系包含证书颁布机构（CA）、注册机构（RA）、证书数据库和证书存储实体。其中，RA 是一个信任实体，它负责对用户进行身份验证以及对数据、证书或者其他用于支持用户请求的材料进行合法性审查，同时还负责创建注册所需的注册凭证。CA 则会根据 RA 的建议，给指定用户颁发数字证书，这些证书由根 CA 直接或分层进行认证。成员服务的详细实体如下图所示。

成员服务实体组成

下面针对图中的实体进行进一步介绍说明。

Root Certificate Authority（Root CA）

根 CA，代表 PKI 体系中信任的实体，同时也是 PKI 体系结构中的最顶层认证机构。

Enrollment Certificate Authority（ECA）

负责在验证用户提供的注册凭证后发出注册证书（ECerts）。

Transaction Certificate Authority（TCA）

负责在验证用户提供的注册凭证后发出交易证书（TCerts）。

TLS Certificate Authority （TLS-CA）

负责颁发允许用户使用其网络的 TLS（Transport Layer Security，传输层安全协议）证书和凭据。

Enrollment Certificates（ECerts）

ECerts 是长期证书。它们针对所有角色颁发。

Transaction Certificates（TCerts）

TCerts 是每个交易的短期证书。它们是由 TCA 根据授权的用户请求颁发的。此外，TCerts 可以被配置为不携带用户身份的信息。它们使得用户不仅可以匿名地参与系统，还可以防止事务的可链接性。

TLS-Certificates（TLS-Certs）

TLS-Certs 是用于系统和组件之间进行通信的证书。它们携带其所有者的身份，并用于网络级安全性。

Code Signer Certificates（CodeSignerCerts）

负责对代码进行数字签名，通过对代码的数字签名来标识软件来源及软件开发者的真实身份，以此保证代码在签名之后不被恶意篡改。

金融 IC 卡系统中也使用了 PKI 体系，它的架构如下图所示。与 Fabric 的 PKI 体系相比，它没有 TCert，每次交易都是使用 ECert 完成，所以这个系统中的交易是没有匿名的。

金融IC卡PKI架构

2、用户/客户端注册过程

前面介绍了成员服务的 PKI 体系的实体及其基本功能，接下来针对具体的用户注册流程做一

个简单的介绍。下图展示了一个用户登记流程的高层描述，它分为两个阶段：离线过程与在线过程。

用户注册过程

a）离线过程

• 每个用户或者 Peer 节点必须向RA注册机构提供身份证件（ID证明），同时这个流程必须通过带外数据（out-of-band，OOB）进行传输，以提供 RA 为用户创建（和存储）账户所需的证据。
• RA 注册机构返回用户有关的用户名和密码，以及信任锚（包含TLS-CA Cert）。如果用户可以访问本地客户端，那么客户端可以将 TLS-CA 证书作为信任锚的一种方式。

b）在线过程

• 用户连接客户端以请求登录系统，在这一过程中，用户将用户名和密码发送给客户端。
• 用户端接着代表用户向成员服务发送请求，成员服务接受请求。
• 成员服务将包含几个证书的包发送给客户端。
• 一旦客户端验证完成所有的加密材料是正确有效的，它就会将证书存储于本地数据库中并通知用户，至此，用户注册完成。

区块链服务

区块链服务包含4个模块：共识管理、分布式账本、账本存储以及 P2P 网络协议。共识管理用于在多个节点的分布式复杂网络中使消息达成共识，分布式账本与账本存储负责区块链系统中所有的数据存储，比如交易信息、世界状态等。而P2P网络协议则是网络中节点的通信方式，负责 Fabric 中各节点间的通信与交互。

1、P2P 网络

P2P 网络是一种在对等实体之间分配任务和工作负载的分布式应用架构，是对等计算模型在

应用层形成的一种组网或网络形式。在 P2P 网络环境中，彼此连接的多台计算机之间都处于对等的地位，各台计算机有相同的功能，无主从之分。一台计算机既可作为服务器，设定共享资源供网络中其他计算机所使用，又可以作为工作站。

一般来说，整个网络不依赖专用的集中服务器，也没有专用的工作站。而区块链所处的分布式环境中，各个节点间本应该是平等的，天然适合 P2P 网络协议。

在 Fabric 的网络环境中，节点是区块链的通信实体。

存在三类不同的节点，分别是客户端节点（Client）、Peer 节点（Peer）以及共识服务节点（Ordering Service Node 或者 Orderer）。

客户端节点代表着终端用户实体。它必须连接到 Peer 节点后才可以与区块链进行通信交互。

同时客户端节点可以根据它自己的选择来连接到任意的 Peer 节点上，创建交易和调用交易。在实际系统运行环境中，客户端负责与 Peer 节点通信提交实际交易调用，与共识服务通信请求广播交易的任务。

Peer 节点负责与共识服务节点通信来进行世界状态的维护和更新。它们会收到共识服务广播的消息，以区块的形式接收排序好的交易信息，然后更新和维护本地的世界状态与账本。

与此同时，Peer 节点可以额外地担当背书节点的角色，负责为交易背书。背书节点的特殊功能是针对特定的交易设置的，在它提交前对其进行背书操作。每个合约代码程序都可以指定一个包含多个背书节点集合的背书策略。

这个策略将定义一个有效的交易背书（通常情况下是背书节点签名的集合）的充要条件。需要注意的是，存在一个特殊情况，在安装新的合约代码的部署交易中，（部署）背书策略是由一个系统合约代码的背书策略指定的，而不能自己指定。

共识服务节点 Orderer 是共识服务的组成部分。共识服务可以看作一个提供交付保证的通信组织。共识服务节点的职责就是对交易进行排序，确保最后所有的交易是以同样的序列输出，并提供送达保证服务的广播通信服务。关于共识服务，之后还将详细介绍。

谈完节点的类型，再来看看网络的拓扑结构，在v0.6版本中，整个网络由两类节点构成：VP（Validating Peer）验证节点和 NVP 非验证节点。如下图所示，网络中包含了4个验证节点，并且每个节点还连接着2个非验证节点，整个网络的共识则由4个验证节点构成。

在v1.0版本中，网络拓扑结构随着网络节点类型的变化也发生了很大的改变，其中共识服务节点一起组成共识服务，将共识服务抽离出来，而 Peer 节点中可以分为背书节点或者提交 Peer 节点，并且它们还可以进行分组，然后整个共识服务与 Peer 节点所构成的组一起形成新的完成网络。

网络拓扑结构

同时，在v1.0版本中，Fabric 引入了新的通道概念，在共识服务上支持多通道消息传递，使

得 Peer 节点可以基于应用访问控制策略来订阅任意数量的通道；也就是说，应用程序可以指定 Peer 节点的子集架设通道。这些 Peer 节点组成提交到该通道交易的相关者集合，而且只有这些 Peer 节点可以接收包含相关交易的区块，与其他交易完全隔离。

Fabric 支持多链与多通道，即系统中可以存在多个通道以及多条链，如下图所示。应用根据业务逻辑决定将每个交易发送到一个或多个通道，不同通道上的交易不会存在任何联系。

总的来说，Fabric 在节点和网络方面的一些重构和新特性使得 Fabric 的交易处理能力有了很好的增强，而且很好地实现了隐私隔离。

多通道结构

2、共识服务

网络中的 Orderer 节点聚集在一起形成了共识服务。它可以看作一个提供交付保证的通信组

织。共识服务为客户端和 Peer节点提供了一个共享的通信通道，还为包含交易的消息提供了一个广播服务的功能。

客户端连接到通道后，可以通过共识服务广播消息将消息发送给所有的 Peer 节点。共识服务可以为所有消息提供原子交付保证，也就是说，在 Fabric 中共识服务保证了消息通信是序列化和可靠的。换句话说，共识服务输出给所有连接在通道上的 Peer 节点相同的消息，并且输出的逻辑顺序也是相同的。

共识服务可以有不同的实现方式，在v1.0版本中，Fabric 将共识服务设计成了可插拔模块，

可以根据不同的应用场景配置不同的共识选项。

目前，Fabric 提供了3种模式实现：Solo、Kafka 和 BFT。

• Solo 是一种部署在单个节点上的简单时序服务，主要用于开发测试，它只支持单链和单通道。
• Kafka 是一种支持多通道分区的集群共识服务，可以支持 CFT（Crash Faluts Tolerance）。它容忍部分节点宕机失效，但是不能容忍恶意节点。其基本实现是基于 Zookeeper 服务，使用的分布式环境中要求总节点数与失效节点数目满足 n>=2f+1。
• BFT 则是拜占庭容错模式，这种模式允许在分布式环境中存在恶意节点，也允许节点宕机，但是它要求分布式环境中总节点数据与失效节点数目满足 n>=3f+1 的关系。

提供的3种配置模式，从 Solo 到 Kafka 再到 BFT，面临的分布式的环境越来越复杂，当然这也导致共识服务处理性能有所降低，所以应该根据系统所处环境来选择最优的配置选项。

3、分布式账本

区块链技术从其底层构造上分析，可以将其定义为一种共享账本技术。账本是区块链的核心

组成部分，在区块链的账本中，存储了所有的历史交易和状态改变记录。

在 Fabric 中，每个通道都对应着一个共享账本，而每个连接在共享账本上的 Peer 节点，都能参与网络和查看账本信息，即它允许网络中的所有节点参与和查看账本信息。账本上的信息是公开共享的，并且在每个 peer 节点上，都维持着一份账本的副本。下图展示了 Fabric 账本的结构。

共享账本结构

从图中可以看出，共享账本以文件系统的形式存储于本地。共享账本由两个部分组成：图中

链式结构的 Chain 部分和图中右边存储状态数据的 State 部分。其中，Chain 部分存储着所有交易的信息，只可添加查询，不可删改。State 部分存储着交易日志中所有变量的最新值，因为它表示的是通道中所有变量键值对的最新值，所以有时称为“世界状态”。

合约代码调用执行交易来更改目前的状态数据，为了使这些合约代码高效交互，设计将最新

的键值对数据存储于状态数据库中。默认的状态数据库采用的是 Level DB，但是可以通过配置切换到 Couch DB 或者其他。

合约代码服务

合约代码服务提供了一种安全且轻量级的方式，沙箱验证节点上的合约代码执行，提供安全

容器服务以及安全的合约代码注册服务。其运行环境是一个“锁定”和安全的容器，合约代码首先会被编译成一个独立的应用程序，运行于隔离的 Docker 容器中。在合约代码部署时，将会自动生成一组带有签名的智能合约的 Docker 基础镜像。在 Docker 容器中，Peer 节点与合约代码交互过程如下图所示。

链码与 Peer 节点交互过程

步骤如下：

1、合约代码通过 gRPC 与 Peer 节点交互，当 Peer 节点收到请求的输入后，会通过发送一个合约代码消息对象给对应的合约代码。

2、合约代码调用 Invoke()方法，通过 getState() 和 putState() 方法进行读取和写入数据，向 Peer 节点获取账本状态信息和发送预提交状态。

3、合约代码发送最终输出结果给 Peer 节点，节点对输入和输出信息进行背书签名，完成签

名提交。

好啦，以上为 Hyperledger Fabric 的架构详解，想了解更多区块链技术内容，日常宠幸一下区块链大本营吧