Hyperledger Fabric for Dummies

A Blockchain Platform for the Enterprise

Good afternoon, dear readers, my name is Nikolay Nefedov, I am an IBM technical specialist, in this article I would like to introduce you to the blockchain platform - Hyperledger Fabric. The platform is designed to build enterprise-level business applications (Enterprise class). The level of the article is for unprepared readers with basic knowledge of IT technologies.

Hyperledger Fabric is an open-source project, one of the branches of the open project Hyperledger, a consortium of Linux Foundation. Hyperledger Fabric was originally launched by Digital Assets and IBM. The main feature of the platform Hyperledger Fabric is focused on corporate use. Therefore, the platform was designed to ensure high speed of transactions and their low cost, as well as the identification of all participants. These benefits are achieved through the separation of the transaction verification service and the formation of new blocks of a distributed registry, as well as the use of a certification authority and authorization of participants.

My article is part of a series of articles on Hyperledger Fabric in which we describe the design of a system for accounting for students entering a university.

Hyperledger Fabric overall architecture

Hyperledger Fabric is a distributed blockchain network consisting of various functional components that are installed on network nodes. The components of the Hyperledger Fabric are Docker containers, which can be freely downloaded from the DockerHub. Hyperledger Fabric can also be run in a Kubernetes environment.

We used Golang to write smart contracts (chaincode in the context of Hyperledger Fabric) (although Hyperledger Fabric allows other languages ​​to be used). In our case, Node.js with the corresponding Hyperledger Fabric SDK was used to develop a custom application.

The nodes run business logic (smart contract) - chaincode, stores the state of the distributed registry (ledger data), and performs other system services of the platform. A node is only a logical unit, different nodes can exist on the same physical server. Much more important is how the nodes are grouped (Trusted domain) and what functions of the blockchain network they are associated with.

The overall architecture is as follows:

Picture 1. General Hyperledger Fabric Architecture

User application (Submitting Client) - an application with which users work with the blockchain network. To work, you must pass authorization and have the appropriate rights to various actions in the network.

Peers (Nodes) come in several roles:

• Endorsing Peer is a node that simulates the execution of a transaction (executes a smart contract code). After the verification and execution of the smart contract is completed, the node returns the results of the execution to the client application along with its signature.
• Ordering Service - a distributed service on several nodes; it is used to form new blocks of a distributed registry and create a sequence for the execution of transactions. Ordering Service does not add new blocks to the registry (For better performance, this function has been moved to Committing Peers).
• Committing Peer is the node that contains the distributed registry and adds new blocks to the registry (which were formed by the Ordering Service). All Committing Peers contain a local copy of the distributed registry. Committing Peer before local adding of a new block checks all transactions inside the block for validity.

Endorsement Policy is a validation policy for a transaction. These policies determine the required set of nodes on which a smart contract must be executed in order for a transaction to be recognized as valid.

The Distributed Registry - Lerger - consists of two parts: WolrldState (also called State DataBase) and BlockChain.

BlockChain is a chain of blocks that keeps records of all changes that have occurred to objects of the distributed registry.

WolrldState is a distributed registry component that stores the current (extreme) values ​​of all distributed registry objects.

WorldState is a database, in the base case - LevelDB or more complex - CouchDB, which contains key-value pairs, for example: Name - Ivan, Last Name - Ivanov, system registration date - 12.12.21, date of birth - 12.17.1961, etc. WorldState and the distributed registry must be consistent across all members of this channel.

Since the Hyperledger Fabric is a network in which all participants are known and authenticated, it uses a dedicated certification authority - CA (Certification Authority). CA works on the basis of the X.509 standard and public key infrastructure - PKI.

Membership Service is a service through which members verify that an object belongs to a particular organization or channel.

A transaction - in most cases, is a record of new data in a distributed registry.

There are also transactions to create channels or smart contracts. The transaction is initiated by the user application and ends with writing to the distributed registry.

Channel (Channel) - is a closed subnet, consisting of two or more participants of the blockchain network, designed to conduct confidential transactions within a limited, but known, group of participants. The channel is determined by the participants, their distributed registry, smart contracts, Ordering Service, WorldState. Each channel participant must be authorized to access the channel and have the right to perform various types of transactions. Authorization is performed using the Membership Service.

Typical transaction execution scenario

Further I would like to tell about the typical scenario of transaction performance on the example of our project.

As part of our internal project, we have created a Hyperledger Fabric network, which is designed to register and account for students entering universities. Our network consists of two organizations belonging to University A and University B. Each organization contains a client application, as well as its Committing and Endorsing Peer. We also use the general services Ordering Service, Memebership Service and Certification Authority.

1) Transaction Initiation

The user application, using the Hyperledger Fabric SDK, initiates a transaction request and sends a request to the nodes with smart contracts. A request may be for changing or reading from a distributed registry (Ledger). If we consider an example of our test system configuration for accounting for university students, the client application sends a transaction request to the universities A and B, which are included in the Endorsement policy of the called smart contract. Node A is a node that is located at the university, which registers an incoming student, and node B is a node that is located at another university. In order for the transaction to be saved to a distributed registry, it is necessary that all nodes that, according to business logic, must approve the transaction, successfully execute smart contracts with the same result. The user application of node A, using the tools of the Hyperledger Fabric SDK, gets an Endorsement policy and finds out which nodes need to send a transaction request. This is a request to call (invoke) a specific smart contract (chaincode function) to read or write certain data to a distributed registry. Technically, the client SDK uses the corresponding function, the API of which passes a certain object with transaction parameters, and also adds a client signature and sends this data via protocol buffer over gRPC to the corresponding nodes (endorsing peers).

