如何将Org3加入Hyperledger Fabric现有SampleConsortium联盟？

Got it, let's walk through exactly how to add Org3 to your existing SampleConsortium in Hyperledger Fabric. Since you mentioned most docs cover adding orgs to channels (not consortiums), I’ll break this down into actionable steps tailored to your setup:

Step 1: Prepare Org3's MSP Definitions #

First, make sure Org3 has a properly set up Membership Service Provider (MSP). If you haven’t already:

• Use Fabric’s cryptogen tool or Fabric CA to generate Org3’s crypto materials (root CA certs, admin certs, TLS certs, etc.).
• Match the directory structure of Org1 and Org2’s MSP folders so the orderer can recognize it consistently.

Step 2: Fetch the Current Orderer System Channel Configuration #

Consortiums are defined in the system channel (the channel that manages the orderer network, usually named orderer-system-channel by default). Pull the latest config block:

osnadmin channel fetch config config_block.pb -o <orderer-ip>:<orderer-port> --ca-file <path-to-orderer-ca-cert> --client-cert <path-to-admin-cert> --client-key <path-to-admin-key> -c system-channel

Convert this protobuf block to a readable JSON file:

configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json

Step 3: Update the Consortium in the Config JSON #

Open config.json and navigate to the consortiums → SampleConsortium → organizations array. Add Org3’s MSP entry, matching the format used for Org1 and Org2:

"organizations": [
    {
        "name": "Org1MSP",
        "id": "Org1MSP",
        "adminPrincipal": "Role.MEMBER",
        "rootCerts": ["/path/to/org1/ca/ca.org1.example.com-cert.pem"],
        "tlsRootCerts": ["/path/to/org1/tls/ca/tlsca.org1.example.com-cert.pem"]
    },
    {
        "name": "Org2MSP",
        "id": "Org2MSP",
        "adminPrincipal": "Role.MEMBER",
        "rootCerts": ["/path/to/org2/ca/ca.org2.example.com-cert.pem"],
        "tlsRootCerts": ["/path/to/org2/tls/ca/tlsca.org2.example.com-cert.pem"]
    },
    {
        "name": "Org3MSP",
        "id": "Org3MSP",
        "adminPrincipal": "Role.MEMBER",
        "rootCerts": ["/path/to/org3/ca/ca.org3.example.com-cert.pem"],
        "tlsRootCerts": ["/path/to/org3/tls/ca/tlsca.org3.example.com-cert.pem"]
    }
]

Double-check that the MSP ID, cert paths, and admin principal match Org3’s actual setup.

Step 4: Generate a Configuration Update Transaction #

We need to create a transaction to apply this config change to the system channel:

1. Make a backup of the original config:

   cp config.json config_original.json
   

2. Encode both config files back to protobuf:

   configtxlator proto_encode --input config_original.json --type common.Config --output config_original.pb
   configtxlator proto_encode --input config.json --type common.Config --output config.pb
   

3. Compute the difference between the original and updated config:

   configtxlator compute_update --channel_id system-channel --original config_original.pb --updated config.pb --output config_update.pb
   

4. Convert the update to a JSON envelope that includes channel metadata:

   configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate | jq . > config_update.json
   echo '{"payload":{"header":{"channel_header":{"channel_id":"system-channel","type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
   

5. Encode the final envelope to protobuf for submission:

   configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output config_update_in_envelope.pb
   

Step 5: Submit the Update to the Orderer #

Use the osnadmin command (recommended for Fabric v2.x+) to submit the config update:

osnadmin channel update -o <orderer-ip>:<orderer-port> --ca-file <path-to-orderer-ca-cert> --client-cert <path-to-admin-cert> --client-key <path-to-admin-key> -c system-channel --config-file config_update_in_envelope.pb

If you’re using an older Fabric version, you can use the peer command instead (from an admin peer node):

peer channel update -f config_update_in_envelope.pb -c system-channel -o <orderer-ip>:<orderer-port> --tls --cafile <path-to-orderer-ca-cert>

Step 6: Verify the Update Worked #

Fetch the updated system channel config and check if Org3 is now part of SampleConsortium:

osnadmin channel fetch config updated_config.pb -o <orderer-ip>:<orderer-port> --ca-file <path-to-orderer-ca-cert> --client-cert <path-to-admin-cert> --client-key <path-to-admin-key> -c system-channel
configtxlator proto_decode --input updated_config.pb --type common.Block | jq .data.data[0].payload.data.config.consortiums.SampleConsortium.organizations

You should see Org3MSP listed alongside Org1MSP and Org2MSP in the output.

Pro Tips #

• Backup First: Always save copies of the original config files before making changes—this lets you roll back if something goes wrong.
• Sync Certificates: If you have a multi-node orderer cluster, ensure Org3’s MSP certs are copied to every orderer node’s MSP directory, otherwise validation will fail.
• Use Fabric v2.x+ Tools: The osnadmin command simplifies config updates compared to the older configtxlator-only workflow, so stick to it if your version supports it.

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