Hyperledger Composer区块验证及交易上链流程咨询

Hey there! Let me break down exactly what happens when you submit a transaction via the Hyperledger Composer API, all the way to that transaction being added to a block on the Fabric blockchain. I’ve walked through this flow plenty of times, so let’s unpack it step by step:

1. Initial Transaction Handling in Composer #

When you send a transaction via Composer’s REST API or SDK, here’s the first round of checks:

• Local Validation: Composer first verifies that your transaction matches the structure defined in your CTO model (correct field types, required values, etc.) and that the submitter has the right permissions per your ACL rules. If this fails, the transaction gets rejected immediately—no trip to the Fabric network.
• Packaging & Forwarding: If validation passes, Composer serializes the transaction into Fabric’s protobuf format, then uses the Fabric SDK to send it to your target peer node(s) (or directly to the orderer, depending on your network config).

2. Fabric Peer Endorsement & Execution #

Once a peer receives the transaction, it kicks off the chaincode execution (remember: Composer runs as a Fabric chaincode under the hood):

• Transaction Execution: The peer runs your Composer script logic (the JavaScript you wrote) against the transaction. This generates a read-write set—a record of all ledger keys the transaction read, and the new values it wants to write/update.
• Endorsement Check: The peer then validates if the transaction meets the chaincode’s endorsement policy (e.g., "needs signatures from 2 different orgs"). If your policy requires multiple endorsements, Composer’s client will collect signatures from all required peers before moving forward.
• Submit to Orderer: Once all necessary endorsements are collected, the client sends the signed transaction (with read-write set) to the Fabric orderer node.

3. Orderer: Transaction Sorting & Block Assembly #

The orderer’s job is to keep the network’s transaction history consistent:

• Ordering: It takes all incoming transactions from across the network and sorts them chronologically (using the consensus mechanism you’ve configured—like Raft or Kafka— to ensure all nodes agree on the order).
• Block Creation: When enough transactions are collected (or a time/block size threshold is hit), the orderer packages the sorted transactions into a new block.

4. Block Validation & Commit to the Blockchain #

The new block is sent to every peer in the network, which runs these critical checks:

• Endorsement Re-validation: Each peer confirms that every transaction in the block has the required endorsements matching the chaincode policy.
• MVCC Check: The peer verifies that the read-write set of each transaction matches the current state of its local ledger. If a transaction tries to read a key that’s been updated by another transaction since the endorsement was collected, it’s marked invalid (prevents double-spends and conflicts).
• Integrity Check: The peer checks the block’s hash to ensure it hasn’t been tampered with during transmission.
• Commit: If all checks pass, the peer appends the block to its local blockchain ledger and updates the world state (the state database like CouchDB/LevelDB) with the write operations from the valid transactions.

Quick Tip for Debugging #

If you want to see this flow in action, check the Fabric container logs:

• Run docker logs <peer-container-name> to see transaction execution, endorsement, and block commit details.
• Orderer logs (docker logs <orderer-container-name>) will show you transaction sorting and block assembly steps.

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