Hyperledger was initiated by Linux Foundation as a base project to\ncreate blockchain based technologies. The objective of Hyperledger project is\nto collaboratively develop blockchain technologies through open source and\ncommunity-based development. Fabric is one of the blockchain project or\nframework as part of Hyperledger initiative. The most distinguishing aspect of\nHyperledger Fabric is that it is a permissioned-based enterprise grade\nblockchain platform and unlike Bitcoin or Ethereum, it does not deal with any\nkind of crypto-currency or mining based concept. <\/p>\n\n\n\n
Hyperledger Fabric is built on four core features:<\/p>\n\n\n\n
Shared Ledger<\/strong> – One ledger\nthat contains transactional data and is distributed and shared across business\nnetwork<\/p>\n\n\n\n Confidentiality<\/strong> – Controlled\nvisibility and access to transactions through the concept of channels<\/p>\n\n\n\n Smart Contract<\/strong> – Business logic\nrules shared across the business network<\/p>\n\n\n\n Trust<\/strong> – All the\nentities in the business network own the copy of ledger and are able to verify\nit thereby enforcing trust<\/p>\n\n\n\n In this section, we will talk about components or\nthe building blocks of the Hyperledger Fabric framework that makes it a more\ncomplete permissioned enterprise blockchain solution.<\/p>\n\n\n\n Peer is a node in the Fabric network that\nperforms the validation and updates to the blockchain data. A typical Fabric\nnetwork will have more than one peer node in the network. It is the peer where\nthe ledger is stored. Every peer maintains its own copy of shared ledger. A\npeer may also have multiple ledgers by subscribing to multiple channels (see\nChannel section). When transactions are delivered to the channel, it is then\nsynced across all the peers that are part of that channel thereby keeping them\nin a consistent and trusted state. In a Fabric model, a peer can also perform a\nrole of endorser where it has the ability to simulate and verify the\ntransaction initiated by the client application. The validating peers will\nsimply verify the transactions that were invoked making sure the data is in a\nconsistent state before committing a block to the ledger. Fabric deployment\nalso allows for horizontal scaling where peers can be added to the blockchain\nnetwork as and when needed.<\/p>\n\n\n\n Ordering service or orderer is another important\ncomponent of the Fabric model. It is used to create and order blocks of\ntransactions before it is sent to the peers for commit. All the peers receive\nthe same block of transactions atomically and in the same order. The atomicity\nguarantees the network to be in the state of consensus. Once the transactions\nare received from the channel, the ordering service orders them according to\nits occurrence. It creates a chain of hashed transaction ids with each\ntransaction pointing to the previous hashed transaction id thereby maintaining\nthe order for that block. After the transactions are ordered, they are grouped\nand assigned as part of block for that channel. (See the below section for more\non Channel). Client applications and peers subscribe to these channels to send\nor receive transactions respectively. Orderers provide two primary\nfunctionalities viz. broadcast and deliver. Broadcast is used by client\napplications to broadcast transactions and deliver is used by orderer to create\nblock of these transactions and send them to peers.<\/p>\n\n\n\n Channel is a place for private communication\nwhere parties to the business network can execute transactions in a\nconfidential way. Channels can be thought of as a partitioned topic in a\nmessaging system where each partition acts as a separate channel, and the\ntransactions in that partition are only visible to its subscribers. Every\nchannel is independent of another and has its own set of security policies and\nchaincode (See the below section for more on Chaincode). Peers in the Fabric\nmodel must be part of a particular channel. A peer can also be part of multiple\nchannels. Channel participants (peers) must be in the know of each other; it\nmeans that only authorized peers can be part of the channel. This is achieved\nusing something known as genesis or the first block that contains the\nconfiguration details of the channel that states which peers can be part of\nthis channel. One can create as many channels as needed and peers can be made\npart of one or more channels. Every channel will manage its own distinct ledger\n(transactions).<\/p>\n\n\n\n Note- The channel\nmaps to the Ledger Conduits of our reference architecture.<\/em><\/p>\n\n\n\n Chaincode<\/strong><\/p>\n\n\n\n Smart contract in Fabric model is known as chaincode. It is an\napplication code that represents business logic to invoke transactions. Using\nchaincode one can read and update the ledger data. Chaincodes are executed on\npeers. Hyperledger Fabric provides support for Go and Java programming language\nfor developing chaincode. When you write a chaincode, you are actually writing\nbusiness logic to manipulate or query the ledger data. Chaincode must be part\nof the channel and can manipulate only the ledger of that channel. Peers of\nthat channel can use one or set of multiple chaincodes to execute a complex\nbusiness process workflow. Chaincode must be installed and eventually\ninstantiated. Chaincodes are installed on every peer that forms a part of the\nchannel. Each peer owns a copy of ledger, and therefore, chaincode must be\ninstalled on each peer for a given channel. After installation, each chaincode\nneeds to be instantiated. Chaincode instantiation requires an endorsement\npolicy, which suggests which peer can endorse the chaincode transaction. Every\nchaincode can have its own distinct policy. Policies can be customized to make\nit more stringent or lenient based on the business requirement.<\/p>\n\n\n\n Membership Service Provider (MSP) is one of the\ncore components of the Fabric model that provides an abstraction over creating\nthe identities for the network components like peers, orderers, users, etc. It\nprovides cryptographic credentials in the form of keys and certificates that\nhelps in authenticating and verifying network entities as they communicate with\neach other. It in a way provides root of trust to the blockchain network. An\nMSP may define its own protocol stack and rules to generate crypto credentials,\nwhich are then used for signing and verification. You could think of a business\nentity or an organization as one MSP. One or more MSP can be set up as part of\na consortium, and the structural metadata can be provided in the configuration\nfile. Based on the configuration, crypto materials can be generated. MSP is\nidentified by its id and is associated with its peers and orderers in the\nnetwork. Different network design topology can be thought of or devised with\nrespect to MSP, but the usual best practice is to have one MSP per\norganization. One can use the cryptogen tool provided by the Fabric runtime, or\nyou can use Fabric CA server to generate crypto artifacts like certificates and\nkeys.<\/p>\n\n\n\n Note – The MSP\nmaps to the abstraction level that we had talked about in Security layer of our\nreference architecture.<\/em><\/p>\n\n\n\n Hyperledger Fabric provides a Certificate Authority (CA) component\ncalled Fabric CA, which can be used for managing the network identities of all\nmember organizations, their nodes and users. Fabric CA drives security using\ncryptographically signed certificates. Every transaction whether read or update\nmust be signed using the certificate. Fabric CA server can be used to issue\ncertificates and associate it with different entities of the network like peer\nnodes or orderer nodes. It can also be used to create or register a user. If\nyou already have users created in LDAP or Active Directory (AD), you can still\nuse Fabric CA to integrate with your existing LDAP or AD infrastructure.<\/p>\n\n\n\n Hyperledger Fabric provides a modular architecture, so you can plug-in\nany CA implementation of your choice. Alternatively, you can also create your\nown certificates and use it as part of the blockchain network. For instance,\nwhile building the demo application later, we would use the tool called\ncryptogen for generating the certificates for each entity in our blockchain\nnetwork.<\/p>\n\n\n\n As identity management and provenance has become a key principal of\nthe blockchain network, Hyperledger Fabric provides an abstraction called\nMembership Service Provider (MSP), which provides a pluggable interface to\nsupport various identity and credential management implementations. We\ndiscussed MSP in detail in earlier section. The default implementation of MSP\nleverages Fabric CA component as one of the providers for identity management.<\/p>\n\n\n\nCore Component Model<\/a><\/h2>\n\n\n\n
Peer\n(Node)<\/a><\/h3>\n\n\n\n
Ordering\nService<\/a><\/h3>\n\n\n\n
Channel<\/a><\/h3>\n\n\n\n
\n\n\n\n
\n\n\n\nMSP<\/a><\/h3>\n\n\n\n
\n\n\n\n
\n\n\n\nFabric CA<\/h3>\n\n\n\n
\n\n\n\n