Hyperledger Fabric – the journey of a sample transaction

Now, let's look at the journey of a sample transaction with Hyperledger Fabric, as illustrated in the following diagram. This section will facilitate an understanding of the transaction processing protocol of Fabric:

Figure 2.7: 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 2.0 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:

1. Endorsement of a transaction and checking its validity (validation step): This step includes members of a channel to inspect and adhere to endorsement policies that 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 ledger's version of the read-write set. This validation step is vital as it provides the first step of transaction validation. This check also acts as a gate and prevents the erroneous downstream processing of a transaction, which can be computationally expensive.
2. Ordering through an ordering service: This is a consensus protocol that 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.
3. Validation or transaction commitment: This implies committing a transaction and therefore going through a final set of validations per application-specific trust assumption.

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 contract.
• The endorsing peer is a specialized committing peer that can grant or deny the endorsement of a transaction proposal. The endorsing peer has to hold the smart contract.
• The ordering nodes (service) communicate with the committing and endorsing peer nodes; their main function is to approve the inclusion of transaction blocks into the ledger. Unlike the committing peer and endorsing peers, the ordering nodes do not hold the smart contract or the ledger.

Validation can be divided into two roles, endorsement and ordering:

• Endorsing a transaction means verifying that it obeys a smart contract; endorsers sign the transaction 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 ensures its consistency

What about contract invocation? In a Hyperledger Fabric transaction, simulation (contract execution) and block validation/commit are separate.

There are three phases involved in carrying out a contract operation (in other words, a business transaction) with Hyperledger Fabric:

1. The first phase is contract 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.
2. Next, simulation determines the business transaction proposal, that is, the read-write set, and sends this to the ordering service.
3. A transaction proposal is then ordered with regard to others and broadcasts to committing peers (includes endorsing peers) that 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 service 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 connected to a channel validates the channel-specific delivered blocks and commits them to the ledger

The next section will cover the roles of various actors and services in Hyperledger Fabric's network.