Hyperledger Fabric区块链网络

参考资料：官方文档——区块链网络

1. 什么是区块链网络

区块链网络是为应用程序提供账本和智能合约服务的技术基础设施。首先，智能合约用于生成交易，这些交易随后被分发到网络中的每个节点，并在每个节点的账本副本上记录下来并且是不可篡改的。这个应用程序的用户可能是使用客户端应用的最终用户，或者是一个区块链网络的管理员。

多个组织作为一个联盟（consortium）聚集在一起形成网络，它们的权限由一组策略决定，这些策略在最初配置网络时由联盟商定。此外，网络策略可以随着时间的推移而变化，这取决于联盟中的组织的协议。

通俗的一点说，区块链网络也就是Fabric整个联盟链跑起来的环境，包括它的一些交易，共识等等都在区块链网络中发送，正所谓它是基础设施

2. 从零搭建一个较复杂的网络拓扑

在之前的文章Hyperledger Fabric的网络拓扑图与交易流程中我画了一张简单的网络拓扑图

这张图右方是一个简单的网络拓扑图，具体的解释信息可以到我之前的文章中去看下。

这一章我就根据官方文档，一步一步地做出一张详细负责的网络拓扑图，尽可能地去包含区块链网络中更多的成员。那么现在就开始吧

2.1 创建网络

让我们先从创建网络的基础开始，也就是需要画出一个整体的轮廓。

当一个排序节点启动以后，区块链网络就形成了。在上图示例网络中N中，包含单个节 O4 的排序服务根据网络配置 NC4 进行配置， NC4 赋予组织 R4 管理权限。在网络层面，证书颁发机构 CA4 用于向组织 R4 的管理员和网路节点分配身份信息。

定义区块链网络的第一个东西是排序服务O4。将一个排序服务看作是网络的初始管理点是很有用的。如前所述， O4 最初由组织 R4 中的管理员配置和启动，并托管在 R4 中。配置 NC4 包含描述网络初始管理功能集的策略。最初，在网络上只为 R4 授予这样的权限。现在 R4 是网络中唯一的成员。

我们还看到一个证书认证结构 CA4 ，它用于向管理员和网络节点颁发证书。证书颁发机构在区块链网络中扮演着关键角色，它颁发的证书主要用于两个方面

1. 颁发的 X.509 证书可用于标识属于组织 R4 的组件（ R4 组织的节点等）
2. 证书可以用于签署交易，以表明一个组织对交易结果部署，这是该笔交易可以被接受并记录到账本上的一个前提条件

首先，区块链网络的不同组件使用证书相互标识自己来自特定组织（身份证书）。不同组织通常使用不同的CA，而不仅仅限于 Fabric 提供的CA（实践中，组织基本使用自己的CA）

将证书同成员组织进行匹配是通过成员服务提供者 MSP （MeMembership Service Provider， MSP）来实现的。网络配置 NC4 使用一个命名的 MSP 来标识 CA4 分发的证书的属性，CA4 将证书持有者与组织 R4 关联起来。NC4 接下来会使用这个在规则中的 MSP 名字来分配在网络资源上的特殊权利。这种策略的一个例子是识别 R4 中的管理员，管理员可以向网络添加新的成员组织。

其次，X.509 证书可以用于客户端应用程序交易提案和智能合约交易相应中，以便对交易进行数字签名。随后，持有账本副本的网络节点在接受账本上的交易之前验证交易签名是否有效。

总结一下区块链网络的基本结构。有一个由证书颁发结构 CA4 定义的一组用户可访问的资源——网络 N，这些用户对网络 N 中的资源拥有一组权限，这些权限由网络配置 NC4 中包含的策略描述。当我们配置并启动排序服务节点 O4 时，整个网络就启动了。

2.2 添加网络管理员

NC4 最初配置为只允许 R4 用户在网络上拥有管理权限。在这一节中，我们将允许组织 R1 用户管理网络。让我们看看是如何演变的：

组织 R4 更新网络配置，是组织R1也成为管理员。在这一点之后，R1 和 R4 对网络配置具有同等的权限。

可以看到添加了一个新的组织 R1 作为管理员，R1 和 R4 在网络上拥有相同的管理权限。这意味着 R1 或 R4 低可以更新网络配置 NC4。

