Hyperledger Fabric2.3创建通道（无系统通道）文档翻译

最新推荐文章于 2023-07-20 17:24:50 发布

寒木

最新推荐文章于 2023-07-20 17:24:50 发布

阅读量2.7k

点赞数 2

分类专栏：区块链 Hyperledger Fabric

原文链接：https://hyperledger-fabric.readthedocs.io/en/latest/create_channel/create_channel_participation.html

版权

区块链同时被 2 个专栏收录

36 篇文章 26 订阅

订阅专栏

Hyperledger Fabric

16 篇文章 9 订阅

订阅专栏

翻译：https://hyperledger-fabric.readthedocs.io/en/latest/create_channel/create_channel_participation.html

为了简化通道创建流程并增强隐私性和通道的扩展性，现在可以创建应用通道而不需要先创建“system channel”（由ordering service管理）。使用本文档来学习怎样在不创建系统通道的前提下创建新的通道，使用configtxgen 工具来创建创始区块，并且osnadmin CLI（排序服务节点运行的REST API）来讲排序节点加入到通道。这个过程允许排序节点加入（或离开）任意数量的通道，类似的展示peer节点加入不同的通道。

与过去的流程有何不同：

系统通道不再必须。除了创建表示额外步骤的系统通道之外（和新流程相比），系统通道创建了一个额外的管理层，对于某些用例，它没有提供任何其他用处。
联盟不再必须：不必再定义一组组织——所谓的“联盟”，联盟可以在排序服务上创建通道。在新的流程里，所有的的通道都是应用通道，因此，可以创建通道的组织列表的概念不再适用。任何一组组织都可以聚集在一起，使用一组已定义的order节点（成为该渠道的排序服务）创建一个通道。
简化的order节点创建过程：因为在order节点创建之前系统通道的创始节点不再需要，管理员可以专注于设置其基础结果的过程，并在加入特定的应用通道之前确保其节点正常工作。

新流程的好处：

增强了隐私保护：因为所有的order节点用来加入到系统通道，每个网络中的排序节点都知道此节点上所有通道的存在，即使节点本身不是该通道上的审议者，因此没有排序或者存储其块。现在，一个排序节点只知道它加入的通道。
扩展性更好：当系统通道中有大量排序节点，启动节点需要花很长时间，因为每个排序节点需要复制系统通道账本。此外，系统通道中节点数量越多会增加节点之间心跳信息。在庞大通道中有大量节点，这可能会导致处理问题，即使没有应用通道的节点上也有大量问题。
灵活性更好：过去，order服务的范围是有系统通道定义的，并且在一些应用通道是由系统通道创建，现在排序节点可以按需求加入和离开通道，类似于peer加入到它组织所在的通道一样。
操作好处：
- 容易列出orderer节点所在的通道。
- 删除通道和通道关联的区块更容易。
- orderer节点可以在加入通道之前追踪通道，使它们更快速的检测添加。之前，这个流程需要花费几分钟，导致orderer节点管理员重启节点以便于节点加入的更加快速。
- 如果peer组织的MSP，在系统通道中列的，需要修改。peer组织不再需要系统通道管理员来协助修改MSP。

注意：创建通道的新模式不兼容使用系统通道创建通道的模式。如果系统通道存在，channel join操作不支持。类似的，channel join和channel remove不能被Solo或Kafka排序服务所使用。“混合模式”运行，一部分order节点用系统通道创建通道，另外一部分使用新流程，这样是不支持并且强烈的不推荐。你必须转化为新流程或者继续使用系统通道的流程。更多关于删除已有系统通道的作为转换为新流程的信息，查看 Remove the system channel.

创建通道，需要以下步骤和概念。

先决条件
步骤一：产生通道的创始区块。
步骤二：使用osnadmin CLI来增加第一个orderer节点到通道
步骤三：增加更多orderer节点
下一步

目录结构

本文使用如下的目录结构包含order组织的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

有三部分需要注意：

