Lately, at SOUTHWORKS, we have been working with several Blockchain platforms. This time the turn came up for Hyperledger Fabric, for which we crafted a scenario around the Healthcare Industry that we will share with you in another article.

In order to better understand some of the basic concepts that are used, but will not be described in that article, we want to introduce first a couple of things you should know.

* In addition, if you want to learn other concepts of the Blockchain and Smart Contracts world you can read this article which has other common basic concepts that are referred when talking about these technologies.

‍

Hyperledger Fabric Service

Hyperledger Fabric is a platform for distributed ledger solutions. It delivers confidentiality, resiliency, flexibility, and scalability. Its main distinction from alternative blockchain solutions is that it delivers a uniquely elastic and extensible architecture by supporting pluggable implementations of different components. Hyperledger Fabric delivers the following blockchain network functionalities:

• Privacy and confidentiality: Hyperledger Fabric provides restricted messaging paths called channels, these channels can be used to deliver transaction privacy and confidentiality for specific subsets of network members. All data on a channel, including transaction, member and channel information are inaccessible to any network members without permission to access that channel. This feature allows businesses with competing interests to coexist on the same permissioned network.
• Efficient processing: To provide concurrency and parallelism to the network, transaction execution is separated from transaction ordering and commitment. Nodes in the network have a role that corresponds to one of these actions based on their node type. This concurrent execution increases processing efficiency on each peer and accelerates delivery of transactions.
• Chaincode functionality: Chaincode programs are the equivalent of Smart Contracts in decentralized platforms like Ethereum. Chaincode is used to encode assets (real life object representations) and the transaction instructions (business logic) for modifying these assets. Chaincode that defines parameters for a change of asset ownership, for example, ensures that all transactions that transfer ownership are subject to the same rules and requirements.
• Modular design: Hyperledger Fabric implements a modular architecture to provide functional choice to network designers. Specific algorithms for identity, ordering (consensus) and encryption, for example, can be plugged in to any Hyperledger Fabric network.

‍

Key Concepts

Ledger

Ledgers in the Hyperledger Fabric network have two main purposes, to present the current value of a set of ledger states, and to capture the history of the transactions that determined these states. The ledger does not record business objects, it stores facts about the current state of an object, and facts about the history of transactions that led to the current state.

Then, the database consists of two related components:

• World state: Database that holds a cache of the current values of a set of ledger states. This world state allows fast and easy access to the current value of a state, instead of having to calculate it through the entire transaction log. Hyperledger lets you choose among many, although one common used component for this is CouchDB, as it provides states structured as JSON documents.
• Blockchain: Transaction log that records all the changes that resulted in the current world state.

‍

‍

The world state can be queried by applications to quickly retrieve objects with certain attributes. On the other hand, when an application invokes a transaction that modifies the current world state, the transaction process (explained in the transaction workflow section below) will begin in order to update the blockchain.

‍

Peer

Peers are the fundamental element of the blockchain network, they are the nodes responsible of hosting the ledgers and smart contracts. They are the entry-point of every application interaction with the network, trough the peers the applications can execute chaincodes (smart contracts) to either query or update the ledger.

‍

‍

Each peer on the network is assigned a digital certificate, which will identify him in the different channels he connects to. By this method, a peer could have different permission rights on each channel.

While all peers are the same, they can assume multiple roles on the network. Based on that, the peers can be classified in two major types:

• Committing peer: Every peer node in a channel is a committing peer. It receives the blocks of generated transactions and, after they are validated by the network, the commit it to their own copy of the ledger as an append operation.
• Endorsing peer: Every peer with a smart contract can be and endorsing peer, if it has a smart contract installed. To be an endorsing peer the contract must be used by an application to generate a digitally signed transaction response (participating in the transaction endorsement flow).

‍

Channel

A Hyperledger Fabric channel is a private subnet of communication between two or more specific network members, with the purpose of conducting private and confidential transactions.

A channel is defined by members (orgs), the shared ledger, chaincode applications and the ordering service node(s). Every transaction on the network is executed on a channel, where each party must be authenticated and authorized to transact on that channel. Each peer that joins a channel, has its own identity given by a Membership Service Provider (MSP), which authenticates each peer to its channel peers and services.

‍

Smart Contracts and Chaincode

A smart contract defines the executable logic that generates new facts that are added to the ledger. Even though the term smart contract and chaincode are usually used interchangeably, in general, a smart contract defines the transaction logic that controls the lifecycle of a business object contained in the world state. Whereas a chaincode is a set of smart contracts that are packaged for deployment to a blockchain network.

Deploying a chaincode to a network makes all its smart contracts available to the organizations in that network. This means that only administrators need to worry about chaincode; everyone else can think in terms of smart contracts.

‍

Endorsement

Every chaincode has an associated endorsement policy that applies to all the smarts contracts defined within it. This policy indicates which organizations in a blockchain network must sign a transaction generated by a given smart contract in order for that transaction to be declared valid.

‍

