Go语言Chaincode与Hyperledger Composer BNA文件的差异及Fabric新增Peer节点方法

Let's tackle your two questions one at a time—first, the key differences between Go-written chaincode and Hyperledger Composer's BNA files, then a step-by-step guide to adding a peer node to an existing Hyperledger Fabric network.

Abstraction Level & Target Audience #

• Go chaincode is low-level, direct Fabric smart contract code. It’s built for developers who want full control over every detail of transaction logic, state management, and interaction with Fabric’s core APIs. You’re writing raw Go code that runs directly in the peer’s chaincode container—no middle layers.
• BNA (Business Network Archive) files come from Hyperledger Composer, a high-level framework built on top of Fabric. It’s designed for business analysts or developers who want to model business networks with minimal boilerplate. A BNA packages a domain model (CTO files), transaction logic (JS/TS), access controls, and metadata into a single archive—under the hood, it gets converted to Node.js chaincode when deployed.

Development Workflow #

• For Go chaincode: You write .go files, manage dependencies with go mod, package the code, then use Fabric CLI tools like peer chaincode install and peer chaincode instantiate to deploy. Debugging relies on standard Go tools or Fabric’s chaincode logging.
• For BNA: You use Composer’s tooling (composer-cli) to define your network’s rules and logic, test it locally with composer network start, then package it into a BNA with composer archive create. Deployment is simpler—composer network deploy handles the underlying chaincode installation/instantiation automatically.

Flexibility & Control #

• Go chaincode gives you absolute flexibility. You can directly interact with Fabric’s state database (LevelDB/CouchDB), build complex transaction flows, integrate with external systems via chaincode APIs, and optimize performance down to the line of code.
• BNA simplifies development but adds an abstraction layer. You’re limited to the capabilities exposed by Composer’s API—great for rapid development of standard business networks, but you might hit limits if you need highly custom logic that doesn’t fit Composer’s model.

Underlying Execution #

A critical point: When you deploy a BNA, Composer converts it into a Node.js chaincode that runs on Fabric. So the BNA isn’t a separate runtime—it’s a higher-level way to generate chaincode without writing it from scratch. Go chaincode runs natively as a Go process in the chaincode container, which can offer performance advantages for certain workloads.

Adding a peer requires coordination with your network’s orderers and existing peers to ensure it joins the channel and syncs the ledger. Here’s a practical step-by-step guide:

1. Set Up the New Peer’s Environment

   • Install the exact same version of Fabric binaries and Docker images as your existing network—version mismatches will break compatibility.
   • Create required directories: crypto-config (for MSP certificates), config (channel artifacts), and data (ledger storage).
   • Generate MSP certificates for the new peer using your network’s cryptogen tool or CA server. For simplicity, we’ll assume the peer belongs to the same organization as existing peers (adding a new org requires extra configuration steps).

2. Configure the Peer’s core.yaml

   • Copy the core.yaml from an existing peer in the same org, then update these key fields:
     • peer.id: A unique ID (e.g., peer2.org1.example.com)
     • peer.address: The new peer’s endpoint (e.g., peer2.org1.example.com:7051)
     • peer.gossip.externalEndpoint: If the peer is on a different host, set this to its publicly accessible address
     • fileSystemPath: Path to the new peer’s data directory
   • Ensure the MSP path points to the new peer’s generated certificates.

3. Start the New Peer Container
   Use a Docker command matching your existing peers—adjust image version, ports, and paths to fit your setup:

   docker run -d \
     --name peer2.org1.example.com \
     --network fabric_network \
     -p 8051:7051 \
     -p 8053:7053 \
     -v $(pwd)/crypto-config/peerOrganizations/org1.example.com/peers/peer2.org1.example.com/msp:/etc/hyperledger/fabric/msp \
     -v $(pwd)/crypto-config/peerOrganizations/org1.example.com/peers/peer2.org1.example.com/tls:/etc/hyperledger/fabric/tls \
     -v $(pwd)/data/peer2:/var/hyperledger/production \
     hyperledger/fabric-peer:2.4.9 \
     peer node start
   

4. Join the Peer to the Channel

   • First, fetch the channel’s genesis block from an existing peer or orderer:

     peer channel fetch oldest mychannel.block -o orderer.example.com:7050 -c mychannel --tls --cafile /etc/hyperledger/fabric/orderer/tls/ca.crt
     

   • Join the new peer to the channel using the fetched block:

     peer channel join -b mychannel.block
     

   • Verify the join was successful:

     peer channel list
     

5. Sync the Ledger
   The new peer will automatically sync the ledger from existing peers via Fabric’s gossip protocol. Check the sync status with:

   docker logs peer2.org1.example.com | grep "ledger committed"
   

   Wait until the ledger is fully synced before using the peer for transactions.

6. Update Channel Configuration (If Needed)
   If you’re adding a peer from a new organization, you’ll need to update the channel’s config to include the new org’s MSP. This involves creating a config update transaction, signing it with existing org admins, and submitting it to the orderer. For same-org peers, this step isn’t required.

7. Update Client Connections
   Make sure any client apps or SDKs are updated to include the new peer’s endpoint so they can route transactions to it.

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