Orderer organization MSP：organizations/ordererOrganizations/ordererOrg1.example.com/msp包含orderer组织的MSP，其中cacerts和tlscacerts需要你去创建，然后复制根证书ca-cert.pem过来。如果你使用中间CA，你需要包含相符合的intermediatecerts和tlsintermediatecerts文件。
Orderer local MSP:organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/msp就是所谓的orderer本地msp，包含登陆证书和私钥（osn1节点的）。这个文件自动生成当你登陆orderer身份从Fabirc CA
TLS certificates: organizations/ordererOrganizations/ordererOrg1.example.com/ordering-service-nodes/osn1.ordererOrg1.example.com/tls目录包含了TLS证书和私钥对（osn1节点），也有TLS CA根证书tls-ca-cert.pem。
Admin client certificates admin-client/目录包含了TLS 证书admin客户端用来签发osadmin命令。客户端的链接叫做osnadmin CLI并且orderer需要多层TLS，尽管网络本身并不需要。意味着admin client需要登陆和注册TLS CA来产生TLS证书client-tls-cert.pem和私钥client-tls-key.pem这回提供给osnadmin CLI。你需要复制这些证书和客户端TLS CA根证书client-tls-ca-cert.pem到这个文件夹或者指明他们所在的路径。本文为了简便，你可以使用orderer组织相同的TLS CA。在生产环境中，你需要分开TLS CA

本例中使用的证书名称并不和CA产生的名字相同。当你获取了证书之后需要重命名来使它们更容易区分。

重要：你需要创建config.yaml文件并且添加到组织的MSP和本地MSP目录中。这个文件启用了NodeOU，这个特性可以使MSP的管理员身份基于证书中的“admin” OU。详情查看 Fabric CA

如果你选用容器来运行网络（明显是最流行的方案），最好的方式是采用挂载卷的方式来讲证书加入到容器中。这样证书可以被容器使用，而不会受容器运行错误的影响。

前提条件

因为osnadmin命令运行在orderer节点上，通道上至少要存在一个orderer节点。你可以尝试本文的存在orderer节点在order服务中，那个系统通道必须删除从orderer节点中。选择两种方式：

使用已有ordering service
部署一组新的orderer

使用已有的ordering service

在已有的ordering service上利用新特性之前，你需要在orderer节点上删除系统通道。一个通道上的“混合模式”，一部分orderer节点使用系统通道，另一部分order采用新特性，是不支持的。osadmin CLI包含了包括channel list和channel remove命令方便的删除系统通道。

删除系统通道

在下面的步骤之前需要保证ordering节点已经升级到Fabric 2.3以上版本。
修改orderer.yaml来支持新特性并重启节点。查看sampleconfig
- General.BootstrapMethod 设置此为none，因为系统通道不再需要了，每一个orderer节点的配置文件都要设置none，意味着不需要启动区块来启动orderer
- Admin.ListenAddress： orderer server的管理地址（主机和端口）这个可以用来使用osnadmin命令来配置通道。这个值需要是唯一的不能冲突。
- Admin.TLS.Enabled: 理论上这个可以设置为false，但是这不推荐。一般情况下，需要设置为true。
- Admin.TLS.PrivateKey:TLS CA签发的私钥路径
- Admin.TLS.Certificate: TLS CA签发的orderer证书
- Admin.TLS.ClientAuthRequired:这个值必须设置为true。注意虽然在orderer Admin端口上各操作需要使用TLS，但整个网络并不需要。
- Admin.TLS.ClientRootCAs: 管理员客户端的TLS CA根证书。在上面的结构中，是admin-client/client-tls-ca-cert.pem
- ChannelParticipation.Enabled:设置此值为true来启动orderer的这个特性。
重启每一个orderer节点。
放system channel into maintenance mode，Kafka和Raft同步相同。这个动作会停止通道创建新的交易。
从orderer节点上删除系统通道，一个接一个。在orderer节点删除系统通道的过程中，orderer会停止服务。因此，小心并确定剩余的orderer仍然可以工作并且彼此可以达成一致。这个操作可以是交错的，根据各通道的容错设置，没有让通道关闭。如果一个应用通道能容错一个server下线，你仍然可以提交交易到通道中，凭借其它orderer并没有同时处于删除流程中。使用osnadmin channel list命令展示orderer所参与的通道
```
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 list -o [ORDERER_ADMIN_LISTENADDRESS] --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY
```
- ORDERER_ADMIN_LISTENADDRESS 与orderer.yaml中Orderer.Admin.ListenAddress一致
- OSN_TLS_CA_ROOT_CERT orderer组织的TLS根证书或中间证书。
- ADMIN_TLS_SIGN_CERT admin client的TLS CA证书
- ADMIN_TLS_PRIVATE_KEY TLS CA的私钥路径