在这个简单的模式中，排序服务在网络中是一个独立的节点，就像例子中看到的。排序服务通常是多节点的，并且可以配置为在不同的组织中拥有不同的节点。例如，可以在 R4 中运行 O4 并将其连接到 O2，这是组织 R1 中的一个单独的排序节点，这样就有了多站点、多组织的管理结构。

所以现在来说，排序服务可以看做是一个管理节点，它给不同的组织提供了对于网络的管理的权限

2.3 定义联盟

虽然现在网络可以由 R1 和 R4管理，但是这样还是不够的。我们需要的第一件事是定义一个联盟。这个词表示“具有着共同命运的一个群组”，所以这个是在一个区块链网络中合理地选择出来的一个群组。

让我们来看看联盟是如何定义的：

一个网络管理员（可能是 R4 或者是 R1）定义了一个包含两个成员的联盟 X1，包含组织 R1 和 R2。这个联盟定义存储在网络配置 NC4 中，将在网络开发的下一阶段使用。CA1 和 CA2 分别是这些组织的证书认证机构。

上图显示了 R1 或者 R4 创建了一个新的联盟 X1，它将 R1 和 R2 定义为组成它的组织。我们也看到了 CA2 也被添加进来用来标识来自于 R2 的节点和。

注意，一个联盟可以有任意数量的组织成员

为什么联盟很重要？我们可以看到，一个联盟定义了网络中的一部分组织，它们都需要彼此进行交易——在本例中是R1和R2。如果组织有一个共同的目标，那么将他们联盟在一起是很有意义的。

2.4 为联盟创建一个通道

我们将使用联盟 X1 创建一个非常重要的部分——通道（Channel）。通道是一个主要的通信机制，通过它联盟的成员可以彼此通信。网络中可以有多个通道，我们从第一个开始。

让我们看看第一个通道是如何添加到网络中的：

使用 X1 为 R1 和 R2 创建了通道 C1。通道由通道配置 CC1 控制，完全独立与网络配置。 CC1 由 R1 和 R2 管理，它们对 C1 拥有相同的权限。R4 在 CC1 中没有任何权限。

通道 C1 为联盟 X1 提供了一个私有通信机制。我们可以看到通道 C1 已经连接到排序服务 O4，但是没有附加任何其他内容。之后可能会在通道 C1 中添加 Peer 节点。

需要注意的是，组织 R3 和 R4 并不在这个通道中——它用于 R1 和 R2 之间的交易处理。之前提到 R4 如何授予 R1 创建新联盟的权限，值得一提的是，R4 也允许 R1 创建通道。在这个图中，创建通道 C1 的可能是组织 R1 或 R4（很抱歉，R2 没有这个权利）。

同样注意，一个通道可以有任意数量的组织连接到它

请注意通道 C1 如何具有与网络配置 NC4 完全独立的配置 CC1。 CC1 包含控制 R1 和 R2 对通道 C1 拥有的权限的策略，正如我们看到的，R3 和 R4 在这个通道中没有权限。R3 和 R4 只有在由 R1 或 R2 添加到通道配置 CC1 中的适当策略时才能与 C1 交互。特别需要注意的是，R4 不能将自己添加到通道 C1 中——它只能由 R1 或 R2 授权。

通道非常有用，它是 Fabric的一个鲜明的特点。通道定义了一个联盟成员之间进行私有沟通和私有数据交互的机制。通道提供区别于其他通道和网络的隐私。Fabric非常强大，它允许组织共享基础设施（同一个通道），同时又保持私有（私有数据）。这里没有矛盾——网络中的不同联盟需要适当共享不同的信息和流程，而通道提供了一种有效的机制。通道提供了一种高效的基础设施共享，同时维护数据和通信隐私。

通道是完全自由于网络的，只有在通道配置中指定的组织才能控制它。对网络配置 NC4 的任何更新都不会对通道配置 CC1 产生直接影响；例如，如果更改了联盟定义 X1，也不会影响通道 C1 的成员（除非再去更改通道配置）。因此，通道是有用的，因为它们允许组成通道的组织之间进行私人通信。此外，通道中的数据与网络的其他部分完全隔离，包括其他通道（通道之间是相互隔离的）。

另外，还定义了一个特殊的系统通道供排序服务使用。它的运行方式与常规通道完全相同，因此常规通道有时称为应用程序通道。我们通常不需要担心这个通道。

