Centos7 Fabric2.4 网络搭建（二）

提示：上一篇文章讲到用cryptogen为组织内的orderer、peer颁发证书后，再用docker启动orderer和peer，接着是创建通道。

---

目录

前言

一、主脚本中创建通道

二、createChannel.sh

2.1 创建通道创世区块

2.2 使用 osnadmin CLI 将 orderer 添加到通道

2.3 peer 加入通道

2.4 设置锚节点

 遇到的问题总结

---

前言

第一部分：Centos7 Fabric2.4 网络搭建（一）_Big. boss的博客-CSDN博客

---

提示：用的是官方的例子学习搭建自己的网络，本次是用cryptogen生成证书，单机多节点部署

一、主脚本中创建通道

为了简化channel创建过程并增强channel的隐私性和可伸缩性，现在可以创建应用程序channel（涉及资产的交易发生的地方），而无需首先创建由orderer管理的“system channel”。本案例是在没有system channel的情况下创建新channel，方法是使用configtxgen工具创建genesis块，并使用osnadmin CLI（它运行在每个orderer节点公开的REST API上）将orderer节点连接到channel。这个过程允许orderer节点根据需要加入（或离开）任意数量的channel，类似于peer节点可以参与多个channel的方式。

# Step4 创建通道
function createChannel() {
  # 如果网络尚未启动，请启动网络
  bringUpNetwork="false"

  if ! $CONTAINER_CLI info > /dev/null 2>&1 ; then
    fatalln "$CONTAINER_CLI network is required to be running to create a channel"
  fi

  # 检查是否所有容器是否准备好
  CONTAINERS=($($CONTAINER_CLI ps | grep hyperledger/ | awk '{print $2}'))
  len=$(echo ${#CONTAINERS[@]})

  if [[ $len -ge 8 ]] && [[ ! -d "organizations/peerOrganizations" ]]; then
    echo "Bringing network down to sync certs with containers"
    networkDown
  fi

  [[ $len -lt 8 ]] || [[ ! -d "organizations/peerOrganizations" ]] && bringUpNetwork="true" || echo "Network Running Already"

  if [ $bringUpNetwork == "true"  ]; then
    infoln "Bringing up network"
    networkUp
  fi

  # 现在运行创建频道的脚本。此脚本使用configtxgen一次性创建通道创建事务和锚节点对等更新
  scripts/createChannel.sh $CHANNEL_NAME $CLI_DELAY $MAX_RETRY $VERBOSE
}

二、createChannel.sh

2.1 创建通道创世区块

创建新通道的过程首先为通道生成创世块，稍后将在请求中提交给orderer。只需要一个orderer需要创建创世块，并且可以与通道上的其他成员进行带外共享，这些成员可以检查它以确保他们同意通道配置，然后由排序服务中的每个排序者使用。

FABRIC_CFG_PATH=${PWD}/configtx

## Create channel genesis block
infoln "Generating channel genesis block '${CHANNEL_NAME}.block'"
createChannelGenesisBlock


# 函数 - 创建通道创世区块
createChannelGenesisBlock() {
  # 搜索configtxgen命令，判断是否存在此二进制文件，若不存在，打印错误信息，程序终止
	which configtxgen
	if [ "$?" -ne 0 ]; then
		fatalln "configtxgen tool not found."
	fi
	set -x  #脚本调试，会将下面执行的命令输出到屏幕上
	# 创建创世区块：生成创世区块mychannel.block文件，根据配置文件../configtx/configtx.yaml来创建Orderer系统通道的创世块
	configtxgen -profile TwoOrgsApplicationGenesis -outputBlock ./channel-artifacts/${CHANNEL_NAME}.block -channelID $CHANNEL_NAME
	res=$?
	{ set +x; } 2>/dev/null
  verifyResult $res "Failed to generate channel configuration transaction..."
}

涉及到一个重要的文件configtx.yaml，详细内容参考Hyperledger Fabric 配置文件解析——configtx.yaml_Big. boss的博客-CSDN博客

与Fabric2.2流程不同：

1.不再需要系统通道：除了代表一个额外步骤的系统通道的建立，创建了一个额外的管理层，对于某些用例没有体统任何切实的好处。

2.不再需要联盟：在configtx.yaml不再需要定义一组组织（“consortium”），允许在特定的orderer上创建通道。新的流程中，所有的通道都是application channels，不再需要创建通道的组织列表这个概念。任何一组组织都可以聚集在一起并使用一组定义的排序节点来创建通道。

3.简化orderer节点创建过程：在创建orderer节点之前，系统通道的genesis块不再需要，admin现在可以专注于基础设置的过程，并在加入特定application channel之前确保其节点正常工作。

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

---
################################################################################
#
#   Section: Organizations
#
#   - This section defines the different organizational identities which will
#   be referenced later in the configuration.
#
################################################################################
Organizations:

    # SampleOrg defines an MSP using the sampleconfig.  It should never be used
    # in production but may be used as a template for other definitions
    - &OrdererOrg
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        # 组织名称
        Name: OrdererOrg

        # ID to load the MSP definition as
        # 组织ID，ID是引用组织的关键
        ID: OrdererMSP

        # MSPDir is the filesystem path which contains the MSP configuration
        # 组织的MSP证书路径
        MSPDir: ../organizations/ordererOrganizations/hmw.com/msp

        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        # 定义本层级的组织策略，其权威路径为 /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('OrdererMSP.member')"
            Writers:
                Type: Signature
                Rule: "OR('OrdererMSP.member')"
            Admins:
                Type: Signature
                Rule: "OR('OrdererMSP.admin')"

        OrdererEndpoints:
            - orderer0.hmw.com:7050
            - orderer1.hmw.com:7052
            - orderer2.hmw.com:7054

    - &Org1
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: Org1MSP

        # ID to load the MSP definition as
        ID: Org1MSP

        MSPDir: ../organizations/peerOrganizations/org1.hmw.com/msp

        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org1MSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org1MSP.peer')"

    - &Org2
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: Org2MSP

        # ID to load the MSP definition as
        ID: Org2MSP

        MSPDir: ../organizations/peerOrganizations/org2.hmw.com/msp

        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org2MSP.admin', 'Org2MSP.peer', 'Org2MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org2MSP.admin', 'Org2MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org2MSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org2MSP.peer')"

################################################################################
#
#   SECTION: Capabilities
#
#   - This section defines the capabilities of fabric network. This is a new
#   concept as of v1.1.0 and should not be utilized in mixed networks with
#   v1.0.x peers and orderers.  Capabilities define features which must be
#   present in a fabric binary for that binary to safely participate in the
#   fabric network.  For instance, if a new MSP type is added, newer binaries
#   might recognize and validate the signatures from this type, while older
#   binaries without this support would be unable to validate those
#   transactions.  This could lead to different versions of the fabric binaries
#   having different world states.  Instead, defining a capability for a channel
#   informs those binaries without this capability that they must cease
#   processing transactions until they have been upgraded.  For v1.0.x if any
#   capabilities are defined (including a map with all capabilities turned off)
#   then the v1.0.x peer will deliberately crash.
#
################################################################################
Capabilities:
    # Channel capabilities apply to both the orderers and the peers and must be
    # supported by both.
    # Set the value of the capability to true to require it.
    Channel: &ChannelCapabilities
        # V2_0 capability ensures that orderers and peers behave according
        # to v2.0 channel capabilities. Orderers and peers from
        # prior releases would behave in an incompatible way, and are therefore
        # not able to participate in channels at v2.0 capability.
        # Prior to enabling V2.0 channel capabilities, ensure that all
        # orderers and peers on a channel are at v2.0.0 or later.
        V2_0: true

    # Orderer capabilities apply only to the orderers, and may be safely
    # used with prior release peers.
    # Set the value of the capability to true to require it.
    Orderer: &OrdererCapabilities
        # V2_0 orderer capability ensures that orderers behave according
        # to v2.0 orderer capabilities. Orderers from
        # prior releases would behave in an incompatible way, and are therefore
        # not able to participate in channels at v2.0 orderer capability.
        # Prior to enabling V2.0 orderer capabilities, ensure that all
        # orderers on channel are at v2.0.0 or later.
        V2_0: true

    # Application capabilities apply only to the peer network, and may be safely
    # used with prior release orderers.
    # Set the value of the capability to true to require it.
    Application: &ApplicationCapabilities
        # V2_0 application capability ensures that peers behave according
        # to v2.0 application capabilities. Peers from
        # prior releases would behave in an incompatible way, and are therefore
        # not able to participate in channels at v2.0 application capability.
        # Prior to enabling V2.0 application capabilities, ensure that all
        # peers on channel are at v2.0.0 or later.
        V2_0: true

################################################################################
#
#   SECTION: Application
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for application related parameters
#
################################################################################
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"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"

    Capabilities:
        <<: *ApplicationCapabilities
################################################################################
#
#   SECTION: Orderer
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for orderer related parameters
#
################################################################################
Orderer: &OrdererDefaults

    # Orderer Type: The orderer implementation to start
    # 定义order共识机制
    OrdererType: etcdraft
    # Addresses used to be the list of orderer addresses that clients and peers
    # could connect to.  However, this does not allow clients to associate orderer
    # addresses and orderer organizations which can be useful for things such
    # as TLS validation.  The preferred way to specify orderer addresses is now
    # to include the OrdererEndpoints item in your org definition
    Addresses:
        - orderer0.hmw.com:7050
        - orderer1.hmw.com:7052
        - orderer2.hmw.com:7054

    EtcdRaft:
        Consenters:
        - Host: orderer0.hmw.com
          Port: 7050
          ClientTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer0.hmw.com/tls/server.crt
          ServerTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer0.hmw.com/tls/server.crt
        - Host: orderer1.hmw.com
          Port: 7052
          ClientTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer1.hmw.com/tls/server.crt
          ServerTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer1.hmw.com/tls/server.crt
        - Host: orderer2.hmw.com
          Port: 7054
          ClientTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer2.hmw.com/tls/server.crt
          ServerTLSCert: ../organizations/ordererOrganizations/hmw.com/orderers/orderer2.hmw.com/tls/server.crt

    # Batch Timeout: The amount of time to wait before creating a batch
    # 区块生成超时时间
    BatchTimeout: 2s

    # Batch Size: Controls the number of messages batched into a block
    BatchSize:

        # Max Message Count: The maximum number of messages to permit in a batch
        # 区块消息数量
        MaxMessageCount: 10

        # Absolute Max Bytes: The absolute maximum number of bytes allowed for
        # the serialized messages in a batch.
        # 区块绝对最大字节数
        AbsoluteMaxBytes: 99 MB

        # Preferred Max Bytes: The preferred maximum number of bytes allowed for
        # the serialized messages in a batch. A message larger than the preferred
        # max bytes will result in a batch larger than preferred max bytes.
        # 建议消息字节数
        PreferredMaxBytes: 512 KB

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

    # Policies defines the set of policies at this level of the config tree
    # For Orderer policies, their canonical path is
    #   /Channel/Orderer/<PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        # BlockValidation specifies what signatures must be included in the block
        # from the orderer for the peer to validate it.
        BlockValidation:
            Type: ImplicitMeta
            Rule: "ANY Writers"

################################################################################
#
#   CHANNEL
#
#   This section defines the values to encode into a config transaction or
#   genesis block for channel related parameters.
#
################################################################################
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:
        # Who may invoke the 'Deliver' API
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        # Who may invoke the 'Broadcast' API
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        # By default, who may modify elements at this config level
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"

    # Capabilities describes the channel level capabilities, see the
    # dedicated Capabilities section elsewhere in this file for a full
    # description
    Capabilities:
        <<: *ChannelCapabilities

################################################################################
#
#   Profile
#
#   - Different configuration profiles may be encoded here to be specified
#   as parameters to the configtxgen tool
#
################################################################################
Profiles:
    TwoOrgsApplicationGenesis:
        <<: *ChannelDefaults
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
            Capabilities: *OrdererCapabilities
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
            Capabilities: *ApplicationCapabilities

2.2 使用 osnadmin CLI 将 orderer 添加到通道

现在已经创建了 Genesis 块，接收 osnadmin 通道连接命令命令的第一订购节点有效地“激活”通道，尽管频道未完全运行，直到建立了仲裁频率（如果您的策略列出了三个同意，则至少一个节点总共两个，必须使用osnadmin通道连接命令加入）

# 函数 - 激活通道
createChannel() {
  # 调用脚本 envVar.sh中的函数setGlobals，为org1或org2的peer节点设置环境变量，参数01对应的是org1，02对应org2
  # 设置环境变量为org1
	setGlobals 01
	# Poll in case the raft leader is not set yet
	local rc=1
	local COUNTER=1
	# 创建通道若未成功，可尝试5次
	while [ $rc -ne 0 -a $COUNTER -lt $MAX_RETRY ] ; do
		sleep $DELAY
		set -x
		# 创建通道，将执行结果信息记录到log.txt文件中
		infoln "Orderer0 join channel"
		osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/${CHANNEL_NAME}.block -o localhost:7051 --ca-file "$ORDERER_CA" --client-cert "$ORDERER_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER_ADMIN_TLS_PRIVATE_KEY" >&log.txt
		infoln "Orderer1 join channel"
        osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/${CHANNEL_NAME}.block -o localhost:7053 --ca-file "$ORDERER_CA" --client-cert "$ORDERER1_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER1_ADMIN_TLS_PRIVATE_KEY" >&log.txt
		infoln "Orderer2 join channel"
        osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/${CHANNEL_NAME}.block -o localhost:7055 --ca-file "$ORDERER_CA" --client-cert "$ORDERER2_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER2_ADMIN_TLS_PRIVATE_KEY" >&log.txt
		res=$?
		{ set +x; } 2>/dev/null
		let rc=$res
		COUNTER=$(expr $COUNTER + 1)
	done
	# 打印log.txt，即打印创建通道结果信息
	cat log.txt
	# 调用脚本 envVar.sh 中的函数verifyResult，用来验证上面执行的命令是否报错，如果报错，则打印错误信息，程序终止
	verifyResult $res "Channel creation failed"
}

成功后，orderer将加入带有leader height 为 1 的通道中，因为这个orderer是从创世区块加入的，所以显示 status 的状态时 "active"。并且orderer是通道的consenter，所以consensusRelation是"consenter"。 

2.3 peer 加入通道

## Join all the peers to the channel
infoln "Joining peer0-org1 to the channel..."
joinChannel 01
infoln "Joining peer1-org1 to the channel..."
joinChannel 11
infoln "Joining peer0-org2 to the channel..."
joinChannel 02
infoln "Joining peer1-org2 to the channel..."
joinChannel 12

# joinChannel ORG
joinChannel() {
  FABRIC_CFG_PATH=${PWD}/config/
  ORG=$1
  # 根据传递的参数设置环境变量，切换组织使用
  setGlobals $ORG
	local rc=1
	local COUNTER=1
	# peer节点加入通道若未成功，可尝试5次
	while [ $rc -ne 0 -a $COUNTER -lt $MAX_RETRY ] ; do
    sleep $DELAY
    set -x
    # 将节点加入通道，将执行结果信息记录到log.txt文件中
    peer channel join -b $BLOCKFILE >&log.txt
    res=$?
    { set +x; } 2>/dev/null
		let rc=$res
		COUNTER=$(expr $COUNTER + 1)
	done
	cat log.txt
	verifyResult $res "After $MAX_RETRY attempts, peer0.org${ORG} has failed to join channel '$CHANNEL_NAME' "
}

2.4 设置锚节点

最后，在组织将其对等节点加入频道后，他们应至少选择其中一个对等节点成为锚节点。为了利用私有数据和服务发现等功能，需要锚节点。每个组织都应该在一个通道上设置多个锚节点以实现冗余。每个组织的锚节点的端点信息都包含在通道配置中。每个通道成员都可以通过更新通道来指定它们的锚节点。

## Set the anchor peers for each org in the channel
infoln "Setting anchor peer for org1..."
setAnchorPeer 01
infoln "Setting anchor peer for org2..."
setAnchorPeer 02


# 函数 - 设置锚节点
setAnchorPeer() {
  ORG=$1
  ${CONTAINER_CLI} exec cli ./scripts/setAnchorPeer.sh $ORG $CHANNEL_NAME
}

每个通道成员都可以通过更新通道来指定它们的锚节点。我们将使用configtxlator 来为Org1 和Org2更新通道配置。

Org1设置环境变量

export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.hmw.com/tlsca/tlsca.org1.hmw.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.hmw.com/users/[email protected]/msp
export CORE_PEER_ADDRESS=localhost:8051

通过以下命令可以获取通道配置

  infoln "Fetching the most recent configuration block for the channel"
  set -x
  # 获取通道配置
  peer channel fetch config config_block.pb -o orderer0.hmw.com:7050 --ordererTLSHostnameOverride orderer0.hmw.com -c $CHANNEL --tls --cafile "$ORDERER_CA"
  { set +x; } 2>/dev/null
  res=$?
  if [ $res -ne 0 ]; then
    fatalln "Failed to fetch the most recent configuration block..."
  fi

由于最近的通道配置块是信道创世纪块，因此命令从通道返回块0

我们现在可以开始使用configtxlator工具开始使用通道配置。第一步是将来自protobuf的块解码为可以读取和编辑的json对象。我们还脱离了不必要的块数据，仅留下了通道配置。

  # 将配置块protobuf格式转成json格式
  configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json
  jq .data.data[0].payload.data.config config_block.json >"${OUTPUT}"

这些命令将通道配置块转换为一个简化json，config.json，将作为我们更新的基准。

可以使用jq工具将org1锚节点添加到通道配置

  set -x
  # Modify the configuration to append the anchor peer
  # 将锚节点添加至配置文件中
  jq '.channel_group.groups.Application.groups.'${CORE_PEER_LOCALMSPID}'.values += {"AnchorPeers":{"mod_policy": "Admins","value":{"anchor_peers": [{"host": "'$HOST'","port": '$PORT'}]},"version": "0"}}' ${CORE_PEER_LOCALMSPID}config.json > ${CORE_PEER_LOCALMSPID}modified_config.json
  { set +x; } 2>/dev/null

在此步骤之后，我们在modified_config.json文件中以json格式更新了频道配置的更新版本。我们现在可以将原始和修改的通道配置转换回protobuf格式并计算它们之间的差异

  # 将原始和修改的通道配置都转换回protobuf格式，并计算它们之间的差异
  configtxlator proto_encode --input "${ORIGINAL}" --type common.Config --output original_config.pb
  configtxlator proto_encode --input "${MODIFIED}" --type common.Config --output modified_config.pb
  configtxlator compute_update --channel_id "${CHANNEL}" --original original_config.pb --updated modified_config.pb --output config_update.pb

新的protobuf文件叫config_update.pb，包含了应用于通道配置的锚节点更新，我们可以在事务信封中包装配置更新以创建通道配置更新事务

  # 将配置更新包装在交易Envelope中，以创建通道配置更新交易
  configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json
  echo '{"payload":{"header":{"channel_header":{"channel_id":"'$CHANNEL'", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . >config_update_in_envelope.json
  configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output "${OUTPUT}"
  { set +x; } 2>/dev/null

我们可以通过peer channel update指令提供新的通道配置来增加锚节点。

因为我们正在更新仅影响org1的通道配置的一部分，因此其他频道成员不需要批准通道更新

peer channel update -o orderer0.hmw.com:7050 --ordererTLSHostnameOverride orderer0.hmw.com -c $CHANNEL_NAME -f ${CORE_PEER_LOCALMSPID}anchors.tx --tls --cafile "$ORDERER_CA" >&log.txt

同样道理，设置好环境变量，为Org2添加锚节点 

可以通过以下命令确认通道已经更新：

export FABRIC_CFG_PATH=${PWD}/config/
export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org1.hmw.com/tlsca/tlsca.org1.hmw.com-cert.pem
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.hmw.com/users/[email protected]/msp
export CORE_PEER_ADDRESS=localhost:8051
peer channel getinfo -c mychannel

通过上述更新锚节点，向创世区块添加两个通道配置文件来更新通道，所以通道的区块高度变成3并且哈希值也被更新

 相关代码请参考：https://blog.csdn.net/humingwei11/article/details/124128401

---

 遇到的问题总结

1.Error: can't read the block: &{SERVICE_UNAVAILABLE} 

​​

这个问题困扰我好久，原来是因为在加入通道的时候，没有把所有的orderer加入通道 。2

set -x
# 创建通道，将执行结果信息记录到log.txt文件中
infoln "Orderer0 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/${CHANNEL_NAME}.block -o orderer0.hmw.com:7051 --ca-file "$ORDERER_CA" --client-cert "$ORDERER_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER_ADMIN_TLS_PRIVATE_KEY" >&log.txt
infoln "Orderer1 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/${CHANNEL_NAME}.block -o orderer1.hmw.com:7053 --ca-file "$ORDERER_CA" --client-cert "$ORDERER1_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER1_ADMIN_TLS_PRIVATE_KEY" >&log.txt
infoln "Orderer2 join channel"
osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/${CHANNEL_NAME}.block -o orderer2.hmw.com:7055 --ca-file "$ORDERER_CA" --client-cert "$ORDERER2_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER2_ADMIN_TLS_PRIVATE_KEY" >&log.txt
res=$?
{ set +x; } 2>/dev/null

2.在orderer加入通道中，-o 我写localhost 出现tls证书握手失败

 原因是之前在crypto-config-orderer.yaml中，Specs中忘记在每一个Hostname下加SANS