Hyperledger Fabric 2.5.4开发之通道篇［1］-摩杜云开发者社区

本人坚信Hyperledger Fabric 3.0正式版本的发布日益临近，很多组件中的内容都要进行相应调整，即使针对当前最新的2.5.4版本。但通道这一块，至少在3.0版本中是不会发生改变的。

一、通道简介

Hyperledger Fabric 2.5.4开发之通道篇［1］_通道

在Hyperledger Fabric联盟链中的组织之间要想进行资产交互操作，这些组织必须加入到一个通道中。

可否把通道比喻为：公共互联网名的一种经过专门加密处理的为应对特定组织进行通信的局域网？！

通道是特定组织之间通信的私有层，对网络的其他成员来说是不可见的。

每个通道都由一个单独的账本组成，此账本只能由通道成员读取和写入。通道成员可以将其同行加入该通道，并从排序服务接收新的交易块。虽然Peer节点、排序节点和证书颁发机构构成了网络的物理基础设施，但通道却承担起了组织之间相互连接和交互的过程。

来自百度“文心一言”的解说如下：

“在Hyperledger Fabric区块链网络中，通道是一个非常重要的概念。它允许联盟成员之间进行私有沟通和私有数据交互，同时保持数据的隔离性和安全性。

通道将交易和链码封装在同一个加密的容器中，只有拥有通道的成员才能访问容器中的数据。这意味着即使在同一个网络中，不同的通道也可以有不同的成员和策略，从而实现数据的隔离和安全性。

在Hyperledger Fabric中，一个通道可以有任意数量的组织连接到它。同时，一个组织也可以连接到任意数量的通道。

总之，通道是Hyperledger Fabric中实现数据隔离和安全性的关键机制。”

由于通道在Fabric网络的运营和治理中发挥着重要作用，我想专门撰写一组文章来探讨通道应用的各个方面。

自从Fabric v2.3开始，其引入了在~~不需要~~~~系统通道~~的情况下创建通道的功能，从而从对应操作中去除了额外的管理这一层。本系列文章中，我将介绍Fabric新版本（V2.3+）环境下创建通道的新的流程。

值得注意的是，Fabric新版本继续支持基于系统通道创建通道的传统方案，在使用Fabric v2.2创建通道教程部分对此进行了描述。

为了更深入地了解通道有关内容，后面我会再专门撰文介绍使用配置文件configtx.yaml构建通道配置并创建通道等内容，并单独讨论通道策略有关问题。

二、创建通道操作简介

接下来，我们来了解在Fabric V2.3＋架构下创建一个通道的过程。

为了简化通道创建过程并增强通道的隐私性和可扩展性，现在当且仅当需要创建应用程序通道（涉及资产的交易发生的地方），~~而不再需要首先创建由排序服务管理的系统通道。~~

本文中，我们将学习：

（1）如何通过使用configtxgen命令行工具创建创世区块；

（2）使用工具osnadmin CLI（针对每个排序服务节点公开的REST API运行）将排序节点连接到通道来创建新通道。注：“OSN”即排序服务节点（Ordering Service Node）。

该过程允许排序节点根据需要加入（或离开）任意数量的通道，类似于Peer节点如何参与多个通道。

Hyperledger Fabric 2.3版本起不再支持系统通道！

在Hyperledger Fabric以前版本中，系统通道是一个特殊的链，具有以下特点：

系统链上只能添加排序节点。

链的成员可以由应用程序动态指定。

不支持混合模式，即不支持已经有了系统通道，又需要通过无系统通道来建立新的应用通道。

因此，为了简化创建通道的过程并提升通道的私密性和扩展性，Hyperledger Fabric 2.3版本起不再支持系统通道

归纳来说，上述过程与传统Fabric 旧版本过程的区别在于：

~~不再支持系统通道~~：以前版本中的系统通道需要额外的步骤和管理，因此不再受支持。
~~不再支持联合体~~：您不再需要定义一组被称为“联合体（consortium）”的组织——这些组织被允许在特定的排序服务上创建通道。有了现在这种新的实现流程，所有通道都是应用通道；因此，~~可以创建通道的组织列表的概念不再适用~~。任何一组组织都可以聚集在一起，使用一组定义的排序节点（成为该通道的排序服务）创建一个通道。
简化了排序节点的创建过程：因为在创建排序节点之前，系统通道生成块不再需要存在，所以管理员现在可以在加入特定应用程序通道之前，专注于设置其基础设施并确保其节点正常工作的过程。

现在的放弃使用旧版本中系统通道的新流程的好处有：