Valid transaction

Smart contracts run on a peer node owned by an organization in the blockchain network. These contracts take a set of input parameters called the transaction proposal and uses them in combination with its program logic to read and write the ledger. Changes to the world state are captured as a transaction proposal response which contains a read-write set with both the states that have been read, and the new states that are to be written if the transaction is valid. The world state is not updated when the smart contract is executed, it is finally updated when the transaction is validated.

A transaction that is distributed to all peer nodes in the network is validated in two phases. Firstly, the transaction is checked to ensure it has been signed by the specified organizations according to the endorsement policy. Secondly, it is checked that the current value of the world state matches the read set of the transaction when it was signed by the endorsing peer nodes. If a transaction passes both these tests, it is marked as valid.

Both valid and invalid transactions are added to the blockchain history, but only valid transactions result in an update to the world state.

‍

Ordering Service

In the Hyperledger Fabric networks there is another kind of node called orderer, who oversees the “transaction ordering” and building the final block of transactions, before they are sent to be committed in each peer’s ledger. The Ordering Service is composed of a group of orderer nodes.

The Ordering Service nodes receive transactions from many applications after the endorsement flow occurred and its job is to arrange batches of these transactions into a well-defined sequence and package them into the final block.

Besides their ordering role, the orderers also maintain the “consortium” list, that consist of the list of organizations that can create channels and are in charge of enforcing basic access control for the channels.

‍

Network Authentication

The different entities in a blockchain network include peers, orderers, client applications, administrators. Each of these entities must have a digital identity encapsulated in an X.509 digital certificate. These identities represent a very important component in the authentication process because they determine the exact permissions over resources and access to information that entities have in the network.

‍

Digital Certificates

Digital certificates hold a set of attributes relating to the holder of the certificate, which allows the encoding of a party’s identifying details in its structure. These attributes are recorded using cryptography so that tampering will invalidate the certificate. Additionally, certificates are related with a pair of public-private keys that belong to their holder.

The certificate’s authentication comes in the form of a digital signature which is produced using the certificate’s holder private key. Recipients of digitally signed messages can verify the origin and integrity of a received message by checking that the attached signature is valid under the public key of the expected sender.

Every time an actor wants to interact with the Hyperledger network, it will need to access its digital certificate and sign the transaction with the private key.

‍

Certificate Authority (CA)

For digital certificates to be trusted by the Hyperledger Fabric network, they must be issued by a Certificate Authority (a trusted third-party organization that issues digital certificates).

It is because CAs are so important that Fabric provides a built-in CA component to allow you to create CAs in the blockchain networks you form. This component known as Fabric CA is a private root CA provider capable of managing digital identities of Fabric participants that have the form of X.509 certificates.

‍

Membership Service Provider

While Certificate Authorities are used to ensure that network entities are authenticated, not all certificates issued by a CA are valid in the network. Membership Service Providers add another layer of authentication, they are used to define which identities are allowed to operate.

The implementation of the MSP requirement is a set of folders that are added to the configuration of the network and are used to define an organization both inwardly (organizations decide who its admins are) and outwardly (by allowing other organizations to validate that entities have the authority to do what they are attempting to do). Whereas Certificate Authorities generate the certificates that represent identities, the MSP contains a list of permissioned identities.

‍

Transaction Workflow

The transaction workflow in an Hyperledger Fabric network can be divided as 3 mayor phases.

Phase 1 — Proposal

In the first phase, a client application sends a transaction proposal to the required set of peers for endorsement. Each of these peers (taking the role of endorsing peers) execute a chaincode using the transaction proposal to generate a transaction proposal response, after validating and signing the incoming proposal.

‍

‍

Once the application has received back enough signed proposals (depending on the requisite specified on the endorsement policy) the first phase is complete.

‍

‍

Phase 2 — Ordering and packaging transactions into blocks

In this phase, application clients submit transactions, containing endorsed transaction proposal responses, to an ordering service node. Then the ordering service nodes work together to collectively define a well-defined sequence and package them in the next block to be appended to the blockchain.

This phase finishes with the blocks being saved to the orderers’ own ledgers and afterwards broadcasting the block to all the peers connected.

‍

‍

Phase 3 — Validation and commit

This phase begins with the orderers distributing the blocks to all the peers connected to them. Each peer will process this block independently, but in exactly the same way as every other peer on the channel, assuring the consistency of the ledger. Now the peers will validate the transaction has been endorsed and complies with the endorsement policy (like the application has done in Phase 1).

‍

‍

After validating the endorsement of the transaction, and also that the current state of the ledger is compatible with the state when the proposed update was generated, it finally commits and updates its copies of the ledger.

Finally, this phase concludes with the block events generated by the peers, events to which the application can subscribe to, to get informed of the transaction being committed to the ledger.

‍

‍

* Source of references https://hyperledger-fabric.readthedocs.io/

‍

Originally published by Mauro Krikorian for SOUTHWORKS on Medium 03 May 2021

‍