2.5 节点和账本

现在开始使用通道将区块链网络和组织组件连接在一起。我们可以看到网络 N 中又新增了两个组件，即节点 P1 和账本实例 L1 。

节点 P1 已经加入通道 C1。P1 物理上保存这个账本 L1 的副本。 P1 和 O4 可以使用通道 C1 进行通信。

节点是保存区块链账本副本的网络组件。 P1 在网络中的目的单纯地是存放 L1 账本的一个副本供其他人访问。我们可以将 L1 看做物理上托管在 P1 上，但是逻辑上托管在通道 C1 上。

也就是说，每个通道拥有一个账本，通道上的每个节点拥有一个账本的副本，这个账本逻辑上是属于这个通道的。

P1 配置的一个关键部分是由 CA1 发布的 X.509身份信息，它将 P1 与组织 R1 关联起来。一旦 P1 启动，它就可以使用排序节点 O4 连接通道 C1（因为通道 C1 中有组织 R1）。当 O4 收到这个连接请求时，它使用通道配置 CC1 来确定 P1 在这个通道上的权限。例如，CC1 确定 P1 是否可以读写账本 L1 的信息。

2.6 应用程序和智能合约

现在通道 C1 拥有了一个账本，我们可以连接客户端来使用由 Peer 节点提供的服务了。

注意网络的变化：

一个智能合约 S5 已经安装到 P1 上。组织 R1 中的客户端应用程序 A1 可以使用 S5 通过 Peer 节点 P1 访问账本。A1、P1 和 O4 都加入了通道 C1，即他们都可以使用该通道提供的通信设施。

A1 可以使用通道 C1 连接到特定的网络资源——在这种情况下，A1 可以连接到 Peer 节点 P1 和排序节点 O4。就像 Peer 节点和排序节点一样，一个客户端应用也会有一个使它和组织相关联的身份信息。在示例中，客户端应用程序 A1 与组织 R1 相关联；虽然它在 Fabric 区块链网络之外，但是它通过通道 C1 与之连接。

事实上，A1 想要通过 P1 直接访问账本 L1，是要通过智能合约（链码）的特殊程序 S5 来管理的。智能合约 S5 定义了对账本的所有通用访问模式； S5 定义了一组方法，通过这些方法可以查询或更新账本 L1。总之，客户端应用程序 A1 必须通过智能合约 S5 才能访问账本 L1。

每个组织中的应用程序开发人员都可以创建智能合约链码，以实现联盟成员共享的业务流程。智能合约用于帮助生成交易，这些交易随后可以分发到网络中的每个节点。

智能合约必须先安装，后实例化。

2.6.1 安装一个智能合约

在智能合约 S5 被开发完之后，组织 R1 中的管理员必须将其安装到 Peer节点 P1 上。这是一个简单的操作，安装完成后，P1 对 S5 有了充分的了解。具体来说，P1 可以看到 S5 的实现逻辑（一种程序代码），它可以用该程序代码来访问账本 L1。我们将此与 S5 接口进行对比，S5 接口只描述 S5 的输入和输出，而不考虑它的实现。

当一个组织在一个通道中有多个 Peer 节点时，它可以选择哪个节点可以安装智能合约；它不需要每个节点上都安装智能合约。

2.6.2 实例化一个智能合约

但是，仅仅为 P1 安装了 S5，其他连接到通道 C1 的组件并不知道它；它必须首先在通道 C1 上实例化。在示例中，只有一个 Peer 节点 P1，组织 R1 中的管理员必须使用 P1 在通道 C1 上实例化 S5。实例化之后，通道 C1 上的每个组件都知道存在 S5；在示例中，这意味着 S5 可以由客户端应用程序 A1 调用了。

注意，尽管通道上的每个组件现在都可以访问 S5，但是它们不能看到它的程序逻辑。这对安装了它的节点仍然是私有的，在我们的例子中，这意味着 P1。

从概念上讲，这意味着实例化的是智能合约的接口，而不是安装的智能合约的实现。

安装智能合约显示了我们如何任务它是物理上托管在 Peer 节点上的，而实例化智能合约则显示了我们如何从逻辑上考虑它是由通道托管的。

2.6.3 背书策略

实例化时提供的最重要的附加信息是背书策略。它描述了哪些组织必须批准交易，然后才会被其他组织接受到它们的账本上。在示例中，只有在 R1 或 R2 背书的情况下，交易才能被接受并存储到账本 L1 上。

