--- title: Introduction to Hyperledger Fabric type: article date: 2019-12-18 source: website original_url: "https://navveenbalani.dev/index.php/articles/introduction-to-hyperledger-fabric/" topics: ["blockchain"] legacy_categories: ["blockchain"] tags: ["blockchain-guide"] summary: Hyperledger was initiated by Linux Foundation as a base project to create blockchain based technologies. The objective of Hyperledger project is to collaboratively develop blockchain technologies through open source and community-based development. Fabric is one of the… draft: false --- Hyperledger was initiated by Linux Foundation as a base project to create blockchain based technologies. The objective of Hyperledger project is to collaboratively develop blockchain technologies through open source and community-based development. Fabric is one of the blockchain project or framework as part of Hyperledger initiative. The most distinguishing aspect of Hyperledger Fabric is that it is a permissioned-based enterprise grade blockchain platform and unlike Bitcoin or Ethereum, it does not deal with any kind of crypto-currency or mining based concept. Hyperledger Fabric is built on four core features: **Shared Ledger** - One ledger that contains transactional data and is distributed and shared across business network **Confidentiality** - Controlled visibility and access to transactions through the concept of channels **Smart Contract** - Business logic rules shared across the business network **Trust** - All the entities in the business network own the copy of ledger and are able to verify it thereby enforcing trust ## Core Component Model In this section, we will talk about components or the building blocks of the Hyperledger Fabric framework that makes it a more complete permissioned enterprise blockchain solution. ### Peer (Node) Peer is a node in the Fabric network that performs the validation and updates to the blockchain data. A typical Fabric network will have more than one peer node in the network. It is the peer where the ledger is stored. Every peer maintains its own copy of shared ledger. A peer may also have multiple ledgers by subscribing to multiple channels (see Channel section). When transactions are delivered to the channel, it is then synced across all the peers that are part of that channel thereby keeping them in a consistent and trusted state. In a Fabric model, a peer can also perform a role of endorser where it has the ability to simulate and verify the transaction initiated by the client application. The validating peers will simply verify the transactions that were invoked making sure the data is in a consistent state before committing a block to the ledger. Fabric deployment also allows for horizontal scaling where peers can be added to the blockchain network as and when needed. ### Ordering Service Ordering service or orderer is another important component of the Fabric model. It is used to create and order blocks of transactions before it is sent to the peers for commit. All the peers receive the same block of transactions atomically and in the same order. The atomicity guarantees the network to be in the state of consensus. Once the transactions are received from the channel, the ordering service orders them according to its occurrence. It creates a chain of hashed transaction ids with each transaction pointing to the previous hashed transaction id thereby maintaining the order for that block. After the transactions are ordered, they are grouped and assigned as part of block for that channel. (See the below section for more on Channel). Client applications and peers subscribe to these channels to send or receive transactions respectively. Orderers provide two primary functionalities viz. broadcast and deliver. Broadcast is used by client applications to broadcast transactions and deliver is used by orderer to create block of these transactions and send them to peers. ### Channel Channel is a place for private communication where parties to the business network can execute transactions in a confidential way. Channels can be thought of as a partitioned topic in a messaging system where each partition acts as a separate channel, and the transactions in that partition are only visible to its subscribers. Every channel is independent of another and has its own set of security policies and chaincode (See the below section for more on Chaincode). Peers in the Fabric model must be part of a particular channel. A peer can also be part of multiple channels. Channel participants (peers) must be in the know of each other; it means that only authorized peers can be part of the channel. This is achieved using something known as genesis or the first block that contains the configuration details of the channel that states which peers can be part of this channel. One can create as many channels as needed and peers can be made part of one or more channels. Every channel will manage its own distinct ledger (transactions). --- *Note- The channel maps to the Ledger Conduits of our reference architecture.* --- **Chaincode** Smart contract in Fabric model is known as chaincode. It is an application code that represents business logic to invoke transactions. Using chaincode one can read and update the ledger data. Chaincodes are executed on peers. Hyperledger Fabric provides support for Go and Java programming language for developing chaincode. When you write a chaincode, you are actually writing business logic to manipulate or query the ledger data. Chaincode must be part of the channel and can manipulate only the ledger of that channel. Peers of that channel can use one or set of multiple chaincodes to execute a complex business process workflow. Chaincode must be installed and eventually instantiated. Chaincodes are installed on every peer that forms a part of the channel. Each peer owns a copy of ledger, and therefore, chaincode must be installed on each peer for a given channel. After installation, each chaincode needs to be instantiated. Chaincode instantiation requires an endorsement policy, which suggests which peer can endorse the chaincode transaction. Every chaincode can have its own distinct policy. Policies can be customized to make it more stringent or lenient based on the business requirement. ### MSP Membership Service Provider (MSP) is one of the core components of the Fabric model that provides an abstraction over creating the identities for the network components like peers, orderers, users, etc. It provides cryptographic credentials in the form of keys and certificates that helps in authenticating and verifying network entities as they communicate with each other. It in a way provides root of trust to the blockchain network. An MSP may define its own protocol stack and rules to generate crypto credentials, which are then used for signing and verification. You could think of a business entity or an organization as one MSP. One or more MSP can be set up as part of a consortium, and the structural metadata can be provided in the configuration file. Based on the configuration, crypto materials can be generated. MSP is identified by its id and is associated with its peers and orderers in the network. Different network design topology can be thought of or devised with respect to MSP, but the usual best practice is to have one MSP per organization. One can use the cryptogen tool provided by the Fabric runtime, or you can use Fabric CA server to generate crypto artifacts like certificates and keys. --- *Note - The MSP maps to the abstraction level that we had talked about in Security layer of our reference architecture.* --- ### Fabric CA Hyperledger Fabric provides a Certificate Authority (CA) component called Fabric CA, which can be used for managing the network identities of all member organizations, their nodes and users. Fabric CA drives security using cryptographically signed certificates. Every transaction whether read or update must be signed using the certificate. Fabric CA server can be used to issue certificates and associate it with different entities of the network like peer nodes or orderer nodes. It can also be used to create or register a user. If you already have users created in LDAP or Active Directory (AD), you can still use Fabric CA to integrate with your existing LDAP or AD infrastructure. Hyperledger Fabric provides a modular architecture, so you can plug-in any CA implementation of your choice. Alternatively, you can also create your own certificates and use it as part of the blockchain network. For instance, while building the demo application later, we would use the tool called cryptogen for generating the certificates for each entity in our blockchain network. As identity management and provenance has become a key principal of the blockchain network, Hyperledger Fabric provides an abstraction called Membership Service Provider (MSP), which provides a pluggable interface to support various identity and credential management implementations. We discussed MSP in detail in earlier section. The default implementation of MSP leverages Fabric CA component as one of the providers for identity management. --- *Note - The Fabric CA maps to the Certificate Authority (CA) provider that we had talked about in the security section of our reference architecture.* --- In the [next article](/articles/the-trade-finance-use-case-using-ibm-hyperledger), we we build a trade finance application on Hyperledger Fabric