搭建 Fabric 网络分步走

区块链技术 927 4 月 22, 2024 0 区块链315

搭建 Fabric 网络分步走

> 本文作为 Fabric 官方文档的补充，带你一步步搭建 Fabric 网络，中间会有一些解释说明。搭建 Fabric 网络是个繁琐易出错的过程，如果碰到啥问题，要恭喜你，离成为大牛又近了一步。 > 世上本没有大牛，填的坑多了，也就成了大牛。 ## 第一步确定联盟成员本文接下来会假定 SAP 与 IBM 要组成一个培训联盟，共享培训资源。那么我们可以基本确定这个培训联盟的创世成员为 SAP 与 IBM。联盟有个新域名 training.com. SAP 和 IBM 分别有一个组织域名 sap.training.com, ibm.training.com ## 第二步确定网络节点在 Fabric 网络里最重要的两类节点，一个是 Orderer 节点，一个是 Peer 节点。 Orderer 节点为联盟成员共享的中心化节点。用来对交易进行排序，是 Fabric 共识机制的重要组成部分。 Peer 节点为各联盟成员分别维护的对等节点，为 Fabric 网络的记账节点。通过一番讨论，我们假定 SAP 与 IBM 决定先从最小化网络开始，分别维护两个对等节点。 ## 第三步生成 MSP Fabric 是个有权限的网络，各个网络节点之间通讯都需要进行身份认证。MSP 保存了各个网络节点的证书和私钥，当某个节点要和其它节点通讯时用私钥对数据进行签名，同时附带自己的证书，对方节点就可以通过证书验证消息发送方的身份，继而通过证书里的公钥来验证消息确实是由拥有该身份的节点发送过来的。 MSP 的配置信息如下： ``` OrdererOrgs: - Name: Orderer Domain: training.com Specs: - Hostname: orderer PeerOrgs: - Name: sap Domain: sap.training.com Template: Count: 2 Users: Count: 1 - Name: ibm Domain: ibm.training.com Template: Count: 2 Users: Count: 1 ``` 从上面配置我们可以看到前面提到的 Orderer 节点组织和 Peer 节点组织。Template.Count 指定了所要生成的节点数量。Users.Count 指定了需要生成的初始化用户数量。这里为了方便，把配置写在了一个配置文件中。在项目实际操作过程中，为了私钥安全，可以每个组织分别生成自己的 MSP 信息。把上面的配置在当前文件夹下保存为crypto-config.xml, 可以调用下面的命令来生成 MSP 配置信息： ``` cryptogen generate --config crypto-config.yaml ``` 该命令会在当前目录生成一个 crypto-config 的目录结构，如下面截图所示： ![](https://img.learnblockchain.cn/2020/02/05_/301558260.png) msp 目录结构 ## 第四步生成 Orderer 创世区块在 Orderer 节点上维护的有个 system chain, 这个创世区块实际上是这个 system chain 的创世区块。在 Fabric 的上下文中，chain，channel 基本上可以通用，下面有时会称 system chain 为 system channel。这个创世区块都包含什么东西呢？可以看看用来生成这个区块的配置文件。 ``` # Copyright IBM Corp. All Rights Reserved. # # SPDX-License-Identifier: Apache-2.0 # --- Organizations: - &OrdererOrg Name: OrdererOrg ID: OrdererMSP MSPDir: crypto-config/ordererOrganizations/training.com/msp Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" - &Sap Name: SapMSP ID: SapMSP MSPDir: crypto-config/peerOrganizations/sap.training.com/msp AnchorPeers: - Host: peer0.sap.training.com Port: 7051 Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" - &Ibm Name: IbmMSP ID: IbmMSP MSPDir: crypto-config/peerOrganizations/ibm.training.com/msp AnchorPeers: - Host: peer0.ibm.training.com Port: 7051 Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" Orderer: &OrdererDefaults OrdererType: solo Addresses: - orderer.training.com:7050 BatchTimeout: 2s BatchSize: MaxMessageCount: 10 AbsoluteMaxBytes: 99 MB PreferredMaxBytes: 512 KB Kafka: Brokers: - 127.0.0.1:9092 Organizations: Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" Channel: &ChannelDefaults # Policies defines the set of policies at this level of the config tree # For Channel policies, their canonical path is # /Channel/<PolicyName> Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" Application: &ApplicationDefaults # Organizations is the list of orgs which are defined as participants on # the application side of the network Organizations: # Policies defines the set of policies at this level of the config tree # For Application policies, their canonical path is # /Channel/Application/<PolicyName> Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" ################################################################################ # # Profile # # - Different configuration profiles may be encoded here to be specified # as parameters to the configtxgen tool # ################################################################################ Profiles: TrainingOrdererGenesis: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults Organizations: - *OrdererOrg Consortiums: TrainingConsortium: Organizations: - *Sap - *Ibm TrainingChannel: Consortium: TrainingConsortium Application: <<: *ApplicationDefaults Organizations: - *Sap - *Ibm ``` 猛一看会感觉这个配置文件的内容有点儿多，我们可以从一个入口进去，拆开来慢慢看。在这个文件里有两个 Profile，一个是 **TrainingOrdererGenesis** , 一个是 **TrainingChannel** 。一个 Profile 代表了一组配置，我们生成创世区块用的就是 **TrainingOrdererGenesis** 这个 Profile。里面包含了通道相关配置，Orderer 节点相关配置，联盟成员相关配置。通道相关配置确定了系统通道的一些权限策略，Orderer 节点配置确定了 Orderer 节点的类型（是 solo 还是 kafaka），Orderer 节点的访问地址，还有出块时间，区块大小，区块内允许包含的交易数量等。联盟配置确定了联盟的名称和联盟所包含的组织，对组织来说这里最为关键的是组织的 MSP ID 和路径，这些信息都会被包含到 system chain 中。我们可以在当前目录创建一个 artifacts 文件夹来存放要接下来要生成的各种区块链工件。 ``` mkdir artifacts ``` 然后用下面的命令来生成创世区块： ``` configtxgen -profile TrainingOrdererGenesis -channelID orderer-channel -outputBlock artifacts/orderer.genesis.block ``` 如果我们不指定配置文件的路径，该命令会从当前目录下读取名为 configtx.yaml 的配置文件。这个命令需要指定一个 channelID，注意这里的 channelID 为系统链(system chain)的 channelID。到这一步，其实就可以通过 **orderer** 命令或 docker 容器来启动网络了，orderer 启动的时候会查找一个名为 orderer.yaml 的配置文件，文件内容比较多，具体可以查看 [orderer 默认配置](https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/orderer.yaml) 。这个配置文件不是必须的，在找不到这个配置文件时，orderer 命令会使用默认配置。我们也可以通过环境变量或命令行参数的方式去对每个配置项进行覆盖。下面截图里"environment"配置项，实际上就是在 docker 启动的时候，通过环境变量覆盖 orderer 默认配置对 orderer 节点进行自定义配置。 ![](https://img.learnblockchain.cn/2020/02/05_/556368994.png) 为了方便我们做实验，可以把 fabric-samples/first-network/base 文件夹拷贝到当前目录，将配置文件里的域名和环境变量进行替换来作为自己 fabric 配置的基础，节省一些工作量。实际工作中，我们也倾向与尽量站在前人的肩上，能复用的复用，将自己更多的时间花费在更有创造性的贡献中去。尽管这时我们已经可以启动 fabric 网络了，但这个网络没有任何应用级别的通道（channel），相当于也没啥用。所以一般来说，我们也会把创建应用通道所需要的工件准备好，再进行网络的启动。 ## 第五步生成通道交易注意：这里我们生成的是个用来生成通道创世区块的交易，而不是创世区块。通过下面的命令，可以生成这样的一个交易。 ``` configtxgen -profile TrainingChannel -outputCreateChannelTx artifacts/training-channel.tx -channelID training-channel ``` 该命令会读取和生成 Orderer 相同的配置文件，只是使用了 "TrainingChannel" 这个 Profile，确定了通道的权限策略，创建通道的联盟和组织信息。只是创建了通道，而不创建锚节点的化，通道区块数据就无法跨组织传播，所以一般还要通过下面的命令创建用来更新锚节点的交易。 ``` configtxgen -profile TrainingChannel -outputAnchorPeersUpdate artifacts/SapMSPAnchor.tx -asOrg SapMSP -channelID training-channel configtxgen -profile TrainingChannel -outputAnchorPeersUpdate artifacts/IbmMSPAnchor.tx -asOrg IbmMSP -channelID training-channel ``` 上面的命令生成了为每个组织生成锚节点的交易。到这里，我们就可以通过 “peer 命令” 或 docker 容器启动包含 Orderer 节点，Peer 节点的 Fabric 网络了。peer 命令在启动 peer 节点时默认会读取 core.yaml, 该文件的默认配置见 [peer节点配置](https://github.com/hyperledger/fabric/blob/1c94e9e9108409ba3278d2bc40a184b1ef7127e9/sampleconfig/core.yaml) 。在读到这个配置文件之前，我一致对 fabric 网络中 leader 节点如何产生，orderer 节点如何感知 leader 节点的变化一致不是太清楚，但这个配置文件把这点儿描述的算是比较清楚了。 ``` # Defines whenever peer will initialize dynamic algorithm for # "leader" selection, where leader is the peer to establish # connection with ordering service and use delivery protocol # to pull ledger blocks from ordering service. It is recommended to # use leader election for large networks of peers. useLeaderElection: true # Statically defines peer to be an organization "leader", # where this means that current peer will maintain connection # with ordering service and disseminate block across peers in # its own organization orgLeader: false ``` 从配置描述基本可以推断出，peer 节点会主动联系 orderer 节点来明确当前的 leader 节点。这个阶段把网络启动后，还是啥事都做不了，节点之间也没有通信。因为我们还没真正去生成应用通道的创世区块。这时我们通过下面的命令来生成应用通道的创世区块： ``` peer channel create -t 50s -o orderer.training.com:7050 -c training-channel -f ./channel-artifacts/training-channel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/training.com/orderers/orderer.training.com/msp/tlscacerts/tlsca.training.com-cert.pem ``` 然后通过下面的命令加入区块： ``` peer channel join -b training-channel.block ``` 在通过下面的命令来更新组织的锚节点： ``` peer channel update -o orderer.training.com:7050 -c training-channel -f ./channel-artifacts/SapMSPAnchor.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/training.com/orderers/orderer.training.com/msp/tlscacerts/tlsca.training.com-cert.pem ``` 为什么创建应用通道搞的这么繁琐呢？我想这主要由联盟链的性质决定的： 1. 对联盟链上与联盟成员有关的任何网络变动，都要网络成员的确定。否则，如果任何一个成员都可以对网络进行修改，整个网络的信任基础也就荡然无存了。 2. 加入通道，修改通道配置这些操作都需要各个网络成员的确认。将操作步骤分开，由每个节点的管理员自主加入通道，由每个组织的管理员来更新锚点等配置。实际上是让每个组织对相关操作进行了确认。锚节点更新成功之后，一个可用的，带有应用通道的 Fabric 网络就启动起来了。我们接下来就可以向网络中部署链码来实现业务逻辑了。 ## 总结部署 Fabric 网络是个繁琐的过程，需要反复的练习、试错、琢磨，才能理解透彻，举一反三。