实例化行为将背书策略放置在通道配置 CC1 中；它是通道的任何成员都可以访问它。

2.6.4 调用一个智能合约

一旦在 Peer 节点上安装了智能合约并在通道上实例化了它，客户端应用程序就可以调用它了。客户端应用程序通过向智能合约背书策略指定的组织所属的节点发送交易提案来实现这一点。交易提案作为智能合约的输入，智能合约使用它生成一个经过背书的交易相应，该响应由 Peer 节点返回给客户端应用程序。

这些交易相应与交易提案打包在一起，形成一个完整背书的交易，它们会被分发到整个网络。

我们可以看到组织 R1 完成参与了网络。它的应用程序从 A1 开始，通过智能合约 S5 访问账本 L1，生成将由 R1 背书的交易，最后会被接受并添加到账本中，因为这满足了背书策略。

2.7 网络设置完成

我们的目标是为联盟 X1（由组织 R1 和 R2 构成）创建一个通道。网络开发的下一阶段将看到组织 R2 将它的基础设施添加到网络中。

让我们看看网络是如何演化的：

网络是通过增加 R2 组织的基础设施而发展起来的。具体来说，R2 添加了 Peer 节点 P2，它会存有账本 L1 的一个副本和智能合约 S5。 P2 也加入了通道 C1，应用程序 A2 也是如此。A2 和 P2 是使用 CA2 的证书识别的。所有这些意味着应用程序 A1 和 A2 都可以使用 Peer 节点 P1 或 P2 在 C1 上调用 S5。

我们可以看到组织 R2 在通道 C1 上添加了一个 Peer 节点 P2。P2 还包含账本 L1 和智能合约 S5 的副本。我们可以看到 R2 还添加了客户端应用程序 A2，它可以通过通道 C1 连接到网络。为了实现这一点，R2 组织中的管理员创建了 Peer 节点 P2 并将其连接到通道 C1，与 R1 中的管理员的方法相同。

我们创建了我们的第一个可运行的网络！在网络开发的这个阶段，我们有一个通道，组织 R1 和 R2 可以在这个通道中彼此交易。具体来说，这意味着应用程序 A1 和 A2 可以使用通道 C1 上的智能合约 S5 和账本 L1 生成交易。

2.7.1 生成并接受交易

相比较于经常会存有账本副本的 Peer 节点，我们能够看到两种类型的 Peer 节点，一类是存储智能合约而另一类则不存。在我们的网络中，每个 Peer 节点都会存储智能合约的副本，但是在更大的网络中，将有更多的 Peer 节点不存储智能合约的副本。Peer 节点运行安装在它上边的智能合约，但是它可以通过连接到通道来了解智能合约的接口。

不能认为没有安装智能合约的 Peer 节点在某种程度上较差的。拥有智能合约的 Peer 节点都可以在其账本 L1 副本上验证并随后接受或拒绝交易。然而，只有安装了智能合约的 Peer 节点才能参与交易背书的过程。而交易背书是生成有效交易的核心。

2.7.2 节点类型

虽然所有的 Peer 节点是相同的，但它们可以根据网络的配置方式承担多个角色。

记账节点

在一个通道中的每个 Peer 节点都是一个记账节点。它们会接收生成的交易的区块。在这些区块被 Peer 节点验证之后会提交到它维护的账本副本中。

背书节点

一个带有一个智能合约的 Peer 节点都可以作为一个背书节点。然而，想要成为一个真正的背书节点，在 Peer 节点上的智能合约必须要被一个客户端应用使用，来生成包含数字签名的响应。背书节点这个术语就是对这个事实的真实参考。

对于一个智能合约的一个背书策略明确了在交易能够被接受并且记录到记账节点的账本副本之前，哪些组织的节点需要为交易提供数字签名。

领导节点

当一个组织在一个通道中具有多个节点的时候，会有一个领导节点，它是一个负责将交易从排序节点分发到该组织中其他记账节点的节点。一个节点可以选择参与静态的或者动态的领导节点的选择。对于静态的，0个或者多个节点可以被配置为领导节点。对于动态的，一个节点会被选举成为领导节点。