增加了隐私：早期版本中，因为所有排序节点都曾加入系统通道，所以网络中的每个排序节点都知道该排序服务上每个通道的存在，即使节点本身不是该通道的同意者（共识者）——因此没有排序或存储其块。现在，排序节点只需知道它所加入的通道即可。
可扩展性：早期版本中，当系统通道上有大量排序节点时，启动该节点可能需要很长时间，因为它必须等待每个排序者复制显示其已加入的系统通道分类账。此外，系统通道上的大量节点会增加节点之间发送的心跳消息的数量。在具有大量节点的大型系统通道中，这可能会导致处理问题，即使应用程序通道上没有大量排序节点。
灵活性：在过去版本中，排序服务的范围是由系统通道中节点的成员资格以及从该特定系统通道创建的一些应用程序通道来定义的。现在，排序者可以根据需要加入或离开通道，类似于同行可以加入其组织所属的任何通道。
运营方面存在的优势：

易于列出排序节点同意的通道。
删除通道和与该通道关联的块成为一个简单过程。
排序节点现在可以在添加到通道的同意者集合之前作为跟随者跟踪通道，从而使他们能够更快地检测到此添加操作。以前，此过程可能需要几分钟时间，致使排序节点管理员重新启动其节点，以便节点能够更快地检测到其已加入。
如果系统通道中列出的Peer节点组织的MSP需要更改，则该Peer节点
组织不再需要与系统通道的管理员协调来更改MSP。

注意：如果您现在仍在Fabric 3.x版本之前的版本（例如v2.5.x）中使用遗留的系统通道进程，那么，你必须删除系统通道并转换到使用通道参与（participation）API，然后才能将代码库升级到v3.x。

注意：如果您更喜欢学习如何使用测试网络来创建频道，那么请查看官网中的“使用测试网络创建频道”相关教程。

三、文件夹架构

需要说明一下，本文为生成的排序组织MSP和排序节点证书使用以下文件夹结构，虽然这种结构不是强制性的，但在引用命令引用的证书时还是非常有用的。

├── organizations
│       ├── ordererOrganizations
│       │   └── ordererOrg1.example.com
│       │       ├── msp
│       │       │   ├── cacerts
│       │       │   | └── ca-cert.pem
│       │       │   ├── config.yaml
│       │       │   ├── tlscacerts
│       │       │   | └── tls-ca-cert.pem
│       │       └── ordering-service-nodes
│       │           ├── osn1.ordererOrg1.example.com
│       │           │   ├── msp
│       │           │   │   ├── IssuerPublicKey
│       │           │   │   ├── IssuerRevocationPublicKey
│       │           │   │   ├── cacerts
│       │           │   │   │   └── ca-cert.pem
│       │           │   │   ├── config.yaml
│       │           │   │   ├── keystore
│       │           │   │   │   └── key.pem
│       │           │   │   ├── signcerts
│       │           │   │   │   └── cert.pem
│       │           │   │   └── user
│       │           │   └── tls
│       │           │       ├── IssuerPublicKey
│       │           │       ├── IssuerRevocationPublicKey
│       │           │       ├── cacerts
│       │           │       │   └── tls-ca-cert.pem
│       │           │       ├── keystore
│       │           │       │   └── tls-key.pem
│       │           │       ├── signcerts
│       │           │       │   └── cert.pem
│       │           │       └── user
├── admin-client
│       ├── client-tls-cert.pem
│       ├── client-tls-key.pem
│       └── client-tls-ca-cert.pem

在上面的文件夹结构中有三个部分需要考虑：

排序组织MSP：
organizations/orderOrganizations/orderOrg1.example.com/MSP文件夹包含排序组织MSP，其中包括我们需要创建的cacerts和tlscacerts文件夹，然后分别复制到组织ca和TLS ca的根证书（ca-cert.pem）中。如果我们使用的是中间CA，则还需要包括相应的intermediatecerts和tlsintermediatecerts文件夹。
排序本地MSP：organizations/orderOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1-example.com/MSP文件夹，也称为排序本地MSP，包含排序服务osn1节点的注册证书和私钥。当向组织的Fabric CA注册排序标识时，会自动生成此文件夹。
TLS证书：organizations/orderOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.org.com.TLS文件夹包含排序服务osn1节点的TLS证书和私钥，以及TLS CA根证书TLS-CA-cert.pem。
系统管理员客户端证书-admin-client/文件夹包含将发出osadmin命令的管理客户端的TLS证书。调用osnadmin CLI的管理客户端和排序节点之间的连接需要双向TLS，尽管网络本身并不需要。这意味着，管理员客户端需要注册TLS CA，以生成提供给osnadmin CLI的TLS证书（client-TLS-cert.pem）和私钥（client TLS-key.pem）。然后，需要将这些证书和客户端TLS CA根证书（client-TLS-CA-cert.pem）复制到此文件夹中，或者指向它们在文件系统中的位置。为了简化起见，可以使用排序节点组织使用的相同TLS CA。但是在生产网络环境上，它们可能是单独的TLS CA。

