Hyperledger Composer业务网络与Fabric网络的差异及部署类比问询

Great question! Let’s break this down clearly to cover both the core differences and the command mapping you’re curious about.

First, let’s clarify the roles and differences between these two layers of the Hyperledger ecosystem:

• Abstraction Level & Core Purpose
  Hyperledger Fabric is the low-level blockchain infrastructure—it handles foundational blockchain mechanics: peer-to-peer communication, consensus protocols (like Raft or Kafka), distributed ledger storage, identity management via CAs, and channel-based data isolation. It’s the "engine" that powers blockchain transactions.
  Hyperledger Composer is a high-level development framework built on top of Fabric. Its whole goal is to simplify building blockchain applications by abstracting away Fabric’s low-level complexities. It lets developers define business logic, data models, and access controls with intuitive tools, no deep expertise in Fabric’s internals required.

• Component Structure
  A Fabric network is made up of core infrastructure pieces: peer nodes, orderer nodes, certificate authorities, channels, chaincode (smart contracts), and the underlying ledger.
  A Composer Business Network (packaged as a .bna file) is a self-contained business logic unit that includes:

  • CTO files (data models for assets, participants, and transactions)
  • ACL files (fine-grained access control rules for different participant roles)
  • Script files (business logic, essentially wrapped Fabric chaincode)
  • Predefined query definitions for ledger data

• Development & Operational Complexity
  Building directly with Fabric requires writing chaincode in Go, Java, or Node.js, managing channel configurations, defining endorsement policies, and handling low-level transaction flow details.
  Composer uses domain-specific languages (DSLs) and pre-built tools (CLI, Playground) to streamline development. You can define business rules without writing raw chaincode, and Composer handles translating your model into Fabric-compatible chaincode under the hood.

• Access Control Implementation
  Fabric enforces access control via channel-level policies and chaincode endorsement policies—powerful, but requiring careful configuration of cryptogen files and channel configs.
  Composer provides a dedicated ACL file that lets you define granular permissions (e.g., "only suppliers can initiate a shipment transaction") in human-readable terms, abstracting away the need to directly edit Fabric policy files.

Your intuition here is exactly right—there’s a direct, one-to-one mapping between Composer’s deployment workflow and Fabric’s chaincode lifecycle commands:

• composer network install → peer chaincode install
  Both commands package and install the business logic onto target peer nodes. For Composer, this takes your .bna file, converts it into a Fabric-compatible chaincode package, and installs it on peers. For raw Fabric, this installs your hand-written chaincode package so it can be instantiated later.

• composer network start → peer chaincode instantiate
  Both commands initialize the installed logic on a specific channel. Composer’s start command instantiates the wrapped chaincode, sets up initial ledger state, applies your defined ACLs, and configures endorsement policies (default or custom). Fabric’s instantiate does the same for raw chaincode—initializing it on the channel and making it ready to process transactions.

Additionally, deploying multiple Composer Business Networks on a Fabric network (single/multi-organization, single/multiple channels) is analogous to deploying multiple independent chaincodes. Each Composer Business Network acts as a separate chaincode instance, with its own isolated state, business logic, and access controls. Just like separate Fabric chaincodes on a channel, they don’t share ledger data unless explicitly configured to do so.

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