Hyperledger Composer与Fabric核心概念关联及隐私维护问询

Great question—let’s break this down step by step, since connecting Composer’s high-level abstractions to Fabric’s core components is crucial to understanding how privacy and access control work under the hood.

First, let’s map Composer’s key concepts directly to Fabric’s foundational components:

• Participants: These align with Fabric’s identities (backed by Membership Service Providers, or MSPs). Each participant is linked to a specific network identity (e.g., a member of an organization), which forms the basis for all permission checks.
• Assets: Assets are the core data objects stored in Fabric’s World State (the ledger’s current immutable state) and logged in the Transaction Log when modified. Composer abstracts raw chaincode interactions, so you don’t have to write low-level code to manage asset creation, updates, or queries.
• Transactions: A Composer transaction is a wrapped chaincode invocation. When you submit a transaction, it triggers your network’s business logic, which interacts with the Fabric ledger—writing to the World State and appending to the Transaction Log via Peer nodes. Orderers still handle ordering these transactions into blocks, just like in vanilla Fabric.
• Business Network Archive (BNA): This is your packaged Composer app, deployed as a chaincode to Fabric Peers within a Channel. The channel itself remains the Fabric construct that isolates ledger data between authorized organizations.

Yes, the permissions.acl file is the primary tool for maintaining transaction and data privacy in a single-channel Composer setup—but it works in tandem with Fabric’s underlying identity and channel model. Here’s how it all comes together:

1. ACL Rules as Granular Gatekeepers:
   The permissions.acl file defines precise rules for who can read/write assets, submit transactions, or access participant data. For example, you could write a rule that only a VehicleOwner can update their vehicle’s ownership status. These rules are enforced at the application level by the Composer chaincode, checking the submitting user’s identity against their participant role before executing any operation.
2. Channel Isolation Still Applies:
   Even in a single-channel setup, Fabric’s channel ensures only organizations joined to the channel can access the ledger data. Composer doesn’t bypass this—your BNA is deployed to a specific channel, so only peers in that channel have the chaincode and associated ledger data.
3. Fine-Grained Data Privacy Within Channels:
   For scenarios where you need privacy inside a channel (like a vehicle lifecycle use case where a repair shop shouldn’t see a vehicle’s financial history), ACLs let you restrict access to specific asset properties or transaction results. For example:
   • A Manufacturer can create a Vehicle and set production details.
   • A Dealer can read production details and update the vehicle’s owner.
   • A RepairShop can only access the vehicle’s VIN and maintenance history, not its purchase price or owner’s personal info—all enforced via ACL rules.
4. Complementary MSP Integration:
   Composer participants are tied to Fabric’s MSP identities, so ACL rules can also reference organizational roles (e.g., org.example.VehicleOwner where the owner is part of the CustomerOrg MSP). This adds another layer of privacy by ensuring only members of specific organizations can perform certain actions.

Let’s make this concrete with a vehicle lifecycle use case:

• Assets: Vehicle (properties: vin, productionDate, purchasePrice, maintenanceHistory, owner)
• Participants: Manufacturer, Dealer, Customer, RepairShop
• Key ACL Rules:
  • Allow Manufacturer to create Vehicle assets.
  • Allow Dealer to read Vehicle assets and update the owner property.
  • Allow Customer to read their own Vehicle’s full details and submit ScheduleMaintenance transactions.
  • Allow RepairShop to read only the vin and maintenanceHistory of vehicles assigned to them, and update the maintenanceHistory post-repair.

In this setup, even though all participants share the same channel, ACLs ensure sensitive data stays restricted to only those who need it—no cross-role data leaks, and no need for multiple channels to enforce this level of privacy.

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