Hyperledger Fabric — Part 1 — Components and Architecture
This is my second blog on Blockchain technology. In the earlier post, we talked about Bitcoin and took a deep dive in its framework. You can read the blog here.
In this blog, we will focus on Hyperledger Fabric components and Architecture.
Hyperledger is an umbrella of open source projects and tools which is managed by Linux foundation which started in December 2015.
Since this blog is more related to Hyperledger Fabric, let's see a brief history of the birth of Fabric:
The idea of privacy, confidentiality, and auditability, are words where implementations fit in. A few folks from Digital asset and IBM started the project called Open Blockchain (OBC) on 9/2015 and completed it on 12/2015 which supports all kinds of use cases which Business doesn’t. Later in 2/2016, the developers joined Linux Foundation which maintained the Hyperledger projects. They donated the project for future maintenance under Hyperledger umbrella. Fabric became the first project under umbrella which went live and ready to deploy to applications on 7/2017.
Ref: https://www.linkedin.com/pulse/hyperledger-fabric-brief-history-binh-nguyen/
Now, let's start understanding Fabric in detail.
Hyperledger Fabric is a permissioned blockchain framework, with a modular architecture (plug-and-play). It leverages container technology to host smart contract (Chaincode) which contains application logic.
Before going to each component in detail let us see a high-level transaction flow and basic components involved.
Here when clients submit the transaction proposal through the Fabric SDK, this proposal is sent to all Endorsing Peers. These endorsing peers check the transaction verifies and executes and generate the Read and Write set as output. Now, this response is again sent to the client. The client collects all responses from all endorsing peers, and send them to Orderer. Now, Orderer sees all transactions and orders them in ascending order and form a block. Now, this block is sent to all committers which checks the transaction and add a new block in their own copy of the ledger.
Since you are aware of basic terms and workflow, lets see blockchain’s main components. Later, we will see the transaction flow in much more detail.
Fabric consist of below major components
- Membership Service Provider(MSP)
- Client
- Peer
- Orderer
Membership Service Provider (MSP)
The membership service provider (MSP), is a component that defines the rules in which, identities are validated, authenticated, and allowed access to a network. The MSP manages user IDs and authenticates clients who want to join the network. This includes providing credentials for these clients to propose transactions. The MSP makes use of a Certificate Authority, which is a pluggable interface that verifies and revokes user certificates upon confirmed identity. The default interface used for the MSP is the Fabric-CA API. However, organizations can implement an External Certificate Authority of their choice. As a result, a single Hyperledger Fabric network can be controlled by multiple MSPs, where each organization brings its own favorite.
There are two types of MSPs.
- Local MSP: It defines users(Clients) and nodes(peers, orderers). It defines who has administrative or participatory rights at that level.
- Channel MSP: It defines administrative and participatory rights at the channel level.
Client
Clients are applications that act on behalf of a person to propose transactions on the network. The client uses a Fabric SDK in order to communicate with the network. The client communicates with the SDK in order to Read or Write the data in a Fabric blockchain and an in-state DB. Even the client is issued with a certificate from the CA authority in order to make sure that a valid client has initiated the transaction over the network.
Nodes
A “Node” is only a logical function in the sense that multiple nodes of different types can run on the same physical server. What counts is how nodes are grouped in “trust domains” and associated with logical entities that control them.
There are three types of nodes:
- Client: A client that submits an actual transaction-invocation to the endorsers, and broadcasts transaction-proposals to ordering service. In short, clients communicate with both peers and the ordering service
- Peer: A node that commits transactions and maintains the state and a copy of the ledger. A peer receives ordered state updates in the form of blocks from the ordering service and maintains the state and the ledger. Besides, peers can have a special endorser role. The special function of an endorsing peer occurs with respect to a particular chaincode and consists in endorsing a transaction before it is committed.
- Ordering-service-node or Orderer: a node running the communication service that implements a delivery guarantee, such as atomic or total order broadcast.
Types of Peers
- Endorsing Peer: Endorsing peers is a special type of committing peers who have an additional role to endorse a transaction. They endorse the transaction request which comes from the client. Each endorsing peer possesses the copy of smart contract installed and a ledger. The main function of Endorser is to simulate the transaction. It is executed based on the smart contract on the personal copy of the ledger, and generates the Read/Write sets which are sent to Client. Though during simulation, the transaction is not committed to the ledger.
- Committing Peer: Peers who commit the block which is received from the Ordering service, in their own copy of the blockchain. This block contains the list of transactions where committing peer to validate each transaction and mark it as either valid or invalid and commits to the block. All transaction either valid or invalid are all committed to blockchain for future audit purpose.
- Anchor Peer: As Fabric network can extend across multiple organization, we need some peers to have communication across an organization. Not all peers can do this, but these are special peers who are only authorized to do so which are nothing but Anchor peer. The anchor peers are defined in Channel configuration.
- Leading Peer: Leader peers are those who communicate or disseminate messages from Ordering service to other peers in the same organization. These peers use Gossip protocol to make sure that every peer receives the message. Leading peers cannot communicate across an organization. If any Leading peer is not responding or is out of network, then we can select a leading peer from available peer based on voting or randomly choose one.
Orderer
In a Blockchain network, transactions have to be written to the shared ledger in a consistent order. The order of transactions has to be established to ensure that the updates to the world state are valid when they are committed to the network. Unlike the Bitcoin blockchain, where ordering occurs through the solving of a cryptographic puzzle, or mining. Hyperledger Fabric allows the organizations running the network to choose the ordering mechanism that best suits that network. This modularity and flexibility make Hyperledger Fabric incredibly advantageous for enterprise applications.
Hyperledger Fabric provides three ordering mechanisms: SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT), the latter of which has not yet been implemented in Fabric v1.0.
- SOLO
It is the Hyperledger Fabric ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks. SOLO involves a single ordering node. In this, the transactions are ordered in chronological order to form a block. - Kafka
It is the Hyperledger Fabric ordering mechanism that is recommended for production use. This ordering mechanism utilizes Apache Kafka, an open source stream processing platform that provides a unified, high-throughput, low-latency platform for handling real-time data feeds. In this case, the data consists of endorsed transactions and RW sets. The Kafka mechanism provides a crash fault-tolerant solution to ordering service. - SBFT
It stands for Simplified Byzantine Fault Tolerance. This ordering mechanism is both crash fault-tolerant and byzantine fault-tolerant, meaning that it can reach agreement even in the presence of malicious or faulty nodes. The Hyperledger Fabric community has not yet implemented this mechanism, but it is on their roadmap.
These three ordering mechanisms provide alternate methodologies for agreeing on the order of transactions.
Other components which are part of the network and yet very important to understand are as below
- Channels
A fabric network can have multiple channels. Channels allow organizations to utilize the same network while maintaining separation between multiple blockchains. Only members(peers) of the channels are allowed to see the transaction created by any member in a channel. In other words, channels partition the network in order to allow transaction visibility for stakeholders only. Only the members of the channel are involved in consensus, while other members of the network do not see the transactions on the channel. The peer can maintain multiple ledgers. And peer can be connected to multiple channels.
The configuration of the channel is maintained by configtx.yaml file. Using this file we generate channel.tx file and then create a channel using it. Chaincode is installed on all participating peers in a channel, where as chaincode is instantiated on a channel. A channel contains all the configurations of communication between peers. It holds the list of peers along with who are endorsing, anchor, leader peers. When a client communicates with the network using SDK, the SDK first gets a list of all endorsing peers to which the transaction request needs to send. Using this list the SDK sends transaction requests to peers. Peers that do participate in multiple channels simulate and commit transactions to different ledgers. Orderers are also a part of channels.
- Identity
Each actors in a network peer, orderer, client, admin have some digital identity in the form of certificate X.509. This identity is used to verify at each and every step of a transaction, in order to check if the source of the transaction is from a valid source. In addition to the multitude of endorsement, validity, and versioning checks that take place, there are also ongoing identity verification happening during each step of the transaction flow.
- Policies
Policies reside in the Channel configuration, but in some cases, it resides in chaincode too. To define, a policy is a function which accepts as input a set of signed data and evaluates successfully or returns an error because some aspect of the signed data did not satisfy the policy. More concretely, policies test whether the signer or signers of some data meet some condition required for those signatures to be considered ‘valid’.
There are two types of policies
Signature Policy: It is powerful and specifies policy as a combination of evaluation of rules for MSP principles. It supports a combination of AND, OR and NOutOf.
Implicit Meta policy: This is less flexible and only valid in context for configuration. It aggregates the result of evaluating policies deeper in the configuration hierarchy, which are ultimately defined by SignaturePolicies.
- Ledger
It is a current state of the business as a journal of transaction. A ledger consists of two different parts, a world state, and a blockchain. A ledger is kept at all peers and, optionally, at a subset of orderers. In the context of an orderer, we refer to the Ledger as to OrdererLedger, whereas in the context of a peer we refer to the ledger as to PeerLedger. PeerLedger differs from the OrdererLedger in that peers locally maintain a bitmask that tells apart valid transactions from invalid ones.
The two different part of Ledger are:
World State: Each chaincode has its own World state and blockchain. It is a DB that holds the current state of the ledger state. These states are expressed as key-value pairs. It holds the fact of a business object. It can be created, update and delete. When application submits the transaction, and when it comes to committing the valid transaction, it first commits in the World state and then it is updated in ledger. State also has a version number. This version number changes each time the state is updated. When a ledger is created the world state is empty, as any transaction which represents a valid change in world state is recorded in blockchain too. This means world state can be generated at any time from the blockchain. The state is maintained by Peers only.
Blockchain: A transaction log that records all the changes that have resulted in the current world state. Its data structure is different as once written cannot be removed. It is immutable. It is a historical record of facts about how the objects arrived at the current state. It is structured as a sequential log of interlinked blocks, where each block contains a sequence of transactions, each transaction representing a query or update to the world state.
Each block header includes a hash of blocks transactions, as well as a copy of a hash of the previous block’s header. Blockchain is always implemented as a file, not like that of the world state which uses database. The first block in the chain is the genesis block. Though this is a starting point of the ledger. It does not contain any transaction details. Instead, it contains configuration transaction details containing initial state of the network channel.
Each Block consists of
Header: This consists of 3 fields
Block number: An integer starting from 0, the genesis block, and incremented by 1 for each new block appended.
Current Block Hash: Hash of all transactions contained in a block
Previous Block Hash: Hash of the previous block.
Data: This consists of a list of transactions arranged in order.
Metadata: It contains time when the block was written, certificate, public key and signature of block writer. A block committer also adds a valid/invalid indicator for every transaction. This information is not included in the hash of the block
Each Transaction in a block consists of
Header: Contains essential metadata about the transaction. For example, Name of relevant chaincode and its version.
Signature: Contains cryptographic signature created by the client application. It is used to check if the transaction details have not been tampered and require application private key to generate it.
Proposal: Encodes input parameters supplied by application to the smart contract which creates proposed ledger update. When the smart contract runs, this proposal provides a set of input parameters, which, in combination with the current world state, determines the new world state.
Response: It captures before and after values of world state as Read/Write (RW) set. It is the output of the smart contract.
Endorsement: This is the list of signed transaction responses from each required organization sufficient to satisfy the endorsement policy. So here for one transaction proposal, we have multiple endorsement responses.
- Chaincode
A smart contract defines the transaction logic that controls the lifecycle of a business object contained in the world state. It is then packaged into the chaincode which is deployed to the blockchain network. Smart contracts are defined within chaincode. Multiple smart contracts can be defined within a single chaincode. When a chaincode is deployed, all smart contracts available within the chaincode is made available to the application. We can see that a smart contract is a domain specific program which relates to specific business processes, whereas a chaincode is a technical container of a group of related smart contracts for installation and instantiation. Every chaincode has endorsement policy attached to it, which applies to every smart contract defined within it. This identifies which organization must sign a transaction generated by Smart contract, in order to consider it valid. So, in short, every smart contract has an endorsement policy attached to it. A smart contract can call other smart contracts within a channel or across different channels.
Recommend you to go through my next blog which covers the Hyperledger Fabric Transaction flow, here.
You can read my other blog related to Bitcoin