本例中使用的证书名称仅供说明之用，可能无法反映CA生成的证书的实际名称。生成证书时，可以相应地对其进行重命名，以便于区分。

重要提示：我们还需要创建一个配置文件config.yaml，并将其添加到每个排序节点的组织MSP和本地MSP文件夹中。此文件支持节点OU对MSP的支持，这是一项重要功能，允许根据身份证书中的“admin”OU识别MSP的管理员。在官方Fabric CA文档相当内容中读者可以了解更多相关信息。

在Hyperledger Fabric区块链网络中，节点OU代表组织单元（Organization Unit）。

组织单元被列在$FABRIC_CFG_PATH/msp/config.yaml文件中，包含了组织单元的一个列表，其中的成员被认为是由这个MSP所代表的组织的一部分。当你想要把一个组织的成员限定为持有一个其中包含某特定组织单元的身份（由MSP指定的某个CA签发）的成员时，它是很有用的。

如果您使用容器化解决方案来运行Fabric网络，则最好将卷装载到节点本身运行的容器外部的证书目录中。这将允许证书由排序节点容器使用，无论排序节点容器是停机、损坏还是重新启动时。

四、先决条件¶

因为osnadmin命令是针对一个排序节点（它负责执行操作）执行的；所以，使用此命令前至少需要存在一个排序节点，以便可以将此排序节点加入到通道中。接下来将介绍完成部署一组新的排序节点的过程。

osn：ordering service node，即排序服务节点。

（一）部署一组新的排序节点¶

部署排序节点分两步进行：

创建排序节点组织对应的MSP并生成此排序节点的证书
为每个排序节点配置orderer.yaml文件

1.　创建排序组织MSP并生成排序节点证书¶

在部署排序节点之前，需要先定义排序组织MSP的定义，并为每个Raft（本例中，我们使用Raft算法进行节点排序）排序节点生成TLS证书和注册证书。要更详细地了解如何使用CA创建这些标识信息，读者可参考官方文档向CA注册和注册标识。完成该过程后，即拥有了针对每个节点的注册和TLS证书以及排序节点组织MSP相应的定义。为了跟踪分析生成的证书和MSP，您可以使用本文前面定义的文件夹结构，尽管这不是强制性的。

由于本文的主题是介绍创建一个通道的过程，其中要为唯一的一个组织部署三个排序节点，因此我们需要为每一个排序节点生成注册证书和TLS证书。

那么，为什么会使用三个排序节点呢？这是因为使用这样的配置正符合Raft集群上的多数法定节点个数。也就是说，当存在三个排序节点时，一次可以使用一个排序节点负责对系统进行主要的维护任务，而另外其余的大多数排序节点（这里是：三个中的其余两个）则处于简单的普通维护即可。

注意：下面来自百度“文心一言”的Raft集群配置方案中提到的5是指生产环境中的数据，在本文简单的练习环境下则不必如此。

来自百度“文心一言”的解说如下：

A：Fabric区块链中的Raft集群具有怎样特征？

Q：Fabric是一个基于超级账本（Hyperledger Fabric）的开源区块链平台，它使用一种名为Raft的共识算法来确保网络中的所有节点在处理交易和执行智能合约时保持一致。

在Fabric的Raft集群中，有以下几个重要特征：

安全性：Raft算法的一个主要特性是它保证安全性，即不会返回错误的结果。这种安全性保证在非拜占庭错误情况下都能成立，包括网络延迟、分区、丢包、冗余和乱序等错误。

可用性：Raft算法的另一个重要特性是可用性。在大多数节点正常运行并且能够相互通信的情况下，就能保证可用性。因此，一个典型的包含5个节点的集群可以容忍两个节点的失败。

状态机复制：Raft算法通过在其他服务器上复制状态机来保证一致性。一旦指令被正确复制，每个服务器的状态机将按照日志的顺序处理指令，并返回结果给客户端。因此，服务器集群看起来形成一个高可靠的状态机。

领导者选举：在Raft集群中，有一个节点会被选举为领导者（leader），负责处理所有外部请求。如果领导者宕机或停止服务，其他节点会进行选举，选出新的领导者。因此，Raft集群在领导者选举方面具有高可用性和容错性。

Q：Fabric区块链中如何使用Raft算法配置集群？

A：在Fabric区块链中，使用Raft算法配置集群的步骤如下¹：

使用configtxgen生成创世区块时，需要指定SampleMultiNodeEtcdRaft配置端。

使用Docker Compose启动其他4个orderer。

