Chain Lesson | An Introduction to Hyperledger—Fabric Operation Mechanism

Chain Lesson is a regular column of the Cheetah Blockchain Research Center. It aims to provide blockchain enthusiasts with the most complete and trending industry knowledge.

A. Introduction
Blockchain has become the most-watched technology. From the surge in popularity of Bitcoin to the burgeoning development of ICO projects based on Ethereum, the public's attention has been drawn by various types of new cryptocurrencies, and enthusiasm for trading and investment has been high. In contrast, blockchain-related enterprise projects have not received much attention.

However, many well-known enterprises in China, such as JD.com and Huawei, are actively deploying enterprise-level blockchain projects. Without exception, they all choose the regulated, partially decentralized, and high-performance consortium blockchain.

Why is the consortium blockchain favored by so many large enterprises? In this article, I will be introducing Hyperledger Fabric, a project based on a consortium blockchain.

When it comes to consortium blockchains, Hyperledger has to be mentioned. As a blockchain project under the Linux Foundation, Hyperledger was proposed by technology companies, such as IBM and Intel, financial companies, such as J.P. Morgan, and other joint organizations in 2015. At present, Hyperledger has more than 140 members, one quarter of which are from China. The Chinese technology group is mainly composed of Wanda, Huawei, and IBM. Its responsibilities include meeting the needs of members in China and Chinese members, and promoting the code. A large number of enterprise blockchain projects based on Hyperledger technology have been successfully implemented.

Hyperledger includes four framework projects: Sawtooth, Iroha, Fabric, and Burrow. Fabric is the most widely known and the earliest top-level project to join Hyperledger. It has complete permission and audit management, fine-grained privacy protection, and a pluggable and extensible implementation framework. At present, the number of code submissions is close to 6,000, and there are about 100,000 lines of core code, making it a fairly active project.

This article will mainly introduce the operating mechanism and principle of Fabric. In upcoming articles, we will present more content including in-depth development guides for Fabric, more Fabric application scenarios and instances, etc.

B. Architecture
Fabric released the official 1.0 version in July 2017. Compared with the experimental version (released in September 2016), the official version has been greatly improved and enhanced in scalability, maintainability, security, and business isolation, and it approximates an enterprise application scenario more closely. Next, we enter the world of Fabric through the 1.0 version.

Figure 1. Fabric 1.0 Architecture

Figure 2. Runtime Architecture

➤Identity refers to identity management. Because of the importance of identity management, Fabric extracted the original Membership service as a separate module, Fabric-CA. As a non-licensed network, Fabric adopts a digital certificate mechanism to implement identity authentication and permission control. The CA node implements the PKI service, which is responsible for the generation and revocation of identity certificates, etc.

➤Chaincode comes from the idea of smart contracts and has been further extended to support advanced programming languages such as Java and Go. The runtime implements processing logic with containers and state machines.

➤Blockchain & Transactions. Fabric uses a blockchain storage structure similar to a public chain. The runtime has four storage structures: File System (Blockchain), Block Index, World State, and History Index. World State stores a set of variables, supports CouchDB, and provides abundant rich query APIs.

Figure 3. Ledger Storage

➤The bottom layer uses the P2P network and gRPC protocol to achieve the connection of distributed ledger structures, including Peers, OSNs, Clients and other participating roles. State synchronization, data distribution and member detection are implemented with a gossip protocol.

➤In addition to the client based on command lines, Fabric provides SDKs in multiple languages, including Node.js, Python, Java, Go, etc. SDK encapsulates the underlying gRPC API calls, providing better client and development support. In a blockchain network, nodes and chaincodes send events to trigger listening actions to facilitate integration with other external systems.

C. Multi-Channel

Figure 4. Multi-Channel Example

A channel and the configuration and data bound to the channel (including transactions, ledgers, chaincode instances, and membership) form a complete chain. Peer nodes can subscribe to any number of channels based on application access control policies. These Peer nodes only receive block data on the subscription channels. Data of different channels is isolated and confidential. Members outside the channel cannot access the data in the channel.

D. Transaction Process