注意：因为osnadmin CLI和orderer链接相互需要TLS，你需要传递--client-cert和--client-key参数在每一个osadmin命令。分别指向admin客户端证书和admin私钥，都是有admin客户端TLS CA签发。

例如：

osnadmin channel list -o HOST1:7081 --ca-file $TLS_CA_ROOT_CERT --client-cert $OSN_TLS_SIGN_CERT --client-key $OSN_TLS_PRIVATE_KEY

输出如下：

{
  "systemChannel": {
      "name": "syschannel",
      "url": "/participation/v1/channels/systemchannel"
  },
  "channels":[
      {
        "name": "channel1",
        "url": "/participation/v1/channels/channel1"
      }
  ]
}

现在你可以运行osnadmin channel remove 来删除通道：

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

例如：

osnadmin channel remove -o HOST1:7081 --channelID syschannel --ca-file $OSN_TLS_CA_ROOT_CERT --client-cert $ADMIN_TLS_SIGN_CERT --client-key $ADMIN_TLS_PRIVATE_KEY

成功的结果是：

Status: 204

并且运行了osnadmin channel list命令，你可以验证系统通道是否已经被删除

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

检验已经被删除：

{
  "systemChannel": null,
  "channels":[
      {
        "name": "channel1",
        "url": "/participation/v1/channels/channel1"
      }
  ]
}

重复以上命令为每一个ordering节点。

部署一组新的orderers

使用如下步骤来部署新的orderers来使用此特征。分为两步

创建orderer组织的MSP并生成orderer节点的证书
为每一个orderer节点配置orderer.yaml

创建orderer组织的MSP并生成orderer节点的证书

在部署orderer之前，你需要定义orderer的组织MSP和TLS为每一个Raft orderer节点。学习怎样创建身份，查看Registering and enrolling identities with a CA。在完成进程之后，你需要登陆获取TLS证书和orderer MSP.为了跟随本文档你可以使用上面的目录结构。

因为本文展示了使用一个组织的三个orderer来创建通道，你需要为每一个节点生成TLS证书。为什么三个orderers，这样就满足Raft的大多数策略。也就是说，当三个orderer节点，有一个停止运行，还有大多数在运行。更多关于节点数量的信息，查看The Ordering Service。为了简便和学习的目的，你也可以部署一个orderer节点，即使这个orderer服务不会高可用并且不能用于生产环境。

配置orderer.yaml为每个orderer

遵循ordering service deployment guide部署三个orderer节点。注意当你配置orderer.yaml时，你需要修改ChannelParticipation和General.BoostrapMethod。

General.BootstrapMethod 设置为none，因为系统通道不再需要。
Admin.ListenAddress orderer admin server的地址，osnadmin命令配置通道。这个值必须是唯一的不能冲突。
Admin.TLS.Enabled: 理论上这个可以设置为false，但这个并不推荐，普遍来说，你需要设置为true。
Admin.TLS.PrivateKey: TLS CA签发的私钥路径
Admin.TLS.Certificate: TLS CA签发的证书。
Admin.TLS.ClientAuthRequired: 这个值必须设置为true。注意在orderer 管理地址上需要TLS，但整个网络并不需要。
Admin.TLS.ClientRootCAs:admin客户端TLS CA的根证书。在上面的文件夹中，这是admin-client/client-tls-ca-cert.pem
ChannelParticipation.Enabled: 设置为true来启用新特性。

启动每个orderer

1.如果还没有设置Fabric的二进制执行文件

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

2.如果终端设置了变量FABRIC_CFG_PATH 到orderer.yaml,是Fabric可执行文件的相对路径。如果你的执行文件在/bin中，且orderer.yaml在/config，那么路径是

export FABRIC_CFG_PATH=../config

3.你可以开启orderer通过如下命令：

orderer start

当orderer启动成功后，你会看到类似于下面的输出：

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:

这个动作启动了orderer节点且没有加入任何通道，为每个orderer节点重复这个过程。此时此刻，三个节点并没有彼此通信，直到随后我们创建一个通道。

定义peer组织

因为我们创建的的通道在网络中有两个以上peer组织在通信，你至少需要一个peer组织作为通道的管理员，这样可以添加其它组织。理论上，peer节点本身还没有部署，你需要创建一个或多个peer组织MSP且至少一个组织需要在configtx.yaml中。在进入下一步之前，查看Fabric CA建立peer组织的MSP。如果peer已经部署了，你需要包含它们的地址到锚节点。

第一步，生成通道的创始区块

创建新通道的起始是生成创始区块，在随后的channel join中要提交到orderer。只需要一个成员来创建创始区块，可以将它分享到其它通道成员中，确保有相同的通道配置，接着排序服务中的orderer都会用。

安装configtxgen工具

可以手动创建通道交易文件，这也可以使用configtxgen工具来创建通道，这很容易使用configtxgen工具读取configtx.yaml文件（包含通道配置）创建区块。

configtxgen工具是Fabric可执行文件，放在bin文件夹中。

在使用configtxgen之前，确认你已经设置了FABRIC_CFG_PATH环境变量指向到包含configtx.yaml的目录，例如

export FABRIC_CFG_PATH=../config

可以使用帮助来查看用法

configtxgen --help

configtx.yaml文件

configtx.yaml文件是configtxgen工具可读可编辑的文件，包含了新通道的配置。configtxgen工具使用此文件中的配置来设置通道并转化为Fabric识别的protobuf format 。示例configtx.yaml文件在config文件夹中与可执行文件所在的目录相邻。文件中以下配置项需要在新通道中设置：

Organizations：通道成员的组织。每个组织有加密素材组建通道的msp.准确的说每个通道配置定义在下面的Profiles部分。
Orderer：一个orderer节点的列表，组织了通道的参与者
Profiles：每个通道配置信息来创建通道配置。每个通道创建必须参照profiel，包含了peer组织和通道成员。Profiles区域可以设置多个profile设置。然而，每一个必须有独有的名字（这会成为通道的名称，会在创建通道时以flag的形式来指定）

到Using configtx.yaml to build a channel configuration文档中查看更多信息，然而，下面的三个部分需要在没有系统通道的情况下指定配置来创建通道。

注意：在通道初始化时并不需要Peer组织，但你知道推荐将它们加入到Profiles的Organizations和Applications区域，避免后面升级通道。

Organizations：

提供orderer组织MSP和任何peer组织MSP。也提供orderer节点的endpoint

Organizations.OrdererEndpoints:

例如

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

Orderer：

Orderer.OrdererType 设置为etcdraft。之前提过，此流程不支持Solo和Kafka的orderer节点。
Orderer.EtcdRaft.Consenters 设置orderer节点地址的列表，在host:port组成中，这被认为是激活了共识者集合。所有加入此区域的orderer节点在通道加入后都会成为共识者。

例如：

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

为了简明，每个orderer节点使用了相同的TLS证书，包括server和client，尽管这个没有必要。

当通道配置区块被创建了，configtxgen读取TLS的证书路径并替换并替换为证书中的数据。

Profiles

如果你对过去的创建通道流程熟悉，你可以回顾一下Profiles区域：此区域包含了联盟部分在“Orderer：”下。这个联盟定义了，之前的版本包含指定哪些peer组织可以创建通道，现在不需要了。如果此区域存在于profile部分，那就不能使用这个新特征来创建通道。更准确的说在“Orderer："区域只是包含orderer组织的MSP ID或者多排序服务的组织和peer组织在Application区域（通道成员）。至少要有一个orderer组织和peer组织。

下面的一段是通道profile的实例，包含了orderer配置，orderer，组织和策略配置。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')"

注意：为了简单，这段假设peers和orderers属于相同的SampleOrg组织。这里查看 sample config。对于生产环境的部署，推荐peer和orderer节点属于不同的组织，所以本例中使用ordererOrg1.example.com为orderer组织。如果你使用相同的组织，通过configtx.yaml你需要修改指向SampleOrg 到ordererOrg1.example.com。这需要包含新的order组织ordererOrg1.example.com到”Organizations:“