本文作为 Fabric 官方文档的补充，带你一步步搭建 Fabric 网络，中间会有一些解释说明。搭建 Fabric 网络是个繁琐易出错的过程，如果碰到啥问题，要恭喜你，离成为大牛又近了一步。世上本没有大牛，填的坑多了，也就成了大牛。

第一步确定联盟成员

本文接下来会假定 SAP 与 IBM 要组成一个培训联盟，共享培训资源。那么我们可以基本确定这个培训联盟的创世成员为 SAP 与 IBM。联盟有个新域名 training.com. SAP 和 IBM 分别有一个组织域名 sap.training.com, ibm.training.com

第二步确定网络节点

在 Fabric 网络里最重要的两类节点，一个是 Orderer 节点，一个是 Peer 节点。 Orderer 节点为联盟成员共享的中心化节点。用来对交易进行排序，是 Fabric 共识机制的重要组成部分。 Peer 节点为各联盟成员分别维护的对等节点，为 Fabric 网络的记账节点。通过一番讨论，我们假定 SAP 与 IBM 决定先从最小化网络开始，分别维护两个对等节点。

第三步生成 MSP

Fabric 是个有权限的网络，各个网络节点之间通讯都需要进行身份认证。MSP 保存了各个网络节点的证书和私钥，当某个节点要和其它节点通讯时用私钥对数据进行签名，同时附带自己的证书，对方节点就可以通过证书验证消息发送方的身份，继而通过证书里的公钥来验证消息确实是由拥有该身份的节点发送过来的。