另外，在动态选择领导节点的过程中，如果一个领导节点出错了，那么剩下的节点将会重新选举一个领导节点。这意味着一个组织可以有一个或多个领导节点连接到排序服务。这对于一个处理大量的交易的大型网络有助于提升弹性以及可扩展性。

锚节点

如果一个节点需要同另外一个组织的一个节点进行通信的话，那么它可以使用对方组织的通道配置中定义的锚节点。一个组织可以有0个或者多个锚节点，并且一个锚节点能够帮助很多不同的跨组织间的通信场景。

锚节点往往被用在传输私密数据上。

需要注意的是，节点可以同时是提交节点、背书节点、领导节点和锚节点！只有锚节点是可选的，但总是会有一个领导节点、至少一个背书节点和至少一个提交节点。

2.7.3 安装但没有实例化

在 2.6 节上我们说到智能合约 S5 在 P1 节点安装之后就进行了实例化，但是相反，组织 R2 上的 P2 节点不需要实例化智能合约 S5。这是因为组织 R1 已经在通道上实例化了 S5。实例化只需要发生一次；随后加入通道的任何节点都知道通道可以使用智能合约 S5。这一事实反映了账本 L1 和智能合约确实以物理方式存在于节点上，并以逻辑方式存在于通道上；R2 只是向网络添加了 L1 和 S5 的另一个物理实例。

在我们的网络中，我们可以看到通道 C1 连接两个客户端应用程序、两个 Peer 节点和一个排序服务。由于只有一个通道，所以这些组件只与一个逻辑账本交互。节点 P1 和 P2 具有与账本 L1 相同的副本。智能合约 S5 的副本通常使用相同的编程语言以相同的方式实现，但如果没有，它们必须在语义上等价

2.8 添加另外一个联盟定义

在网络开发的下一阶段，我们将介绍组织 R3。我们要给组织 R2 和 R3 一个单独的应用通道让它们可以互相进行交易。这个应用程序通道将完全独立于前面定义的通道，因此 R2 和 R3 交易可以对它们保持私有。

让我们看下网络的演化：

来自组织 R1 或 R4 的网络管理员添加了一个新的联盟定义 X2，其中包括组织 R2 和 R3。这将用于为 X2 定义一个新通道。

注意，网络现在定义了两个联盟：X1 表示组织 R1 和 R2， X2 表示组织 R2 和 R3。引入联盟 X2 是为了能够为 R2 和 R3 创建一个新的通道。

2.9 添加一个新通道

现在让我们使用这个新的联盟定义 X2 来创建一个新的通道 C2

使用联盟定义 X2 为 R2 和 R3 创建了一个新的通道 C2。通道有一个通道配置 CC2，完全独立于网络配置 NC4 和通道配置 CC1。通道 C2 由 R2 和 R3 管理，R2 和 R3 对 CC2 中的策略定义的 C2 拥有相同的权限。R1 和 R4 在 CC2 中没有定义任何权限。

要注意的是通道配置 CC1 和 CC2 是如何彼此完全分离的，以及如何完全独立于网络配置 NC4。我们再次看到了Hyperledger Fabric 网络的去中心化本质，一旦创建了通道 C2，它就由组织 R2 和 R3 独立于其他网络元素进行管理。通道策略始终保持彼此独立，并且只能由授权在通道中这样做的组织更改。

随着通道的发展，可能会要对通道更新。有一个能够以可控的形式实现这些的流程——引入能够获得对于这些配置的改动的配置交易。每个配置更改都会生成一个新的配置区块交易。

网络和通道配置在使用相同区块链技术上都保持一致，无论用于用户交易，还是用于配置交易。要更改网络或通道配置，管理员必须提交一个配置交易来更改网络或通道配置。它必须由在适当策略中标识为负责配置更改的组织签署。这个策略称为 mod_policy。

事实上，排序服务节点操作一个小型区块链，通过我们前面提到的系统通道连接。使用系统通道排序服务节点分发网络配置交易。这些交易用于在每个排序服务节点上协同维护网络配置的一致副本。以类似的方式，应用程序通道中的 Peer 节点可以分发通道配置交易。同样，这些交易用于在每个 Peer 节点上维护通道配置的一致副本。

2.10 添加另一个节点

既然组织 R3 能够完全参与通道 C2，让我们将其基础设施组件添加到通道中。我们不是一次只做一个组件，而是同时添加一个节点、它的本地账本副本、一个智能合约和一个客户端应用程序！

