Hyperledger Fabric 多主机部署下全组织审批后链码commit报FreightMSP未同意错误

两个报错不是孤立出现的，本质是跨网络命名空间操作导致的链码定义审批上下文错位：

• 宿主机直连peer时报connection refused，说明你之前在宿主机执行的所有链码操作（含FreightMSP的approve步骤）根本没有真正连接到对应peer节点，部分命令的成功返回是因为CLI客户端从orderer侧拉取了其他组织的账本数据做的聚合展示，不代表当前操作的peer本地账本真的存了审批记录。
• 换到Swarm内的CLI容器执行commit时，peer节点会校验本地账本里存储的链码审批记录，发现FreightMSP的peer本地没有对应版本的链码审批签名，就会抛出chaincode definition not agreed to by this org的报错。

1. 修正操作上下文，避免跨网络边界操作 #

• 所有链码生命周期操作（approve、checkcommitreadiness、commit）必须在Swarm网络内部完成，不要在宿主机直接执行需要连接peer的命令：
  • 给CLI容器配置和目标组织完全匹配的环境变量：
    • CORE_PEER_LOCALMSPID=FreightMSP
    • CORE_PEER_ADDRESS=freight-peer0.freight.svc:7051（用Swarm服务的内部DNS域名，不要用localhost/127.0.0.1，避免命中容器回环地址）
    • 配置正确的CORE_PEER_TLS_ROOTCERT_FILE路径，指向FreightMSP peer的TLS根证书
• 不要从宿主机跨命名空间连接Swarm内的peer端口：之前的connection refused报错就是因为peer的7051端口只绑定在Swarm overlay网络的服务IP上，没有暴露到宿主机的网络接口，宿主机发起的连接根本无法到达peer节点。

2. 补全审批请求的参数一致性校验 #

很多场景下的认知误区是：checkcommitreadiness返回全true不代表所有参数完全对齐，因为这个命令是从orderer拉取全量区块做的聚合统计，只要有某个组织的peer广播了审批交易，就会显示true，但commit阶段peer只会校验本地账本存的审批记录参数和当前提交的参数是不是完全逐字符匹配。

• 逐参数核对之前各组织执行approve命令时带的所有值，确保commit命令里的参数和approve阶段100%一致：
  • 链码名称--name
  • 版本号--version
  • 序列号--sequence
  • 是否需要初始化标识--init-required
  • 签名策略--signature-policy
  • 链码的系统链码版本--escc/--vscc（如果审批时指定过）
• 重点核对参数偏差：你之前执行checkcommitreadiness、approve时带了完整的--signature-policy参数，但是执行commit的命令里完全漏传了这个参数，这种情况下peer本地存的审批记录对应了带特定policy的链码定义，当前commit提交的定义没有policy配置，生成的哈希值和之前审批的版本完全不同，就会被判定为不是之前审批过的版本。

3. 重新执行FreightMSP的审批流程 #

• 在已经配置好FreightMSP身份的CLI容器里，重新发起一次FreightMSP的approve命令，所有参数和之前其他组织审批时用的参数完全对齐，确保这笔approve交易真的被FreightMSP的peer接收、签名、广播到orderer：

  peer lifecycle chaincode approveformyorg -o orderer0.freight.example.com:9050 --ordererTLSHostnameOverride orderer0.freight.example.com --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/freight.example.com/orderers/orderer0.freight.example.com/msp/tlscacerts/tlsca.freight.example.com-cert.pem --channelID supplychain-channel --name supplychain --version 1.0 --sequence 1 --init-required --signature-policy "AND ('ShipperMSP.peer','FreightMSP.peer','CarrierMSP.peer','CustomMSP.peer','ConsigneeMSP.peer')" --waitForEvent
  

• 加--waitForEvent参数确保命令一直等待到orderer确认这笔交易被写入区块，不要发起请求就立刻返回。
• 等所有组织的approve交易都确认上链后，再重新跑checkcommitreadiness，确认返回的所有组织审批状态都是true，再执行commit操作。

4. 排查隐性的账本一致性问题 #

• 检查FreightMSP的peer容器是否挂载了持久化的账本卷：如果之前重建过peer容器但没有挂载持久化目录，本地账本里存储的审批交易会随容器重启丢失，哪怕之前审批成功过，peer也会判定没有对应审批记录。
• 显式指定commit命令需要背书的所有peer地址，避免Swarm网络DNS解析异常导致某个peer没收到提案：

  peer lifecycle chaincode commit -o orderer0.freight.example.com:9050 --ordererTLSHostnameOverride orderer0.freight.example.com --tls --cafile <tls ca path> --version 1.0 --sequence 1 --init-required --channelID supplychain-channel --name supplychain --signature-policy "AND ('ShipperMSP.peer','FreightMSP.peer','CarrierMSP.peer','CustomMSP.peer','ConsigneeMSP.peer')" --peerAddresses shipper-peer0.shipper.svc:7051 --peerAddresses freight-peer0.freight.svc:7051 --peerAddresses carrier-peer0.carrier.svc:7051 --peerAddresses custom-peer0.custom.svc:7051 --peerAddresses consignee-peer0.consignee.svc:7051
  

• 检查peer的TLS证书SAN配置：确保CLI连接peer时的域名和证书里配置的SAN匹配，避免TLS静默截断连接，导致之前的approve请求实际没有被peer处理但命令没有返回明确报错。

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