MSP 的配置信息如下：

OrdererOrgs:
  - Name: Orderer
    Domain: training.com
    Specs:
      - Hostname: orderer
PeerOrgs:
  - Name: sap
    Domain: sap.training.com
    Template:
      Count: 2  
    Users:
      Count: 1
  - Name: ibm
    Domain: ibm.training.com
    Template:
      Count: 2
    Users:
      Count: 1

从上面配置我们可以看到前面提到的 Orderer 节点组织和 Peer 节点组织。Template.Count 指定了所要生成的节点数量。Users.Count 指定了需要生成的初始化用户数量。这里为了方便，把配置写在了一个配置文件中。在项目实际操作过程中，为了私钥安全，可以每个组织分别生成自己的 MSP 信息。

把上面的配置在当前文件夹下保存为crypto-config.xml, 可以调用下面的命令来生成 MSP 配置信息：

cryptogen generate --config crypto-config.yaml

该命令会在当前目录生成一个 crypto-config 的目录结构，如下面截图所示：

msp 目录结构

第四步生成 Orderer 创世区块

在 Orderer 节点上维护的有个 system chain, 这个创世区块实际上是这个 system chain 的创世区块。在 Fabric 的上下文中，chain，channel 基本上可以通用，下面有时会称 system chain 为 system channel。

