如何在Hyperledger Composer中展示账本记录的不可变性

Great question! Let's break this down step by step since immutability is a core pillar of blockchain, and Hyperledger Composer (built on Hyperledger Fabric) leans into this in a few key ways.

Hyperledger Composer doesn't reinvent the wheel here—it relies entirely on Hyperledger Fabric's hash-linked blockchain structure to enforce immutability. Here's how it works:

• Every block in the Fabric ledger contains a batch of transactions, and the hash of each block includes the hash of the previous block. This creates an unbroken chain: if anyone tries to alter a single transaction in an old block, the block's hash changes, which breaks the hash link with all subsequent blocks.
• Every node in the network validates these block hashes during sync. Tampered data will immediately fail this validation and be rejected by the network.

To visualize this in Composer:

• Use the Composer CLI: Run composer history list <asset-type> <asset-id> to pull the full history of an asset. Each entry ties a change to a transaction ID, which maps directly to a Fabric block.
• Use the enabled Historian REST endpoint: When generating your Composer REST server, enable historian support. Querying /Historian will show all transactions, each with a transactionId you can cross-verify against Fabric's block structure.

The Historian in Composer is a system asset that mirrors the transaction history stored in the underlying Fabric ledger—it's not a separate, editable database. Here's why you can't modify it:

• Composer explicitly protects system assets like the Historian from direct updates. Any attempt to edit a Historian entry via the API or custom scripts will be blocked.
• Even if you somehow tamper with local Historian data on a single node, Fabric's consensus mechanism will catch it. When nodes sync, they validate block hashes, so the tampered node's data won't match the rest of the network and will be forced to revert to the correct ledger state.

This inability to alter Historian entries is actually proof of immutability—you can't rewrite transaction history because it's anchored to the hash-linked blockchain.

If modifying the Historian isn't feasible, here are practical, hands-on ways to demonstrate the ledger's append-only nature:

• Validate the block hash chain: Use Fabric's peer channel fetch command to download blocks (e.g., peer channel fetch oldest mychannel.block -c mychannel -o <orderer-url>). Inspect each block's header: the previous_hash field will exactly match the data_hash of the prior block. Any tampering would break this match.
• Audit asset history: Use Composer's assetRegistry.getHistory(assetId) method (in a transaction function or script) to retrieve all past versions of an asset. You'll see every change is tied to a transaction, and none of these entries can be deleted or edited—you can only add new versions via new transactions.
• Test network consensus: Tamper with a local ledger copy (e.g., edit a key-value in the Fabric state database on one node). Query the asset history from another node, and you'll see the tampered node's data doesn't match the network consensus. The node will eventually sync back to the correct state because hash chain validation fails.
• Trace transaction blocks: Take a transactionId from the Historian and use Fabric tools to look up the corresponding block. The block's data includes the transaction's payload, and its hash is part of the chain—you can't alter this payload without breaking the entire chain.

内容的提问来源于stack exchange，提问作者Sai Prannav Krishna