请注意，这些步骤仅适用于使用Raft算法配置Fabric区块链集群。

Q：Fabric区块链中的集群配置算法有哪几种？

A：共有两种：Raft和etcdraft。其中Raft算法是Fabric 2.x版本中默认的共识算法，而etcdraft算法则是Fabric 1.x版本中默认的共识算法。

Raft算法是一种易于理解和实现的分布式一致性算法，它通过选举产生领导者，并由领导者处理所有的读写请求，从而简化了分布式系统的实现。etcdraft算法则是基于Raft算法的一种改进，主要是针对etcdraf集群中可能出现的脑裂问题进行了优化。

有关应在生产环境中部署的排序节点数量的更多的参考信息，有兴趣的读者请查看官方文档“排序服务”。

本文中我们出于简单和学习的目的，部署单节点排序服务。显然，这种排序服务的可用性不高，因此不能被视为“生产”实战中的部署方案。

2.　为每个排序节点配置orderer.yaml文件¶

现在，我们将按照官方“排序服务部署指南”中的说明，开始构建具有三个排序节点的排序服务。请注意，为每个排序节点配置orderer.yaml文件时，需要修改ChannelParticipation和General.BoostrapMethod参数才能利用此功能。

General.BootstrapMethod：将此值设置为none。由于不再支持系统通道，所以每个排序节点上的orderer.yaml文件需要使用BootstrapMethod:none进行配置。这意味着，不再需要使用引导块来启动排序节点。
Admin.ListenAddress：排序节点管理服务器地址（主机和端口），osnadmin命令可以使用该地址在排序服务上配置通道。该值应该是唯一的主机：端口组合，以避免冲突。
Admin.TLS.Enabled：从技术上讲，这可以设置为false，但不建议这样做。通常，您应该始终将此值设置为true。
Admin.TLS.PrivateKey：TLS CA颁发的排序节点私钥的路径和文件名。
Admin.TLS.Certificate：TLS CA颁发的排序节点签名证书的路径和文件名。
Admin.TLS.ClientAuthRequired：此值必须设置为true。请注意，虽然排序节点管理端点上的所有操作都需要双向TLS证书，但整个网络不需要使用双向TLS。
Admin.TLS.ClientRootCAs：管理客户端TLS CA根证书的路径和文件名。在上面的文件夹结构中，这是admin-client/client-tls-ca-cert.pem。
ChannelParticipation.Enabled：由于不再支持系统通道，因此必须将此值设置为true。

启动每一个排序节点

1.　如果还没有在安装Fabric后设置Bin目录下的CLI命令的快速访问的话，现在可以将路径设置为Fabric二进制文件在系统上的位置（修改并启动文件~/.bash_profile即可）：

export PATH=<path to download location>/bin:$PATH

2.　然后，在终端窗口中，将FABRIC_CFG_PATH设置为指向orderer.yaml文件的位置，注意要相对于上面设置的运行FABRIC命令的bin位置。例如，如果下载二进制文件，并从/bin目录运行命令，并且orderer.yaml位于/config下的话，则配置路径应当为：

export FABRIC_CFG_PATH=../config

3.　现在，我们可以通过在每个排序节点上运行以下命令来启动排序节点：

orderer start

当排序节点成功启动时，应该看到类似于以下输出的内容：

INFO 01d Registrar initializing without a system channel, number of application channels: 0, with 0 consensus.Chain(s) and 0 follower.Chain(s)
INFO 01f Starting orderer:

此操作在没有任何通道的情况下启动排序节点。对每个排序节点重复这些步骤。目前，三个节点还不会相互通信——直到我们在随后的步骤中创建一个通道为止。

当排序节点启动时，排序服务上还没有通道，我们在随后的步骤中要创建一个通道。

（二）定义Peer节点组织¶

由于我们正在创建的通道将由两个或多个Peer节点组织使用，以便在Fabric网络上进行私人交易，因此需要至少定义一个Peer节点组织作为可以添加其他组织的通道管理员。

从技术上讲，Peer节点本身还不需要部署，但确实需要创建一个或多个Peer节点组织的MSP定义，并且在下一步中需要在配置文件configtx.yaml中提供至少一个Peer节点组织。在继续下一节之前，需要按照官方Fabric CA文档中的步骤构建Peer节点组织的MSP定义。如果已经部署了Peer节点，还应该在配置文件configtx.yaml中的AnchorPeers:节中包括这些节点的地址。

接下来，介绍创建通道的整体步骤。

五、第一步：生成通道的创世块¶

创建新通道的过程首先为通道生成创世块，稍后将在通道加入请求中提交给排序节点。