这个创世区块都包含什么东西呢？可以看看用来生成这个区块的配置文件。

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

---
Organizations:

    - &OrdererOrg
        Name: OrdererOrg
        ID: OrdererMSP
        MSPDir: crypto-config/ordererOrganizations/training.com/msp

        Policies:
            Readers:
                Type: ImplicitMeta
                Rule: "ANY Readers"
            Writers:
                Type: ImplicitMeta
                Rule: "ANY Writers"
            Admins:
                Type: ImplicitMeta
                Rule: "MAJORITY Admins"

    - &Sap
        Name: SapMSP
        ID: SapMSP
        MSPDir: crypto-config/peerOrganizations/sap.training.com/msp

        AnchorPeers:
            - Host: peer0.sap.training.com
              Port: 7051

        Policies:
            Readers:
                Type: ImplicitMeta
                Rule: "ANY Readers"
            Writers:
                Type: ImplicitMeta
                Rule: "ANY Writers"
            Admins:
                Type: ImplicitMeta
                Rule: "MAJORITY Admins"

    - &Ibm
        Name: IbmMSP
        ID: IbmMSP
        MSPDir: crypto-config/peerOrganizations/ibm.training.com/msp

        AnchorPeers:
            - Host: peer0.ibm.training.com
              Port: 7051

        Policies:
            Readers:
                Type: ImplicitMeta
                Rule: "ANY Readers"
            Writers:
                Type: ImplicitMeta
                Rule: "ANY Writers"
            Admins:
                Type: ImplicitMeta
                Rule: "MAJORITY Admins"

