Hyperledger Fabric – the journey of a sample transaction
Now, let's look at the journey of a sample transaction with Hyperledger Fabric. This section will help lay the foundation of Hyperledger Fabric concepts and components in order to facilitate a better understanding of the layers involved in transaction processing:
Hyperledger Fabric walkthrough
Fabric introduces a newly designed blockchain, preserving the transaction processing architecture and aiming at a secure, scalable, resilient, modular, and confidential design. Hyperledger Fabric (at the time of writing this book, the current version is 1.1) supports the execution of distributed applications supporting enterprise-friendly programming models. The components in Hyperledger Fabric provide a modular design, optimally suited for a business network made of various enterprises. Hyperledger Fabric introduces a model based on three steps, an endorse-order-validate architecture, designed for the distributed execution of untrusted code in an untrusted environment. This separation not only allows for provisioning at scale, but also ensures security by separation at every layer.
The transaction flow is separated into three steps, which may be run on different entities in the system:
- Endorsement of a transaction and checking its validity (validation step): This step includes members of a channel to inspect and adhere to endorsement policies which define the acceptable agreed upon approach to validate a transaction proposal. Since peers need to update the ledger ( upon transaction finality) the peers ( that are subscribed to a channel) review the proposal and provide their ledgers version of (R)ead and (W)rite set. This validation step is vital as it provides the first step on transaction validation. This check also acts as a gate and prevents form erroneous downstream processing of transaction, which can be computationally expensive.
- Ordering through an ordering service: This is a consensus protocol which is meant to be pluggable, irrespective of transaction semantics. The pluggability of the consensus provides enterprise and business networks with tremendous flexibility, as there are consensus mechanism considerations for various types of industries, use cases, and interactions between network participants.
- Validation or transaction commitment: This implies committing a transaction and therefore going through a final set of validations per application-specific trust assumptions.
A Hyperledger Fabric transaction involves three types of nodes:
- The committing peer is the node that maintains the ledger and state. The committing peer is the party that commits transactions and may hold the smart contract or chaincode.
- The endorsing peer is a specialized committing peer that can grant or deny endorsement of a transaction proposal. The endorsing peer has to hold the smart contract.
- The ordering nodes (service) communicate with the committing and peer nodes; their main function is to approve the inclusion of transaction blocks into the ledger. Unlike the committing peer and endorsing peer, the ordering nodes do not hold the smart contract or the ledger.
Validation can be pided into two roles, endorsement and ordering:
- Endorsing a transaction means verifying that it obeys a smart contract; endorsers sign the contract to complete this aspect of validation
- Ordering verifies transactions for inclusion in the ledger; this form of validation helps to control what goes in the ledger and ensure its consistency
What about chain code invocation? In a Hyperledger Fabric transaction, simulation (chaincode execution) and block validation/commit are separate.
There are three phases involved in carrying out a chaincode operation (in other words, a business transaction) with Hyperledger Fabric:
- The first phase is chaincode operation execution through simulation on endorsing peers. It's possible to enable parallel simulation on endorsers to help improve concurrency and scalability since simulation won't update the blockchain state.
- Next, simulation determines the business transaction proposal, that is, the read set/write set, and broadcasts this to the ordering service.
- A transaction proposal is then ordered in regard to others and broadcasts to committing peers (includes endorsing peers) who validate that its read set has not been modified since simulation and applies its write set automatically.
Channels are also an important aspect of the transaction journey, since peers exchange messages using consensus by way of channels, and they ensure privacy between different ledgers. The following are a few notes regarding channels:
- They don't have to be connected to by all nodes
- Peers connect to channels through an access control policy
- The ordering services orders a transaction broadcast to a channel
- Peers receive transactions in exactly the same order for a channel
- Transactions are delivered in cryptographically linked blocks
- Every peer validates the delivered blocks and commits them to the ledger