Hyperledger Composer与Fabric相关技术疑问咨询

Hey there! Let's walk through each of your questions with clear, practical explanations:

1. Do queries in the REST server get restricted by .acl files? #

Absolutely. Every operation through the Composer REST server—including queries—enforces the access control rules defined in your .acl file.

For example, if you have a rule like:

rule AllowAssetReadByOwner {
    description: "Allow asset owners to read their assets"
    participant: "net.mynetwork.Owner"
    operation: READ
    resource: "net.mynetwork.Asset"
    condition: (resource.owner.getIdentifier() == participant.getIdentifier())
}

An authenticated participant who isn't the owner of an asset will get a permission denied error if they try to query that asset via the REST API. The REST server uses the identity from the connected business network card to enforce these rules automatically.

2. Do .acl rules restrict which transactions a participant can submit—including transactions that create new participants? #

Yes, ACL rules control both who can submit a transaction and what operations that transaction can perform.

Let's say you have a transaction CreateNewParticipantTx that creates a new participant, and your ACL denies participantA the CREATE permission on participant resources. Even if participantA is allowed to submit CreateNewParticipantTx, the transaction will fail during execution. The ACL checker runs against every operation the transaction performs, so creating a new participant (a CREATE operation on a participant resource) will trigger the rule and block the transaction.

You need to explicitly grant the necessary permissions (like CREATE on participants) to participantA if you want that transaction to succeed for them.

3. Can I create business network cards via the REST API? #

The out-of-the-box Composer REST server doesn't include a built-in endpoint to create or issue cards directly. But you have two solid workarounds:

• Extend the REST server: Use LoopBack's custom endpoint feature to add a new API route that calls Composer's JavaScript API under the hood. You can write code to create a new identity for a participant, generate a business network card, and even return the card data for the user to import into their wallet.
• Pre-create identities via CLI/JS API: First, use the composer identity issue command or Composer's JS API to create an identity and card for the new participant. Then you can share the card file or its details with the user, who can import it into their wallet to access the REST server.

Remember: The REST server relies on business network cards for authentication, so any new user needs a valid card to connect.

4. What happens when PeerAdmin upgrades a node to a new version? Do other nodes auto-upgrade? And why the time difference between local deployment upgrades vs browser operations? #

Let's break this down:

• Node upgrades: When you run composer network upgrade (or the equivalent Fabric chaincode upgrade), you're upgrading the business network chaincode on a specific peer node. Other nodes will NOT auto-upgrade—you have to run the upgrade command for each peer in your network individually. This ensures you can roll out upgrades gradually if needed.
• Time difference explained:
  • Local deployment upgrades (real Fabric network) involve multiple steps: packaging the new chaincode, sending it to the ordering service, getting consensus from peers, installing the chaincode on each target peer, and instantiating it. All these steps require network communication and consensus, which takes 2-4 minutes.
  • Browser operations (like Composer Playground's local mode) run on an in-memory "mock" Fabric network. There's no real peer-to-peer communication or consensus—everything happens locally in your browser. That's why it only takes 3-4 seconds; it's simulating the network, not interacting with a real one.

5. Can Hyperledger Fabric store some ledger data privately (or encrypted) in a private network, with external networks only storing hashes? And what about transactions involving this data? #

Yes, Fabric has a feature called Private Data Collections (PDCs) that does exactly this:

• You can define a collection of data that's only stored on a specific subset of peer nodes (your private network peers). Peers outside this subset will only receive a hash of the private data, not the actual content. This hash is stored on the main ledger to maintain integrity without exposing sensitive data.
• For transactions involving private data: Only the peers in the authorized collection will execute the full transaction (accessing the private data). External peers will only process the public parts of the transaction and verify the hash of the private data. The private transaction details never leave the authorized peer subset.

This is perfect for scenarios where you need to keep sensitive data (like trade secrets or personal info) restricted to a group of participants while still maintaining a shared public ledger for non-sensitive data.

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