Orderer: &OrdererDefaults

    OrdererType: solo
    Addresses:
        - orderer.training.com:7050

    BatchTimeout: 2s

    BatchSize:
        MaxMessageCount: 10
        AbsoluteMaxBytes: 99 MB
        PreferredMaxBytes: 512 KB

    Kafka:
        Brokers:
            - 127.0.0.1:9092

    Organizations:
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"

Channel: &ChannelDefaults
    # Policies defines the set of policies at this level of the config tree
    # For Channel policies, their canonical path is
    #   /Channel/&lt;PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"

Application: &ApplicationDefaults

    # Organizations is the list of orgs which are defined as participants on
    # the application side of the network
    Organizations:

    # Policies defines the set of policies at this level of the config tree
    # For Application policies, their canonical path is
    #   /Channel/Application/&lt;PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"

################################################################################
#
#   Profile
#
#   - Different configuration profiles may be encoded here to be specified
#   as parameters to the configtxgen tool
#
################################################################################
Profiles:

    TrainingOrdererGenesis:
        &lt;&lt;: *ChannelDefaults
        Orderer:
            &lt;&lt;: *OrdererDefaults
            Organizations:
                - *OrdererOrg
        Consortiums:
            TrainingConsortium:
                Organizations:
                    - *Sap
                    - *Ibm
    TrainingChannel:
        Consortium: TrainingConsortium
        Application:
            &lt;&lt;: *ApplicationDefaults
            Organizations:
                - *Sap
                - *Ibm

猛一看会感觉这个配置文件的内容有点儿多，我们可以从一个入口进去，拆开来慢慢看。在这个文件里有两个 Profile，一个是 TrainingOrdererGenesis , 一个是 TrainingChannel 。一个 Profile 代表了一组配置，我们生成创世区块用的就是 TrainingOrdererGenesis 这个 Profile。里面包含了通道相关配置，Orderer 节点相关配置，联盟成员相关配置。通道相关配置确定了系统通道的一些权限策略，Orderer 节点配置确定了 Orderer 节点的类型（是 solo 还是 kafaka），Orderer 节点的访问地址，还有出块时间，区块大小，区块内允许包含的交易数量等。联盟配置确定了联盟的名称和联盟所包含的组织，对组织来说这里最为关键的是组织的 MSP ID 和路径，这些信息都会被包含到 system chain 中。

我们可以在当前目录创建一个 artifacts 文件夹来存放要接下来要生成的各种区块链工件。

mkdir artifacts

然后用下面的命令来生成创世区块：

configtxgen -profile TrainingOrdererGenesis -channelID orderer-channel -outputBlock artifacts/orderer.genesis.block

如果我们不指定配置文件的路径，该命令会从当前目录下读取名为 configtx.yaml 的配置文件。这个命令需要指定一个 channelID，注意这里的 channelID 为系统链(system chain)的 channelID。

到这一步，其实就可以通过 orderer 命令或 docker 容器来启动网络了，orderer 启动的时候会查找一个名为 orderer.yaml 的配置文件，文件内容比较多，具体可以查看 orderer 默认配置。这个配置文件不是必须的，在找不到这个配置文件时，orderer 命令会使用默认配置。我们也可以通过环境变量或命令行参数的方式去对每个配置项进行覆盖。下面截图里"environment"配置项，实际上就是在 docker 启动的时候，通过环境变量覆盖 orderer 默认配置对 orderer 节点进行自定义配置。

为了方便我们做实验，可以把 fabric-samples/first-network/base 文件夹拷贝到当前目录，将配置文件里的域名和环境变量进行替换来作为自己 fabric 配置的基础，节省一些工作量。