Picture 2. Transaction Initiation

2) Execution of a smart contract

The nodes (Endorsing Peers), after receiving a request to conduct a transaction, check the client's signature and, if everything is in order, then take the object with the request data and start the simulation of the smart contract execution (chaincode function) with this data. A smart contract is a business logic of a transaction, a specific set of conditions and instructions (in our case, this is a student's check, a new one is a student, or he is already registered, an age check, etc.). To execute a smart contract, you also need data from WorldState. As a result of the simulation of a smart contract for Endorsing peer, two sets of data are obtained - Read Set and Write Set. Read Set and Write Set are the original and new WorldState values. (new - in the sense obtained when simulating a smart contract).

Picture 3. Execution of a smart contract

3) Return data to the client application

After the simulation of the smart contract, Endorsing Peers returns the initial data and the simulation result to the client application, as well as the RW Set, signed with their certificate. At this stage, no changes are made to the distributed registry. The client application verifies the Endorsing Peer signature, and also compares the original transaction data that was sent and the data that returned (that is, it checks if the original data was not distorted over which the transaction was simulated). If the transaction was only for reading data from the registry, then the client application receives the required Read Set, respectively, and this usually completes the transaction without changing the distributed registry. In the case of a transaction that is supposed to change the data in the registry, the client application additionally checks the execution of the Endorsing policy. It is possible that the client application does not check the result of the Endorsement Policy, but the Hyperledger Fabric platform in this case provides for checking the policies on the nodes (Comitting Peers) at the stage of adding a transaction to the registry.

Picture 4. Returning data to the client application

4) Sending RW sets to Ordering Peers

The client application sends the transaction along with the accompanying data to the Ordering service. This includes the RW Set, Endorsing peers signatures, as well as the Channel ID.

Ordering service - based on the name, the main function of this service is to build incoming transactions in the correct order. As well as the formation of a new block of the distributed registry and guaranteed delivery of the newly formed blocks to all Commiting nodes, thus ensuring the consistency of the data on all nodes containing the distributed registry (Commiting peers). At the same time, the Ordering service itself does not change the registry. Ordering Service is a vital component of the system, so it is a cluster of several nodes. The Ordering Service does not check a transaction for validity, it simply accepts a transaction with a specific channel identifier, builds incoming transactions in a specific order, and forms new blocks of the distributed registry from them. One Ordering Service can serve several channels simultaneously. The Ordering Service includes a Kafka cluster, which maintains the correct (unchanged) transaction queue (see clause 7).

Picture 5. Sending RW sets to Ordering Peers

5) Sending formed blocks to Committing Peer

The blocks formed in the Ordering Service are transmitted (broadcast) to all nodes on the network. Each node, having received a new block, checks it for compliance with the Endorsing Policy, checks that all Endorsing Peers received the same result (Write Set) as a result of the smart contract simulation, and also checks whether the original values ​​have changed (i.e., Read Set - data read by a smart contract from WorldState) since the transaction was initiated. If all conditions are met - the transaction is marked valid, otherwise, the transaction receives the status is not valid.

Picture 6. Sending formed blocks to Committing Peer

6) Adding a block to the registry

Each node adds a transaction to its local copy of the distributed registry, while, if the transaction is valid, then the Write Set is applied to the WorldState (current state), respectively, new values ​​of the objects affected by the transaction are recorded. If the transaction received a token - not valid (for example, two transactions occurred with the same objects within one block, then one of the transactions will not be valid, since the original values ​​have already been changed by another transaction). This transaction is also added to the distributed registry with a non-valid token, but the Write Set of this transaction does not apply to the current state of the WorldState and, accordingly, does not change the objects involved in the transaction. After that, a notification is sent to the user application that a transaction has been added to the distributed registry for all eternity, as well as the status of the transaction, that is, whether it is valid or not ...

Picture 7. Adding a block to the registry

ORDERING SERVICE

Ordering Service consists of a Kafka cluster with corresponding ZooKeeper nodes and Ordering Service Nodes (OSN), which are between the clients of the Ordering service and the Kafka Cluster. The Kafka cluster is a distributed, fault-tolerant flow (messaging) platform. Each channel (topic) in Kafka is an unchangeable sequence of records that only supports adding a new record (deleting an existing one is impossible). An illustration of the structure of the topic is shown below. It is this property of Kafka that is used to build the blockchain platform.

taken from kafka.apache.org

• Picture 8. Ordering Service Topic Structure *

Useful links

Youtube - Building a blockchain for business with the Hyperledger Project

Hyperledger Fabric Docs

Hyperledger fabric: blockchains

Thanks

I express my deep gratitude for the help in the preparation of the article to my colleagues:

Nikolay Marina

Igor Hapov

Dmitry Gorbachev

Alexandra Zemtsova

Ekaterina Guseva