让我们看看添加了组织 R3 组件的网络：

图中显示了网络 N 中通道 C1 和 C2 的相关事实如下：客户端应用程序 A1 和 A2 可以使用通道 C1 与节点 P1 和 P2 通信，使用排序服务 O4；客户端应用程序 A3 可以使用通道 C2 与节点 P3 通信，并使用排序服务 O4。排序服务 O4 可以使用通道 C1 和 C2 的通信服务。通道配置 CC1 适用于通道 C1， CC2 适用于通道 C2。

首先，请注意，由于节点 P3 连接到通道 C2，它与使用通道 C1 的节点具有不同的账本 L2。账本 L2 的有效范围是通道 C2。账本 L1 是完全独立的；它的作用域是通道 C1。这是有意义的——通道 C2 的目的是在联盟 X2 的成员之间提供私有通信，而账本 L2 是他们交易的私有存储。

类似地，安装在节点 P3 上并在通道 C2 上实例化的智能合约 S6用于提供对账本 L2 的受控访问。应用程序 A3 现在可以使用通道 C2 调用智能合约 S6 提供的服务，来生成可以被网络中的每个账本 L2 副本接受的交易。

此时，我们有一个单独的网络，其中定义了两个完全独立的通道。这些通道为组织之间的交易提供了独立管理的设施。这就是工作中的去中心化；我们在控制和自主之间取得了平衡。这是通过应用于由不同组织控制和影响的通道的策略来实现的。

2.11 把一个节点添加到多个通道中

我们可以利用 R2 是联盟 X1 和 X2 的成员这一事实，将其加入多个通道：

我们可以看到 R2 是网络中的一个特殊组织，因为它是两个应用程序通道中唯一的成员组织！它可以在通道 C1 上与组织 R1 进行交易，同时也可以在不同的通道 C2 上与组织 R3 进行交易。节点 P2 同时是两个通道的成员，通过不同的智能合约为不同的账本服务。

这是一个非常强大的概念——通道既提供了组织分离的机制，也提供了组织间协作的机制。一直以来，这个基础设施都是由一组独立的组织提供并在它们之间共享的。

同样重要的是，节点 P2 的行为控制非常不同，这取决于它交易所在的通道。具体来说，通道配置 CC1 中包含的策略规定了 P2 在通道 C1 中进行交易时可用的操作，而通道配置 CC2 中的策略控制了 P2 在通道 C2 中的行为。

这是我们所希望的—— R2 和 R1 同意通道 C1 的规则，而 R2 和 R3 同意通道 C2 的规则。这些规则是在各自的通道策略中适用——它们可以而且必须被通道中的每个组件使用，以强制执行正确的行为。

类似地，我们可以看到客户端应用程序 A2 现在能够在通道 C1 和 C2 上进行交易。同样，它也会按照在相关的通道配置中的策略来进行管理。

2.11.1 排序服务

排序服务节点似乎是一个集中的组件；它最初用于创建网络，并连接到网络中的每个通道。尽管我们将 R1 和 R4 添加到控制排序节点的网络配置策略 NC4 中，该节点仍然运行在 R4 的基础设施上。在一个去中心化的世界里，这看起来是错误的！

让我们来看看一个更真实的排序服务节点配置：

一个多组织排序服务。排序服务包括排序服务节点 O1 和 O4。 O1 由组织 R1 提供，节点 O4 由组织 R4 提供。网络配置 NC4 为来自组织 R1 和 R4 的参与者定义了网络资源权限。

我们可以看到这个排序服务完全去中心化了——它在组织 R1 中运行，也在组织 R4 中运行。网络配置策略 NC4 允许 R1 和 R4 对网络资源拥有相同的权限。来自组织 R1 和 R4 的客户端应用程序和节点可以通过连接到节点 O1 或节点 O4 来管理网络资源，因为这两个节点的行为方式相同，这是由网络配置 NC4 中的策略定义的。在实践中，来自特定组织的参与者倾向于使用由其母组织提供的基础设施，但情况并非总是如此。

2.11.2 去中心化的交易分发

除了作为网络的管理点之外，排序服务还提供了另一个关键功能——交易的分发点。排序服务是一个组件，它从应用程序中收集经过背书的交易并将其排序到交易区块中，然后将这些交易区块分发到通道中的每个 Peer 节点。在每一个记账节点，交易都会被记录下来，不管交易是有效的还是无效的，它们的本地账本副本也会被适当地更新。