Figure 5. Fabric Transaction Process

1. Client (SDK) logs in to CA to obtain ECert.

2. Client (SDK) sends a proposal to an endorser.

3. The endorser checks permissions and simulates chaincode transactions. The result is Yes/No. Then the returned endorsement is signed.

4. Client (SDK) receives enough endorsements and checks whether the number of endorsements is valid.

5. Client (SDK) sends the endorsed transaction to Orderers.

6. Orderers sort read-write sets and build blocks based on block configuration. Send the block to Committer

7. Committer checks block, transaction read-write set, endorsement policies, etc., writes to blockchain and updates World State DB.

E. Consensus Mechanism
In version 0.6, Fabric supports the PBFT consensus algorithm, which is no longer supported in 1.0 and later versions. The reason why the PBFT consensus algorithm is not used in version 0.6 may be:

1. PBFT provides (n-1)/3 fault tolerance, but O(N^2) message complexity makes transaction performance decrease significantly with the increase in nodes.
2. Fabric is an access network, which does not have a high requirement for PBFT consensus algorithm.

The consensus process of Fabric 1.0 includes endorsement, sorting, and checking.

➤Endorsement
During chaincode instantiation, endorsement policies need to be specified. For example:

• AND(‘Org1.member’, ‘Org2.member’, ‘Org3.member’) requests one signature from a member of each of the three orgs.
• OR(‘Org1.member’, ‘Org2.member’) requests one signature from a member of either of the two orgs.
• OR(‘Org1.member’, AND(‘Org2.member’, ‘Org3.member’)) requests one signature from a member of Org1, or one signature from a member of Org2 and one signature from a member of Org3.

➤Sorting
The sorting of Orderer is in two modes: Solo and Kafka.
Solo: It is an experimental single-node sorting function which is not scalable and fault-tolerant and cannot be used in a production environment; Kafka: It is cluster sorting which supports CFT fault tolerance, persistence and scalability. It can be used in a production environment.

➤Checking
Committer Peer does the final check on the sorted transactions before they are submitted to the ledger. The transaction is linked up whether it is valid or not. The state of the transaction indicates whether it is valid or not. If the transaction is invalid, the World State does not change.

F. Characteristics
In addition to the above-mentioned data isolation, modularization, chaincode which supports advanced languages, etc., Fabric differs from public chains such as Bitcoin and Ethereum in the following aspects:

➤Tokens
Fabric has no token mechanism. It only provides a blank platform on which users create things on their own; the nodes of public chains are profit-driven, and tokens are an incentive system to ensure the security and sustainability of the network. Fabric is an access network, and its nodes have a high degree of credibility and purpose, so tokens are not necessary.

➤Block Packaging
Fabric blocks can be configured with time, size, and even the upper limit of the transaction, which is very flexible. In addition, Fabric does not cut empty blocks and only produces blocks when there is a transaction; due to the incentive mechanism, public chains produce blocks periodically, which is a waste of storage to a certain extent. As part of the consensus, the timing and size of blocks produced can hardly change.

➤Finality
Based on No-op (without consensus) or PBFT consensus, Fabric is final. It is irreversible once consensus is reached so it is more suitable for some enterprise scenarios such as financial services. The probability algorithm of public chains represented by PoW is not final and the consensus result is temporary. With the passage of time or some reinforcement, the probability of the consensus result being overturned becomes smaller and smaller, and finally the result is finalized.

➤Regulation and Privacy
Based on PKI certificate system, the characteristics of Fabric include transaction tracking, accountability, non-repudiation, authorized data access, supervision and auditing; public chain data is completely open, anonymous and unsupervised so public chains have become havens for illegal trading.

➤Performance
As a non-licensed consortium blockchain, Fabric does not have too many participating nodes and the number of nodes running concurrently can reach hundreds or even thousands. It is a great improvement compared with dozens of concurrent running of public chains such as Bitcoin and Ethereum.

G. Summary
Characterized by pluggability, high performance, a full identity management mechanism and rich development module support, Fabric can integrate with enterprise applications naturally. I believe that Fabric will flourish in financial and more fields in the future.