Fabric网络中创世块的作用是作为排序服务的创始区块，里面没有任何用户交易，而是包含初始网络通道状态的配置交易（channel configuration）。

注意：只需要通过一个成员来创建创世块，它可以在带外与通道上的其他成员共享，这些成员可以检查它以确保他们同意通道配置，然后由排序服务中的每个排序节点使用。

（一）设置configtxgen工具¶

虽然可以手动构建通道创建事务文件，但通过读取定义通道配置的configtx.yaml文件，可以更容易地使用configtxgen工具来构建块。

configtxgen工具位于下载的Fabric二进制文件的bin文件夹中。

在使用configtxgen之前，请确认您必须将FABRIC_CFG_PATH环境变量设置为包含configtx.yaml文件本地副本的目录的路径，例如：

export FABRIC_CFG_PATH=../config

您可以通过打印configtxgen帮助文本来检查是否能够使用该工具：

configtxgen --help

（二）关于configtx.yaml文件¶

configtx.yaml文件以可读和可编辑的格式指定新通道的通道配置，并且可由configtxgen使用。configtxgen工具使用configtx.yaml中定义的通道配置文件来创建通道配置，并将其写入Fabric可以使用的protobuf格式。

示例configtx.yaml文件位于二进制文件的config文件夹中，旁边是您下载的图像。该文件包含创建新通道所需的以下配置部分：

Organizations：可以成为指定通道成员的组织。每个组织都引用了用于构建通道MSP的加密材料。具体哪些成员是通道配置的一部分，请参见下面的Profiles部分。
Orderer：包含将形成通道的同意集的排序节点列表。
Profiles：每个通道配置文件都引用configtx.yaml文件其他部分的信息来构建通道配置。创建的每个通道都必须引用一个配置文件，其中包含Peer节点组织和通道的共识者集合等信息。配置文件部分可以列出数量不限的配置文件。但是，每个都必须有一个独特的名称（这不会成为通道本身的名称，因为这是由创建通道时给定的标志指定的）。

请参阅官方Using configtx.yaml to build a channel configuration教程，以了解有关此文件的更多信息。

注意：最初创建通道时不需要Peer节点组织，但如果您知道它们，建议现在将它们添加到配置文件Organizations：和Applications部分，以避免以后更新通道配置。

（三）组织（organizations）节¶

配置文件中的organizations节负责提供排序节点组织的MSP和任何已知的Peer节点组织的MSP。还提供每个排序节点的端点地址。

Organizations.OrdererEndpoints:

例如：

OrdererEndpoints:
            - "Host1:7080"
            - "Host2:7080"
            - "Host3:7080"

（四）排序（Orderer）节¶

Orderer.OrdererType：将此值设置为etcdraft。如前所述，~~此过程不适用于Solo排序节点。~~
Orderer.EtcdRaft.Conseters：以host:port的形式提供排序节点地址的列表，这些地址被视为conseter集合的活动成员。本节中列出的所有排序节点在加入通道时都将成为通道上的活动“consenters”。

例如：

EtcdRaft:
    Consenters:
        - Host: Host1
          Port: 7090
          ClientTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls/signcerts/cert.pem
          ServerTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls/signcerts/cert.pem
        - Host: Host2
          Port: 7091
          ClientTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn2.ordererOrg1.example.com/tls/signcerts/cert.pem
          ServerTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn2.ordererOrg1.example.com/tls/signcerts/cert.pem
        - Host: Host3
          Port: 7092
          ClientTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn3.ordererOrg1.example.com/tls/signcerts/cert.pem
          ServerTLSCert: ../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn3.ordererOrg1.example.com/tls/signcerts/cert.pem

为了简单起见，本例中的每个排序节点都为服务器和客户端使用相同的TLS证书，尽管这不是必需的。

创建通道配置块时，configtxgen读取TLS证书的路径，并用证书的相应字节替换这些路径。

（五）Profiles节¶

如果您熟悉创建通道的遗留过程，您会记得configtx.yaml文件的Profiles:section包含Orderer:group下的consortium节。~~该Fabric定义以前指定了允许在排序服务上创建通道的Peer节点组织，现在已不受支持。~~如果配置文件中存在此部分，则无法使用此功能创建通道。相反，在Orderer:部分下，您只需在多组织排序服务的情况下包括排序组织的MSP ID，并在Application:部分中列出将成为通道成员的Peer节点组织。必须至少提供一个排序节点组织和一个Peer节点组织。

以下代码段展示了一个通道配置文件的示例。其中包含基于默认通道、排序节点、组织和策略配置的排序节点配置。“Application:”部分列出了peer节点组织，其中包括默认的“Application”设置以及至少一个Peer节点组织（在本例中为SampleOrg）和通道的相应策略。

