Page Comparison

vi

...

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

...

https://github.com/IBM/hlf-internals

https://github.com/IBM/hlf-internals/blob/master/docs/index.md

This documentation is organised into four main sections:

• Overview: this section provides an overview of the architecture and the key design principles adopted by Hyperledger Fabric to implement the execution and management of smart contracts. It discusses the rationale, benefits, and advantage of the approach and it introduces the the key concepts of shim and chaincode stub.
• Interaction Protocol: this section dives into the details of the chaincode-peer interaction protocol and discusses the various phases of the protocol, from the connection establishment to the execution of transactions. It also provides an overview of the messages exchanged and their meaning.
• Shim Architecture: this section dives into the implementation of the fabric chaincode shim, which is the process that hosts the smart contract and interfaces it with the Fabric peer. The section discusses the architecture, design, its key components and the protocol used to interact with the peer. If you want to know how GetState, PutState, GetStateByRange and other methods work look in here.
• Peer Architecture: this section discusses the internal architecture of the peer, its breakdown into subsystems and components. It details how these are involved and participate in the manageemnt of the life-cycle of the chaincode and the execution of transactions. If you want to know what happens when a client submits a transaction proposal, look here.
• Support for New Languages: this section provides an overview of the key components that need to be modified and implemented to enable Hyperledger Fabric with the ability of managing chaincode in another language than Java, Node, or Go. If you want to get to the action and see what takes, jump here.

What You Need To Know

This documentation assumes that the you have a general understanding of Hyperledger Fabric, its key components, and the transaction execution flow, as a user of this platform. If you need a refresh on these concepts, have a look at the Key Concepts section on the Hyperledger Fabric documentation.

Justitia - management and deployment on Fabric networks

...