Introduction to Fabric V1
Fabric is an open source project under the umbrella of Hyperledger , a consortium hosted by Linux Foundation. It is a private and a permissioned blockchain based network. This means that the members participating in the network know each other’s identity unlike public blockchain networks where the members can be anonymous. Also, in contrast to public blockchain networks, where every member has the same copy of the ledger, the members in the case of private networks have an option to keep data confidential amongst only the participating members of the contract. This post will describe the high level architecture of Hyperledger Fabric v1, which is a major change since the earlier v0.6 version. We will not describe the changes since v0.6 but rather focus primarily on the v1 architecture itself.
Fabric v1 Architecture
The strength of Fabric lies in its modularity, which we shall see when we describe its individual components. Modularity enables flexibility of a pluggable architecture but with it comes complexity. Before, we go into the typical architectural flows, we need to understand the Fabric network terminology.
Member of a network is typically an organisation authorised to participate in the network. These members own and maintain network entities called peers.
Peer node maintains the ledger and runs the Chaincode containers. Peer nodes can play an endorsing role in addition to the standard committing and validating role.
Ledger keeps track of the current and historical state. Essentially, it is the core backbone of a blockchain containing chained sequential blocks of transactions.
Chaincode is the term used for Smart Contract in Fabric. It is an entity which could hold the state of one or more digital assets. It is a piece of code that is deployed on the peer allowinginteraction with the network ledger to store or query its state.
These components are required for any Blockchain 2.0 platform, which introduced the concept of Smart Contracts. However, the uniqueness of Fabric comes with its built-in support for channels, which are isolated data stores, security including identity management using Fabric certificate authority and the decoupling of consensus using ordering service as a pluggable component.
Fabric Channels provide you a way to have your own confidential (private) area in the ledger. These are separate ledgers where only parties subscribed to the channel are able to read and write data. Other parties who are in the network but outside the channel have no access to this data. Generally, these channels manifest physically as a separate database. A two step (install and instantiate) deployment mechanism of Chaincode allows a maximum of one instance of a certain Chaincode type to runs on each peer even though it can be used to serve multiple channels.
The Ordering Service provides an ability to order transactions into a block on a first come first serve basis for all the channels on the network. This service contains the cryptographic ids of all the members of the network. It produces blocks and communicates these blocks to the peers, thus binding the network. An orderer can work with multiple channels at the same time and more than one organisation can be added to the Ordering Service.
Peers communication can be split by peers in the same organisation vs another organisation. Amongst peers in the same org, there is a gossip protocol which is followed. For peers across orgs, the communication information is in the channel config/genesis block for the channel. This information on the join channel will allow the peer to determine ‘anchor peers’, which allow discovery across organisations.
In addition, there are security related services such as Membership Services which implements the authentication, authorisation and identity management. Membership Services Provider or MSP provides an abstraction to the implementation of the membership services. The role of the local MSP is to sign as the identity of the peer or orderer, and to control CC installs to a peer. Fabric comes with its own certificate authority server which provides services for registration, enrolment and revocation. Registration creates a user entry in fabric-ca-server’s DB with an associated password. Enrolment is what creates an enrolment certificate (eCert).
From a client perspective, there are two ways to interact with the Fabric network – CLI and the SDK that you can embed within your app. The SDK comes in many flavours but the most common one used is the Fabric Node SDK built on Node js platform.
Generally, there are different scenarios performed in an end to end process of an application interacting with the HyperLedger Fabric network. Here we are outlining 3 common scenarios :
- Scenario 1: Identity enrolment
- Registration of of an identity can be done by an already enrolled identity. In this case, identity could be an individual user or a peer or the client application. Submitting client submits the registration request to Fabric CA server, which issues a secret which will be required in the enrol process
- Enrolment request is then sent from the submitting client to the Fabric CA server passing the enrolment and secret obtained in the registration process.
- In response, Fabric CA server passes the enrolment certificate along with the enrolment key. The application simply needs to enrol to get ecert(s) and then use that to sign it. When the certificate is sent to a peer with a valid signature, it will be found valid as long as the CA’s signing cert is also one of the cacerts (or intermediatecerts) of the local MSP or of the channel, depending on which operation is being performed.
- Scenario 2: Set up shared data channel and install your programmable digital asset (Chaincode)
- In this case, submitting client application creates a channel through the ordering service.
- After the channel is created, the client can then send a join channel proposal request to those peers, which it wants to participate in the channel. If your client is not allowed to connect to peers outside your organisation, you can use off chain mechanisms such as messaging for those peers.
- Once the peers have joined the channel, the anchor peers can be set and the Chaincode be installed on the peer file system.
- Scenario 3: Read or write the state of the digital asset
- This involves initialising the Chaincode by associating it with a channel or invoking (write transaction)/querying (read) a Chaincode. As a pre-requisite all peers on the channel (including the non endorsing ones), which require interaction (query/invoke) with Chaincode for the state should have Chaincode installed.
- The endorsing peer receives the proposal requests from the client and then simulates the Chaincode interactions. It produces a read write set and then sends it response back to the submitting client stating its response based on the endorsement policy.
- Once the submitting client has received all the required positive endorsements, it submits the endorsed transactions to the ordering service.
- The ordering service validates the transactions, orders them on a first come first serve basis and finally sends the confirm block of transaction to all the peers identified in the channel configuration.
In conclusion, we described the basic Fabric v1 components and their interactions in this post. In our next post, we shall discuss how ChainThat has leveraged Hyperledger Fabric v1 in its Insurance Blockchain Platform to implement the use cases of commercial reinsurance industry.
*Disclaimer: The view expressed in this post are author’s own opinion