Profiles:
    SampleAppChannelEtcdRaft:
        <<: *ChannelDefaults
        Orderer:
            <<: *OrdererDefaults
            OrdererType: etcdraft
            Organizations:
                - <<: *SampleOrg
                  Policies:
                      <<: *SampleOrgPolicies
                      Admins:
                          Type: Signature
                          Rule: "OR('SampleOrg.member')"
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - <<: *SampleOrg
                  Policies:
                      <<: *SampleOrgPolicies
                      Admins:
                          Type: Signature
                          Rule: "OR('SampleOrg.member')"

注意：为了简单起见，上述这个片段假设Peer节点和排序节点属于同一个组织SampleOrg。但是，对于生产部署，建议Peer节点和排序节点属于不同的组织，这就是本文使用ordererOrg1.example.com作为排序节点组织的原因。如果您也这样做，那么在整个configtx.yaml中，您需要将排序节点组织的所有引用从SampleOrg更改为ordererOrg1.example.com。这将包括将新的排序节点组织ordererOrg1-example.com添加到文件的Organizations:部分。

根据实战场景的需要，可以在Profiles节中列出无限数量的配置信息。但是，每个配置部分都必须有唯一的一个独特的名称（这不会成为通道本身的名称，因为这是由创建通道时给定的标志指定的）。在下一步中，在生成通道创世区块时要指定使用对应的这里的哪一个配置。

（六）生成创世区块¶

完成对configtx.yaml的编辑后，可以使用它为Peer节点组织创建一个新的通道。每个通道配置都从一个创世区块开始。因为我们之前为configtxgen工具设置了环境变量，所以可以运行以下命令，使用SampleAppChannelEtcdRaft配置部分为channel1构建创世区块：

configtxgen -profile SampleAppGenesisEtcdRaft -outputBlock genesis_block.pb -channelID channel1

其中：

-profile：是configtx.yaml中用于创建通道的配置文件的名称。
-outputBlock：存储生成的配置块文件的位置。
-channelID：正在创建的通道的名称。通道名称必须全部为小写，长度小于250个字符，并且与正则表达式[a-z][a-z0-9.-]*匹配。该命令使用-profile标志引用configtx.yaml中的SampleAppGenesisEtcdRaft:profile。

命令成功后，您将看到configtxgen加载configtx.yaml文件并打印通道创建事务的日志：

INFO 001 Loading configuration
INFO 002 orderer type: etcdraft
INFO 003 Loaded configuration: /fabric/config/configtx.yaml
INFO 004 Generating genesis block
INFO 005 Writing genesis block

六、第二步：使用osnadmin CLI将第一个排序节点添加到通道¶

既然创世块已经创建，那么接收osnadmin channel join命令的第一个排序节点有效地“激活”了通道，尽管在建立了法定数量的共识者之前，通道无法完全运行（如果您的配置文件列出了三个同意者，则至少还有一个节点（总共两个）必须使用osnadmin channel join命令加入）。

每个排序节点都需要运行以下命令：

export OSN_TLS_CA_ROOT_CERT=../config/organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls/cacerts/tls-ca-cert.pem
export ADMIN_TLS_SIGN_CERT=../config/admin-client/client-tls-cert.pem
export ADMIN_TLS_PRIVATE_KEY=../config/admin-client/client-tls-key.pem

osnadmin channel join --channelID [CHANNEL_NAME]  --config-block [CHANNEL_CONFIG_BLOCK] -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY

注意，要按如下说明替换上面对应内容：

CHANNEL_NAME——与您要调用此通道的名称相一致。
CHANNEL_CONFIG_BLOCK——如果您正在创建通道，请使用您在上面第一步中创建的创世块的路径和文件名。每个后续的排序节点可以从创世
块开始加入配置，也可以通过提供最新的配置块来加入。
ORDEER_ADMIN_LISTENADDRESS——对应于在ORDERER.yaml中为排序节点定义的ORDERER.ADMIN.LISTENADDRESS。
OSN_TLS_CA_ROOT_CERT——其中包含排序节点组织TLS CA根证书和中间证书（如果使用中间TLS CA）的路径和文件名。
ADMIN_TLS_SIGN_CERT——其中包含来自TLS CA的管理员客户端签名证书的路径和文件名。
ADMIN_TLS_PRIVATE_KEY——其中包含TLS CA的管理客户端私钥的路径和文件名。

例如：

osnadmin channel join --channelID channel1 --config-block genesis_block.pb -o OSN1.example.com:7050 --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY

注意：由于osnadmin CLI和排序之间的连接需要双向TLS，因此需要在每个osadmin命令上传递--client cert和--client密钥参数。其中，--client cert参数指向管理客户端证书，--client密钥指的是管理客户端私钥，两者都由管理客户端TLS CA颁发。