Profiles 区域可以按需设置不限个数。但是必须有不同的名字（这会成为通道的名字，当通道创建时使用flag传入）。下一步，需要生成通道的创始区块。

生成创始区块

在你编辑完成configtx.yaml之后，你可以使用它来创建新的通道。每个通道配置以创始区块启动。因为我们之前为configtxgen 设置了环境变量，你可以运行下面的命令来为通道channel1创建创始区块，使用SampleAppChannelEtcdRaft 部分的profile：

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

-profile是configtx.yaml 的profile的名字用来创建通道。
-outputBlock生成创始区块的保存路径
-channelID通道的名称，名字必须全小写，少于250个字符并且匹配表达式[a-z][a-z0-9.-]*。这个命令使用-profile标识来指定“SampleAppGenesisEtcdRaft:”

当命令执行成功，你会看到configtxgen创建通道的事务：

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增加第一个orderer到通道`

现在创始区块已经创建了，第一个orderer节点接收”osnadmin channel join“命令激活 “activates” 通道。尽管通道并不是完全可操作的，直到法定达到法定人数（如果你的profile列出了三个共识者，则需要两个以上，使用osnadmin channel join命令加入到通道中）。

注意：如果你试着运行osnadmin命令（除了channel list命令）在系统通道的orderer节点上，你会收到错误提示系统通道已经存在。系统通道需要在使用osnadmin之前被删除。

每个orderer节点需要运行如下命令

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 --channel-id [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 第一步中创建的创始区块的目录和名称，随后的orderer节点会加入配置使用此创始区块，或者使用最新的配置区块替代。
ORDERER_ADMIN_LISTENADDRESS 与Orderer.Admin.ListenAddress （定义在orderer.yaml）相符的地址
OSN_TLS_CA_ROOT_CERT orderer组织的TLS CA证书或中间证书。
ADMIN_TLS_SIGN_CERT admin client的TLS证书
ADMIN_TLS_PRIVATE_KEY admin client的私钥

例如：

osnadmin channel join --channel-id 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和orderer通信需要TLS，需要传递--client-cert和--client-key参数在每一个osadmin命令。--client-cert参数指向admin client证书，--client-key指向admin client私钥，都是有admin client TLS CA签发。

输出如下：

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

当成功了，orderer加入通道账本高1.因为此orderer是使用创始区块加入的，status是”active“。因为orderer是通道共识集体的一员，它的consensusRelation 是“consenter”。下一部分中会详细介绍consensusRelation 。

在另外的两个orderer中重复以上命令。记得修改orderer地址， -o [ORDERER_ADMIN_LISTENADDRESS]，在命令中改为相符的orderer。

因为两个orderer使用创始区块加入通道斌并且都是共识集体的一员，他们的交易状态会从“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

在第一个orderer加入到通道后，其它节点可以从创始区块加入也可以从最新的区块加入。当orderer从配置区块加入时，它的状态在账本更新配置区块（命令中指定）时是onboarding，之后它的状态更改为active。

使用osadmin channel list命令时加上--channel-id标签用来查看节点的status和consensusRelation（共识关系）

osnadmin channel list --channel-id [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 --channel-id 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 通道名称
ORDERER_ADMIN_LISTENADDRESS 在orderer.yaml中的Orderer.Admin.ListenAddress
OSN_TLS_CA_ROOT_CERT orderer组织的的TLS CA根证书或者中间证书。
ADMIN_TLS_SIGN_CERT admin client的TLS CA证书
ADMIN_TLS_PRIVATE_KEY TLS CA的私钥

输出如下：

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

下面的图表展示了你刚完成的步骤

create-channel.osnadmin1-3

首先使用configtxgen命令创建通道创始区块，然后将此文件提供给各个orderer节点。

假设你已经在三个节上成功的运行了osnadmin channel join命令，现在你已经有一个激活的channel且ordering service已经准备好Wie交易排序。Peer已经可以加入通道且client可以开始交易。

如果你想增加orderer节点到通道，可以追踪以下文档。

第三步，新增orderer到通道

为通道的共识集体新增orderer节点可能随时发生。其它组织可能想贡献它们的orderer到集群中，或者它会在生产环境下允许多个orderer停机维护的情况下展示优越性。

任何时候新的orderer加入集群，都要保证没有在共识机制中失去法定的多数席位。增加一个节点到已有的三个orderer节点中，会改变共识的大多数数量。因此在执行进程直到新orderer开始执行共识，集群处于容错能力减低的状态。对于这种状况或者避免停机，需要使用命令查清orderer节点的consensusRelation ，状态可能是consenter或follower。当orderer加入后身份是follower，账本会从其它orderer上复制过来，但它没有参与共识，通道操作并没有中断。

因为复制长区块链可能会花很长时间，作为follower加入区块很高的通道时是非常有用的，因为这允许你确认orderer可以复制区块在拥有法定人数之前。以follower身份加入通道，请勿将节点包括在通道配置许可程序中。

文档为了清晰，我们假设新增orderer是和之前的orderer是一个组织。如果新增orderer的组织并没有在通道配置中，则orderer的组织必须先添加到通道中，在新orderer可以获取区块之前。orderer可以从其它集群成员拉取区块，如果orderer的组织在通道配置中，并且满足/Channel/Readers策略。

从这个文档中，新的orderer不是集群的一部分。运行如下命令将新的orderer加入到通道:

osnadmin channel join --channel-id [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

orderer可以通过创始区块加入通道，或者最后的配置区块。但是consensusRelation 会一直是“follower”，直到orderer被加入到共识集体中，通道提交通道配置。

如果是加入创始区块，输出类似于：

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

或者，加入的是最新的配置区块，status是onboarding ，直到通道账本更新到了指定的配置区块。你可以使用osnadmin channel list命令来确认status为active和账本高度更新完成。例如，如账本的总高度在指定的区块上是1151，在账本更新完毕后，输出会类似于：

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

然而，有一点很重要，交易的状态从onboarding 到active 不是唯一的标准来决定是否是时候将新的orderer加入到共识集中。更重要的是比对新orderer达到的高度并比较共识的高度。例如，指定的配置区块在高度1151，但下面会有大量的正常区块。在OSN4 成为active（赶上指定配置），最好比较OSN1和OSN4，当它们互相接近的时候，可以添加OSN4到通道结合中。

下图展示了ordering 节点已经作为follower加入：

OSN4作为follower加入了。状态是onboarding，直到账本追平配置区块在加入通道的osnadmin命令。

尽管orderer状态从onboarding 转化为active，但仍然不能参与到排序服务，因为consensusRelation 状态是follower，但仍然会继续拉取区块并且会随时更新。在状态变成active，就可以将orderer从follower转换成共识成员，并且任何orderer组织的admin都可以将orderer添加到共识集合中，通过channel configuration update transaction，或者使用 fabric-config可执行文件。

注意：你不能尝试对Raft共识进行更改，例如提那家一个共识者，除非所有的共识者都在线并且正常运行，因为你可能失去法定人数，从而不能处理交易事务。

确保orderer组织具有写权限在通道配置中，这样orderer可以成为一个共识者。当通道升级完成，你可以使用osnadmin channel list命令来确认，consensusRelation 状态自动更改为共识者。

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

注意如果配置区块高度是1151，并且后面有1000个区块，那么OSN4加入共识的区块会是2152.

下一步

将peers加入通道

在通道创建之后，你可以按正常流程来讲peer加入到通道中，并配置锚节点。如果peer组织并没有包含在通道配置中，你需要提交channel configuration update transaction来增加组织。如果这个没有包含peer组织，所有通道中的peer组织可以从orderer服务中获取通道创始区块，使用peer channel fetch命令。组织可以使用创始区块来加入通道使用 peer channel join命令。一旦peer加入到通道中，peer就开始从排序服务中接受区块账本。

从通道中增加或删除orderer

你可以继续使用osnadmin channel join和osnadmin channel remove名来来增加或删除orderer。在从通道中删除orderer之前需要注意，建议首先通过通道升级请求，在共识集合中删除orderer。

寒木

关注

2
点赞
踩
15

收藏

觉得还不错? 一键收藏
10
评论
Hyperledger Fabric2.3创建通道（无系统通道）文档翻译

为了简化通道创建流程并增强隐私性和通道的扩展性，现在可以创建应用通道而不需要先创建“systemchannel”（由orderingservice管理）
复制链接

扫一扫