Hyperledger Fabric & Composer多节点部署：网络与Composer配置技术问询

Hey there! Based on your multi-org Hyperledger Fabric + Composer setup (3 orgs each with 1 peer, 3 CAs, single orderer, shared channel, and 3-org endorsement policy), I’ve compiled answers to the most frequent technical questions folks face in this scenario:

1. How do I verify cross-org transaction endorsement is working as expected? #

• First, submit a test transaction using composer transaction submit -c admin-org1@mychannel -d '{"$class":"org.example.MyTransaction","asset":"asset1"}' (swap in your actual transaction details).
• Check each peer’s logs (e.g., docker logs peer0.org1.example.com) and search for entries containing Endorsement—you should see proof that all three org peers signed off on the transaction.
• To confirm the policy is enforced, temporarily adjust your endorsement policy to require only 2 orgs, then submit a transaction that only gets 2 endorsements. It should fail, proving your original 3-org policy is active.

2. Best practices for managing Composer cards and switching cross-org identities? #

• Name cards clearly: Stick to a consistent convention like admin-org1@mychannel, admin-org2@mychannel to avoid mixing up org identities.
• Switch explicitly: Use composer card use admin-org2@mychannel to toggle between org admin identities, and always run composer identity list -c <card-name> afterward to confirm you’re operating under the correct org’s context.
• Isolate identities: Never reuse a single card across multiple orgs—each card is tied to an org’s admin identity, which aligns with Fabric’s identity isolation model to avoid permission conflicts.

3. How to ensure all peers get updated when upgrading chaincode? #

• Reinstall on all peers first: Run the install command on every peer node:

  peer chaincode install -n mychaincode -v 2.0 -p github.com/chaincode/mychaincode
  

• Upgrade via orderer: Execute the upgrade command from one peer (using the correct admin identity) and keep your 3-org endorsement policy intact:

  peer chaincode upgrade -o orderer.example.com:7050 -C mychannel -n mychaincode -v 2.0 -c '{"Args":["init"]}' -P "AND ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')"
  

• Verify post-upgrade: On each peer, run peer chaincode list --installed and peer chaincode list --instantiated to confirm the new version is active. Submit a test query or transaction to ensure functionality works across all orgs.

4. Troubleshooting cross-org transaction failures #

• Check orderer logs: Look for errors like ENDORSEMENT_POLICY_FAILURE—this means the transaction didn’t get enough endorsements from your 3 orgs.
• Inspect peer chaincode logs: If the transaction failed during execution, peer logs will show chaincode-specific issues (e.g., data access errors).
• Ping the network with each card: Run composer network ping -c admin-orgX@mychannel for each org’s admin card to confirm network connectivity and valid identity.
• Validate connection profiles: Double-check your connection.json files for correct peer/CA addresses, TLS certificate paths, and MSP IDs—small typos here often cause cross-org issues.

5. Implementing data privacy and access control across orgs #

• Private Data Collections: Define a private collection in your chaincode config (e.g., collections_config.json) to restrict data access to specific orgs:

  {
    "name": "org1-private-collection",
    "policy": "OR('Org1MSP.member')",
    "requiredPeerCount": 1,
    "maxPeerCount": 1,
    "blockToLive": 0
  }
  

  Then use getPrivateData() and putPrivateData() in your chaincode to interact with this restricted data.
• Composer ACLs: In your permissions.acl file, define rules to control which org identities can access assets or execute transactions:

  rule Org1CanUpdateAsset:
    permit (UPDATE)
    asset AssetType
    where (participant.mspId == 'Org1MSP')
  

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