此命令的输出类似于：

{
  "name": "channel1",
  "url": "participation/v1/channels/channel1",
  "consensusRelation": "consenter",
  "status": "active",
  "height": 1
}

成功后，排序节点将加入分类帐高度为1的通道。因为这个排序节点是从创世区块加入的，所以状态是“active”。因为排序节点是通道的共识者集合的一部分，所以它的同意关系是“consenter”。在后面的介绍中，我们将深入探讨consensusRelation的取值问题。

您可以对其他两个排序节点重复执行相同的命令。请记住，在相应排序节点的命令上更新排序节点端点-o[ORDER_ADMIN_LISTENADDRESS]。因为这两个排序节点从创世块加入通道，并且是共识者集合的一部分，所以他们的状态几乎立即从“onboarding”转换为“active”，且“consensusRelation”状态为“consenter”。此时，由于大多数共识者（如通道配置中所定义）处于“active”状态，通道开始运行。您应该在排序相关日志中看到类似于以下内容的内容：

INFO 087 raft.node: 1 elected leader 1 at term 2 channel=channel1 node=1
INFO 088 Raft leader changed: 0 -> 1 channel=channel1 node=1
INFO 089 Start accepting requests as Raft leader at block [0] channel=channel1 node=1

将第一个排序节点添加到通道后，后续节点可以从创世块或最新的配置块加入。当排序节点从配置块加入时，其状态始终为“onboarding”，而其分类账会赶上加入命令中指定的配置块，之后状态会自动更新为“active”。

使用带有--channelID标志的osnadmin channel list命令可以查看任何排序节点上任何通道的详细状态和consensusRelation：

osnadmin channel list --channelID [CHANNEL_NAME] -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY

例如：

osnadmin channel list --channelID channel1 -o HOST2:7081 --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY

注意，要按如下说明替换上面对应内容：

CHANNEL_NAME——其中包含生成通道时在configtxgen命令中指定的通道名称。
ORDERR_ADMIN_LISTENADDRESS——其中ORDERER.ADMIN.LISTENADDRESS在ORDERER.yaml中为排序节点定义。
OSN_TLS_CA_ROOT_CERT——其中包含排序节点组织TLS CA根证书和中间证书（如果使用中间TLS CA）的路径和文件名。
ADMIN_TLS_SIGN_CERT——其中包含来自TLS CA的管理员客户端签名证书的路径和文件名。
ADMIN_TLS_PRIVATE_KEY——其中包含TLS CA的管理客户端私钥的路径和文件名。

此命令的输出类似于：

{
  "name": "channel1",
  "url": "participation/v1/channels/channel1",
  "consensusRelation": "consenter",
  "status": "active",
  "height": 1
}

下图总结了您已完成的步骤：

Hyperledger Fabric 2.5.4开发之通道篇［1］_排序_02

您使用configtxgen命令创建通道生成块，并在针对每个节点上的管理端点为每个排序节点运行osnadmin通道连接命令时提供该文件。

假设您已经在所有三个排序节点上成功运行了osnadmin通道联接，那么现在您就有了一个活动通道，排序服务就可以将事务排序到块中。Peer节点可以加入该通道，客户可以开始交易了。

如果要将其他排序节点加入通道的共识者集合中，请按照下一节中的说明进行操作。

七、第三步：加入其他排序节点¶

随着时间的推移，可能需要将额外的排序节点添加到通道的共识者集合中。其他组织可能希望为集群贡献自己的排序节点，或者在生产条件下允许多个排序节点同时进行系统维护可能更有利。

每当新的排序节点加入集群时，您需要确保在新排序节点的分类账赶上时不会丢失定额。在现有的三节点集群中添加第四个排序节点会将大多数排序节点从两个更改为三个。因此，在追赶过程中，直到新的排序节点开始执行一致性，集群处于容错性降低的状态。为了解决这种情况并避免任何停机时间，引入了一个命令，该命令可以确定排序节点的consensusRelation状态，可以是“consenter”或“follower”。当一个节点作为追随者加入时，通道分类账会从其他排序节点进行复制，但由于它不参与共识，因此通道运营不会受到影响。由于复制长区块链可能需要很长时间，因此作为追随者加入对于区块高度高的通道最有用，因为它允许您在将区块计入定额之前确认排序节点能够复制区块。要将排序节点作为跟随者加入到通道，切记不要将该节点包括在通道配置共识者集合中！

