Introduction to Hyperledger Fabric
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, we we build a trade finance application on Hyperledger Fabric