Hyperledger Fabric 2.0跨不同组织双通道链码部署及背书问题咨询

完全可以在各自包含不同组织的独立通道中创建、部署链码并实现组织隔离，你遇到的需要另一通道组织背书的问题，大概率是链码配置或操作流程出现了偏差，下面我帮你梳理可能的原因和解决办法：

核心问题定位 #

Fabric 2.0中通道是天然隔离的资源边界，每个通道的链码只需要该通道内的组织参与背书。出现跨通道背书要求，通常是以下几个环节出了问题：

1. 链码定义的背书策略错误 #

你可能在配置链码的背书策略时，误将其他通道的组织MSP（比如Org3MSP）包含了进去，导致部署时需要该组织的签名；或者在批准/提交链码定义时，错误地将跨通道组织纳入了需要同意的成员列表。

2. 通道成员配置不严谨 #

如果某个通道的配置里不小心加入了其他通道的组织（比如通道A里包含了通道B的Org3），那么链码部署时自然会要求该组织的背书。

3. 操作时的上下文混淆 #

部署链码时没有正确切换组织/通道的上下文环境（比如环境变量CORE_PEER_LOCALMSPID、CHANNEL_ID设置错误），导致用了其他通道的组织身份去操作当前通道的链码。

正确的操作流程示例 #

假设你有两个通道：

• 通道channel-1：包含组织Org1、Org2
• 通道channel-2：包含组织Org3、Org4

针对channel-1部署链码 #

1. 安装链码包：只在Org1和Org2的节点上安装链码

   # 切换到Org1的peer节点上下文
   export CORE_PEER_LOCALMSPID="Org1MSP"
   export CORE_PEER_ADDRESS=peer0.org1.example.com:7051
   peer lifecycle chaincode install mycc.tar.gz
   
   # 切换到Org2的peer节点上下文
   export CORE_PEER_LOCALMSPID="Org2MSP"
   export CORE_PEER_ADDRESS=peer0.org2.example.com:7051
   peer lifecycle chaincode install mycc.tar.gz
   

2. 批准链码定义：每个通道内的组织单独批准，背书策略只包含当前通道的组织

   # Org1批准，背书策略设置为Org1或Org2的peer背书即可
   peer lifecycle chaincode approveformyorg -o orderer.example.com:7050 \
     --channelID channel-1 --name mycc --version 1.0 \
     --package-id mycc_1.0:<package-id> --sequence 1 \
     --signature-policy "OR('Org1MSP.peer','Org2MSP.peer')"
   
   # Org2执行同样的批准命令（注意替换自己的package-id）
   

3. 提交链码定义到通道：只需要通道内的组织完成批准后提交，无需其他通道组织参与

   peer lifecycle chaincode commit -o orderer.example.com:7050 \
     --channelID channel-1 --name mycc --version 1.0 --sequence 1 \
     --peerAddresses peer0.org1.example.com:7051 --peerAddresses peer0.org2.example.com:7052
   

针对channel-2部署链码 #

重复上述流程，但注意：

• 只在Org3、Org4的节点上安装链码
• 背书策略设置为"OR('Org3MSP.peer','Org4MSP.peer')"
• 提交时指定channel-2和对应节点地址

关键检查点 #

• 确认每个通道的配置中，只有该通道的组织MSP被添加，没有混入其他通道的组织
• 每次操作链码前，务必确认当前的环境变量（CORE_PEER_LOCALMSPID、CHANNEL_ID、CORE_PEER_ADDRESS）对应正确的组织和通道
• 链码的背书策略要严格限定在当前通道的组织范围内，避免使用全局或跨组织的策略

内容的提问来源于stack exchange，提问作者user14420852