为了简化描述，我们假设这个额外的排序节点与前三个排序节点是同一组织的一部分，并且排序节点组织已经是通道配置的一部分。如果新排序节点的组织还不是通道配置的一部分，则必须提交添加该组织的通道配置更新（并由一组满足排序节点组管理员策略的签名进行签名），然后新排序节点才能开始拉取区块。如果排序节点所在的组织在通道配置中定义，并且其排序节点签名满足/channel/Rereaders策略，则排序节点可以从其他集群成员中提取块。

在本文实例中，新的排序节点不属于共识者集合。运行以下命令将新排序节点加入到通道：

osnadmin channel join --channelID [CHANNEL_NAME]  --config-block [CHANNEL_CONFIG_BLOCK] -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY

排序节点可以通过提供创世区块或最新的配置块来加入通道。但consensusRelation的值将始终是“follower”，直到通过提交对通道配置的更新将此排序节点添加到通道的共识者集合中。

如果从创世区块加入，则此命令的输出类似于：

{
  "name": "channel1",
  "url": "participation/v1/channels/channel1",
  "status": "active",
  "consensusRelation": "follower",
  "height": 1
}

否则，如果从最新的配置块加入，则状态为onboarding，直到通道分类账赶上指定的配置块为止。您可以发出相同的osnadmin channel list命令，以确认状态更改为active，并且分类帐高度已赶上。例如，如果指定配置块的通道分类账上的块总数为1151，则在分类账赶上之后，输出将类似于：

{
  "name": "channel1",
  "url": "participation/v1/channels/channel1",
  "status": "active",
  "consensusRelation": "follower",
  "height": 1151
}

然而，需要注意的是，从onboarding到active的过渡不应是决定是否是将新排序节点添加到通道共识者集合中的唯一标准。与共识者的高度相比，更重要的是新排序节点达到的高度。例如，指定的配置块可以在高度1151处，但是后面可能有大量的正常块。在OSN4变为活动状态（达到指定配置）后，最好将OSN1的高度与OSN4的高度进行比较，如果它们彼此足够接近，则只需将OSN4添加到通道的conseters集合中。

作为提醒，要将区块拉到通道分类账中，即使是作为追随者，这个新的排序节点也必须属于当前通道配置的一部分组织。否则，它将无法将任何区块复制到其分类账中。此外，请注意，consensusRelation状态仍然是follower，因为该节点不是通道的consent集合的一部分。

下图显示了作为跟随者添加的新排序节点：

Hyperledger Fabric 2.5.4开发之通道篇［1］_排序_03

OSN4作为跟随者被添加到通道中。它的状态是“onboarding”，而它的分类账会赶上osnadmin channel join命令上提供的配置块。

尽管排序节点的状态从onboarding状态转换为active状态，但它仍然无法参与排序服务，因为它的consistensRelation状态是follower，但它将继续阻止并保持分类账的最新状态。在状态变为active状态并且您准备好让排序节点从追随者转变为同意者之后，任何排序节点组织管理员都可以通过提交通道配置更新事务或使用 fabric-config库将排序节点添加到通道上的共识者集合中。

注意：除非所有共识者都在线且健康，否则您永远不应尝试对Raft共识者进行任何配置更改，例如添加共识者，因为您可能会失去法定人数，从而失去处理交易的能力。

确保排序节点组织在通道配置中具有写入权限，以便排序节点可以成为共识者。通道更新事务完成后，您可以再次使用osnadmin channel list命令来确认排序节点的consensusRelation状态自动更改为consenter。

{
  "name": "channel1",
  "url": "participation/v1/channels/channel1",
  "status": "active",
  "consensusRelation": "consenter",
  "height": 1152
}

请注意，如果在join命令上指定的配置块的高度为1151，并且在它之后还有1000个其他块，那么添加OSN4作为共识者的配置块将位于2152。

接下来的操作简介¶

（一）将Peer节点加入通道¶

创建通道后，按照正常流程，一般接下来就是将Peer节点加入通道中并配置锚点Peer节点。如果Peer节点组织最初未包含在通道配置中，则需要提交通道配置更新事务以添加该组织。如果通道配置中确实已经包含了Peer节点组织，那么作为通道成员的所有Peer节点组织都可以使用 peer channel fetch命令从排序服务获取通道创世区块。然后，组织可以使用创世区块，使用peer channel join命令将peer节点加入到通道中。一旦Peer节点加入通道，Peer节点将通过从排序服务检索通道上的其他区块来构建区块链账本。

（二）从现有通道添加或删除排序节点¶

您可以继续使用osnadmin channel join和osnadmin channel remove命令，根据您的业务需求在每个通道上添加和删除排序节点。请注意，在从排序节点中删除通道之前，官方建议首先通过提交通道更新请求将排序节点从通道的共识者集合中进行删除。

当然，上面仅是对创建通道后接下来的典型操作的简单介绍。