A Blockchain Platform for the Enterprise
Good afternoon, dear readers, my name is Nikolai 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 intended for building 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 Hyperledger open source project, a consortium of the Linux Foundation. Hyperledger Fabric was originally launched by Digital Assets and IBM. The main feature of the Hyperledger Fabric platform is its focus on corporate applications. Therefore, the platform was developed taking into account the high speed of transactions and their low cost, as well as the identification of all participants. These benefits are achieved by separating the transaction verification service and forming new blocks of the distributed registry, as well as using a certificate authority and authorizing participants.
My article is part of a series of articles about Hyperledger Fabric in which we describe the project of a system for registering students entering a university.
General architecture of Hyperledger Fabric
Hyperledger Fabric is a distributed blockchain network consisting of various functional components that are installed on network nodes. Hyperledger Fabric components are Docker containers that can be freely downloaded from DockerHub. Hyperledger Fabric can also be run in a Kubernetes environment.
To write smart contracts (chaincode in the context of Hyperledger Fabric), we used Golang (although Hyperledger Fabric allows you to use other languages). To develop a custom application, in our case, Node.js was used with the corresponding Hyperledger Fabric SDK.
The nodes run business logic (smart contract) – chaincode, store the state of the distributed registry (ledger data) and execute other platform system services. 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 general architecture looks like this:
Picture 1. General Architecture of Hyperledger Fabric
User application (Submitting Client) is an application with which users work with the blockchain network. To work, you need to go through authorization and have the appropriate rights for various kinds of actions on the network.
Peers (Nodes) come in several roles:
- Endorsing Peer is a node that simulates the execution of a transaction (executes the smart contract code). After validating and executing the smart contract, the node returns the execution results to the client application along with its signature.
- Ordering Service is a distributed service on several nodes, it is used to form new blocks of the distributed ledger and create a sequence for executing transactions. Ordering Service does not add new blocks to the registry (Moved to Committing Peers for better performance).
- Committing Peer - a node that contains a 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 ledger. The Committing Peer, before adding a new block locally, checks all transactions within the block for validity.
Endorsement Policy is a policy for checking a transaction for validity. These policies define the necessary set of nodes on which the smart contract must be executed in order for the 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 stores records of all changes that have occurred to distributed ledger objects.
WolrldState is a distributed registry component that stores the current (extreme) values of all distributed registry objects.
WorldState is a database, in the basic version - LevelDB or more complex - CouchDB, which contains key-value pairs, for example: First name - Ivan, Surname - Ivanov, registration date in the system - 12.12.21/17.12.1961/XNUMX, date of birth - XNUMX/XNUMX/XNUMX, etc. WorldState and the distributed ledger must be consistent across all members of a given channel.
Since Hyperledger Fabric is a network in which all participants are known and authenticated, a dedicated certification authority is used here - CA (Certification Authority). CA operates 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 is, in most cases, a record of new data in a distributed ledger.
There are also transactions for the creation of channels or smart contracts. The transaction is initiated by the user application and ends with a write to the distributed ledger.
Channel (Channel) is a closed subnet consisting of two or more participants in the blockchain network, designed to conduct confidential transactions within a limited, but known, circle of participants. The channel is determined by the participants, its distributed ledger, smart contracts, Ordering Service, WorldState. Each channel member must be authorized to access the channel and have the right to perform various kinds of transactions. Authorization is performed using the Membership Service.
Typical transaction execution scenario
Next, I would like to talk about a typical scenario for executing a transaction using the example of our project.
As part of our internal project, we have created a Hyperledger Fabric network, which is designed to register and record students entering universities. Our network consists of two organizations, owned by University A and University B. Each organization contains a client application, as well as its own Committing and Endorsing Peer. We also use the common Ordering Service, Memebership Service and Certification Authority services.
1) Transaction Initiation
The user application, using the Hyperledger Fabric SDK, initiates a transaction request and sends the request to nodes with smart contracts. The request can be to change or read from a distributed ledger (Ledger). If we consider an example of our test configuration of the system for accounting for university students, then the client application sends a transaction request to the nodes of universities A and B, which are included in the Endorsement policy of the called smart contract. Node A is a node that is located in the university that registers an incoming student, and node B is a node that is located in another university. In order for a transaction to be saved to a distributed ledger, it is necessary that all nodes that, according to the business logic, must approve the transaction, successfully execute smart contracts with the same result. The user application of node A, using the Hyperledger Fabric SDK tools, receives the Endorsement policy (approval policy) and finds out which nodes to send a transaction request to. This is a request to call (invoke) a certain smart contract (chaincode function) in order to read or write certain data to the distributed ledger. Technically, the client SDK uses the corresponding function, the API of which is passed an object with transaction parameters, and also adds a client signature and sends this data via protocol buffer over gRPC to the appropriate nodes (endorsing peers).
Picture 2. Transaction Initiation
2) Smart contract execution
Nodes (Endorsing Peers), having received a request to conduct a transaction, check the client signature and if everything is in order, then they take an object with the request data and run a simulation of the execution of a smart contract (chaincode function) with these data. A smart contract is the business logic of a transaction, a certain set of conditions and instructions (in our case, this is a student check, is it a new student, or is he already registered, age check, etc.). To execute a smart contract, you will also need data from WorldState. As a result of the smart contract simulation on the Endorsing peer, two data sets are obtained - Read Set and Write Set. Read Set and Write Set are the original and new WorldState values. (new - in the sense obtained by simulating a smart contract).
Picture 3. Smart contract execution
3) Returning data to the client application
After the simulation of the smart contract, Endorsing Peers return to the client application the initial data and the result of the simulation, as well as the RW Set signed by their certificate. At this stage, there are no changes in the distributed ledger. The client application verifies the signature of the Endorsing Peer, and also compares the original transaction data that was sent and the data that returned (that is, it checks whether the original data on which the transaction was simulated has been corrupted). If the transaction was only for reading data from the registry, then the client application accordingly receives the necessary Read Set, and on this the transaction usually completes successfully without changing the distributed registry. In the case of a transaction that should change the data in the registry, the client application additionally checks whether the Endorsing policy has been implemented. It is possible that the client application does not check the result of the Endorsement Policy execution, 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 related data to the Ordering service. This includes the RW Set, signatures of Endorsing peers, and 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 the guaranteed delivery of new generated blocks to all Commiting nodes, thus ensuring data consistency on all nodes containing the distributed registry (Committing peers). At the same time, the Ordering service itself does not change the registry in any way. Ordering Service is a vital component of the system, so it is a cluster of several nodes. The Ordering Service does not check the transaction for validity, it simply accepts a transaction with a specific channel ID, arranges incoming transactions in a specific order, and forms new blocks of the distributed ledger from them. One Ordering Service can serve several channels at the same time. The Ordering Service includes a Kafka cluster, which maintains the correct (unchanged) transaction queue (see point 7).
Picture 5. Sending RW sets to Ordering Peers
5) Sending the generated blocks to the Committing Peer
The blocks formed in the Ordering Service are broadcasted to all network nodes. 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 if the original values have changed (that is, - Read Set - data read by the smart contract from WorldState) since the initiation of the transaction. If all conditions are met, the transaction is marked as valid, otherwise, the transaction receives the status of not valid.
Picture 6. Sending generated blocks to the Committing Peer
6) Adding a block to the registry
Each node adds a transaction to its local copy of the distributed ledger, and if the transaction is valid, then Write Set is applied to the WorldState (current state), respectively, new values of objects that were affected by the transaction are written. If a transaction received a token that was not valid (for example, there were two transactions with the same objects within the same 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 ledger with a invalid marker, but the Write Set of this transaction does not apply to the current state of the WorldState and, accordingly, does not change the objects participating in the transaction. After that, a notification is sent to the user application that the transaction has been added to the distributed ledger forever, 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
The Ordering Service consists of a Kafka cluster with corresponding ZooKeeper nodes and an Ordering Service Nodes (OSN) that sit between the Ordering service clients and the Kafka Cluster. Kafka cluster is a distributed, fault-tolerant flow (message) management platform. Each channel (topic) in Kafka is an immutable sequence of records that only supports adding a new record (deleting an existing one is not possible). An illustration of the topic structure is given 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
Acknowledgements
I express my deep gratitude to my colleagues for their help in preparing the article:
Nikolai Marina
Igor Khapov
Dmitry Gorbachev
Alexander Zemtsov
Ekaterina Guseva
Source: habr.com