实际工作中，我们也倾向与尽量站在前人的肩上，能复用的复用，将自己更多的时间花费在更有创造性的贡献中去。

尽管这时我们已经可以启动 fabric 网络了，但这个网络没有任何应用级别的通道（channel），相当于也没啥用。

所以一般来说，我们也会把创建应用通道所需要的工件准备好，再进行网络的启动。

第五步生成通道交易

注意：这里我们生成的是个用来生成通道创世区块的交易，而不是创世区块。通过下面的命令，可以生成这样的一个交易。

configtxgen -profile TrainingChannel -outputCreateChannelTx artifacts/training-channel.tx -channelID training-channel

该命令会读取和生成 Orderer 相同的配置文件，只是使用了 "TrainingChannel" 这个 Profile，确定了通道的权限策略，创建通道的联盟和组织信息。

只是创建了通道，而不创建锚节点的化，通道区块数据就无法跨组织传播，所以一般还要通过下面的命令创建用来更新锚节点的交易。

configtxgen -profile TrainingChannel -outputAnchorPeersUpdate artifacts/SapMSPAnchor.tx -asOrg SapMSP -channelID training-channel

configtxgen -profile TrainingChannel -outputAnchorPeersUpdate artifacts/IbmMSPAnchor.tx -asOrg IbmMSP -channelID training-channel

上面的命令生成了为每个组织生成锚节点的交易。

到这里，我们就可以通过 “peer 命令” 或 docker 容器启动包含 Orderer 节点，Peer 节点的 Fabric 网络了。peer 命令在启动 peer 节点时默认会读取 core.yaml, 该文件的默认配置见 peer节点配置。

在读到这个配置文件之前，我一致对 fabric 网络中 leader 节点如何产生，orderer 节点如何感知 leader 节点的变化一致不是太清楚，但这个配置文件把这点儿描述的算是比较清楚了。

        # Defines whenever peer will initialize dynamic algorithm for
        # "leader" selection, where leader is the peer to establish
        # connection with ordering service and use delivery protocol
        # to pull ledger blocks from ordering service. It is recommended to
        # use leader election for large networks of peers.
        useLeaderElection: true
        # Statically defines peer to be an organization "leader",
        # where this means that current peer will maintain connection
        # with ordering service and disseminate block across peers in
        # its own organization
        orgLeader: false

从配置描述基本可以推断出，peer 节点会主动联系 orderer 节点来明确当前的 leader 节点。

这个阶段把网络启动后，还是啥事都做不了，节点之间也没有通信。因为我们还没真正去生成应用通道的创世区块。这时我们通过下面的命令来生成应用通道的创世区块：

peer channel create -t 50s -o orderer.training.com:7050 -c training-channel -f ./channel-artifacts/training-channel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/training.com/orderers/orderer.training.com/msp/tlscacerts/tlsca.training.com-cert.pem

然后通过下面的命令加入区块：

peer channel join -b training-channel.block

在通过下面的命令来更新组织的锚节点：

peer channel update -o orderer.training.com:7050 -c training-channel -f ./channel-artifacts/SapMSPAnchor.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/training.com/orderers/orderer.training.com/msp/tlscacerts/tlsca.training.com-cert.pem

为什么创建应用通道搞的这么繁琐呢？我想这主要由联盟链的性质决定的：

对联盟链上与联盟成员有关的任何网络变动，都要网络成员的确定。否则，如果任何一个成员都可以对网络进行修改，整个网络的信任基础也就荡然无存了。
加入通道，修改通道配置这些操作都需要各个网络成员的确认。将操作步骤分开，由每个节点的管理员自主加入通道，由每个组织的管理员来更新锚点等配置。实际上是让每个组织对相关操作进行了确认。

锚节点更新成功之后，一个可用的，带有应用通道的 Fabric 网络就启动起来了。我们接下来就可以向网络中部署链码来实现业务逻辑了。