...

We're at an interesting point in blockchain as the both production solutions and new use cases drive the future of blockchain. A mature platform like Hyperledger Fabric scales well and offers the flexiblity to adapt to different use cases. I see significant improvements coming in the architecture strategy for enterprise blockchain that can be delivered smoothly. The improvements will accelerate the integration and value delivered by blockchain for enterprises.

Fabric Features Summary 2023

https://8112310.fs1.hubspotusercontent-na1.net/hubfs/8112310/hyperledger_fabric_whitepaper.pdf

Below are some of the key features of Hyperledger Fabric and what differentiates it from other distributed ledger technologies.

• Permissioned architecture

• Highly modular

• Pluggable consensus

• Open smart contract model — flexibility to implement any desired solution model (account model, UTXO model, structured data, unstructured data, etc)

• Low latency of finality/confirmation

• Flexible approach to data privacy : data isolation using ‘channels’, or share private data on a needto-know basis using private data ‘collections’

• Multi-language smart contract support: Go, Java, Javascript • Support for EVM and Solidity

• Designed for continuous operations, including rolling upgrades and asymmetric version sup-port

• Governance and versioning of smart contracts

• Flexible endorsement model for achieving consensus across required organizations

• Queryable data (key-based queries and JSON queries)

Fabric Blockchain Application Conceptual Architecture

...

After transaction commit completion notification, validate block hashes the same on peers if desired 

Each peer logs its block commit hash every block at INFO level. The block commit hash is a hash over all valid transactions that are written to state database. So you can compare block commit hashes across peers to ensure no fork. Look for a peer INFO message every block containing 'commitHash', e.g.:
commitHash=[0d01cbc2d186675855d5b52f2bda5050ff7238d2527062d0fd5c0a8220d817fa]

Some users do like to validate query results by querying a 2nd peer to ensure they get the same results, that certainly is a valid pattern for critical applications.

Related upcoming work:
https://jira.hyperledger.org/browse/FAB-106 - A 'checkpoint' feature will allow peers to bootstrap a channel from a known good state without having to process all prior blocks since genesis block. The feature can also be used to compare global state across peers.
https://jira.hyperledger.org/browse/FAB-33 - BFT for ordering service to ensure a sufficient number of ordering service nodes sign off on blocks.

We will socialize RFCs for these proposed work items once they become available.


Thanks,

Dave Enyeart

...