注意排序服务节点 O4 为通道 C1 执行的角色与为网络 N 执行的角色非常不同。当在通道级别执行操作时，O4 的角色是收集交易务并在通道 C1 中分发区块。它根据通道配置 CC1 中定义的策略执行此操作。相反，当在网络级别执行操作时，O4 的角色是根据网络配置 NC4 中定义的策略为网络资源提供管理点。再次注意，这些角色是如何分别由通道和网络配置中的不同策略定义的。这将增强基于声明策略的配置在 Hyperledger Fabric 中的重要性。策略定义并用于控制联盟中每个成员的一致行为。

我们可以看到，与 Hyperledger Fabric中的其他组件一样，排序服务也是一个完全去中心的组件。无论是作为网络管理点，还是作为通道中区块的分发器，其节点都可以根据需要分布到网络中的多个组织中。

2.11.3 修改策略

通过对示例网络的探索，我们已经看到了控制系统中参与者行为的策略的重要性。我们只讨论了一些可用的策略，但是可以声明性地定义许多策略来控制行为的各个方面。这些单独的策略将在文档的其他部分讨论。

最重要的是，Hyperledger Fabric 提供了一个独特的功能强大的策略，允许网络和通道管理员管理策略的变更！其基本理念是，无论策略变化发生在组织内部或组织之间，还是由外部监管机构强制实施，策略变化都是持续的。例如，新组织可以加入通道，或者现有组织的权限可以增加或减少。让我们进一步研究一下更改策略是如何在 Hyperledger Fabric 中实现的。

理解的关键点是策略变更是由策略本身内部的策略管理的。修改策略，简称 mod_policy，是管理更改的网络或通道配置中的首类策略。让我们举两个简单的例子，说明我们如何已经使用了 mod_policy 管理网络中的变化!

第一个例子是网络最初建立的时候。此时，只有组织 R4 被允许管理网络。实际上，这是通过使 R4 成为网络配置 NC4 中定义的唯一具有网络资源权限的组织来实现的。此外，NC4 的 mod_policy 只提到了组织 R4，说明只允许 R4 更改此配置。

然后，我们将网络 N 改进为允许组织 R1 管理网络。R4 通过在通道创建和联盟创建策略中添加 R1 实现了这一点。由于这个更改， R1 能够定义联盟 X1 和 X2，并创建通道 C1 和 C2。 R1 在网络配置中对通道和联盟策略具有同等的管理权限。

然而，R4 可以通过网络配置为 R1 授予更多的权限！R4 可以将 R1 添加到 mod_policy 中，这样 R1 也可以管理网络策略的更改。

第二种功能比第一种功能强大得多，因为现在 R1 完全控制了网络配置 NC4！这意味着 R1 原则上可以从网络中删除 R4 的管理权限。实际上，R4 将配置 mod_policy，以便 R4 也需要批准更改，或者 mod_policy 中的所有组织都必须批准更改。mod_policy 具有很大的灵活性，可以使其尽可能复杂，以支持所需的任何更改过程。

这就是 mod_policy 的作用——它允许将基本配置优雅地演化为复杂的配置。所有这一切都是在所有有关组织的同意下发生的。mod_policy 的行为与网络或通道配置中的其他策略相同；它定义了一组允许更改 mod_policy 本身的组织。

2.12 最终网络拓扑

当我们为 P2 加入了多个通道后，那么我们最终的网络拓扑图也就完成了。

在这个图中，我们看到 Fabric 区块链网络由两个应用程序通道和一个排序服务组成。组织 R1 和 R4 负责排序通道，R1 和 R2 负责蓝色的应用程序通道，R2 和 R3 负责红色的应用程序通道。客户端应用程序 A1 是组织 R1 的一个元素，而 CA1 是它的证书认证机构。注意 R2 组织中的节点 P2 可以使用蓝色和红色应用程序通道的通信设施。每个应用程序通道都有自己的通道配置，在本例中是 CC1 和 CC2。系统通道的通道配置是网络配置（NC4）的一部分

3. 区块链网络组件的总结

• 账本，每个通道一个，由区块链和世界状态组成
• 智能合约（链码）
• Peer 节点
• 排序服务
• 通道
• 证书认证结构