Hyperledger Fabric中peer0 Org2用marbles02链码创建Marble失败求助

根据你描述的情况，在Org1的peer上操作正常，但Org2的peer执行initMarble返回成功却无实际数据，大概率是交易执行后的账本写入、同步环节出了问题，或者链码/身份配置有疏漏。下面一步步排查解决：

1. 确认Org2 peer的身份上下文是否正确 #

在cli容器中操作Org2的peer时，必须切换到Org2的身份环境，否则即使命令发送到peer0.org2，调用者身份还是Org1，可能触发链码隐藏的权限逻辑（虽然你说返回成功，但还是要确认）。执行以下命令切换上下文：

export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=peer0.org2.example.com:7051

切换后再重新执行initMarble命令试试。

2. 检查peer0.org2的CouchDB连接与状态 #

你修改了CouchDB端口避免冲突，很可能peer0.org2的配置里没有同步更新CouchDB地址，导致交易模拟成功但无法写入状态数据库：

• 先确认couchdb.org2容器是否正常运行：docker ps | grep couchdb.org2，检查端口映射是否是你修改后的（比如6984）。
• 查看peer0.org2的容器日志，搜索CouchDB相关错误：docker logs peer0.org2.example.com | grep -i couchdb，如果出现connection refused或者failed to connect，说明peer配置的CouchDB地址不对。
• 检查peer0.org2的环境变量，确认CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS是否指向正确的CouchDB地址（比如couchdb.org2:6984，对应你修改的端口）。如果是通过docker-compose配置的，要确保environment里的这个参数已经更新。

3. 追踪交易的完整生命周期 #

执行initMarble后会得到一个交易ID（比如tx_id: 0abc123...），用这个ID排查交易的流转：

• 在peer0.org2的日志中搜索该交易ID，看是否有committing transaction的日志，或者是否有提交失败的错误（比如账本写入失败）。
• 查看排序节点日志：docker logs orderer.example.com | grep <交易ID>，确认排序节点是否接收了该交易并生成了区块。
• 在peer0.org2上手动获取最新区块，检查是否包含该交易：

  peer channel fetch newest mychannel_newest.block -o orderer.example.com:7050 -c mychannel --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
  peer channel inspect mychannel_newest.block | grep <交易ID>
  

如果区块里没有这个交易，说明交易没被排序节点处理；如果有但peer没写入，就是peer的账本同步或写入问题。

4. 检查链码的背书策略与访问控制 #

虽然你说命令返回成功，但还是要确认marbles02链码是否有组织访问限制：

• 查看marbles02的链码代码，检查initMarble函数里是否有验证调用者MSPID的逻辑（比如只允许Org1MSP的用户创建）。如果有，你需要修改链码去掉限制，或者在Org2的身份下添加对应的权限。
• 确认链码实例化时的背书策略是否允许Org2的peer背书。first-network默认的背书策略是OR ('Org1MSP.member', 'Org2MSP.member')，如果你的实例化命令修改过这个策略，比如只允许Org1，那Org2的peer背书的交易不会被确认。可以通过以下命令查看通道的链码背书策略：

  peer chaincode list --instantiated -C mychannel
  

5. 排查Fabric版本的潜在问题 #

你用的是Fabric 1.1.0-preview版本，这个预览版可能存在一些未修复的bug，比如交易提交的一致性问题。如果以上排查都没问题，可以考虑升级到1.1.x的正式版（比如1.1.5），再测试看看是否解决问题。

按照上面的步骤逐一排查，应该能定位到问题所在。

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