In a previous article, you have learned that Hyperledger Fabric has a highly modular and configurable architecture. In this article, we shall examine the architecture in more details.
Hyperledger Fabric is a permissioned blockchain network that provides ledger services to application clients and administrators. It allows multiple organizations to collaborate as a consortium to form the network. The permissions to join the network are determined by a set of policies that are agreed to by the consortium when the network is configured. The network policies may change over time subject to the agreement of the organizations in the consortium.
The Hyperledger Fabric network comprises the following components:
The Hyperledger ecosystem also consists of the client applications that allow users to interact with the network. Moreover, The Hyperledger Fabric application SDK provides a powerful API for developers to program applications to interact with the blockchain network on behalf of the users.
The Fabric network is comprised primarily of a set of peers or nodes. Peers maintain the state of the network and a copy of the ledger. In addition, they also host smart contracts(chaincode).
There are two different types of peers in Fabric, the endorsing peer and the committing peer. The endorsing peers (aka endorsers) simulate and endorse transactions. On the other hand, the committing peers (aka committers) verify endorsements and validate transactions before committing transactions to the blockchain. On a separate note, the endorsing peers can also commit transactions to the blockchain. Indeed, the endorsers are special kind of committers. However, the committers cannot be the endorsers. All peers can commit blocks to the distributed ledger.
The ordering service is made up of a cluster of special nodes known as orderers. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger. However, It does not process transactions, smart contracts, or maintains the shared ledger.
Let's examine the transaction workflow that involves the client applications, the peers and the orderers. By examining the entire transaction workflow, we will learn how consensus is reached in the process.
The transaction flow to reach consensus consists of three phases:
Transactions begin with client applications sending transaction proposals to the endorsing peers, as shown in the following diagram:
At this phase, the endorsers will simulate the proposed transactions, without actually updating the ledger. The Endorsers must hold smart contracts in order to simulate the transaction proposals. In the simulation process, the endorsing peers will capture the set of Read and Written data, known as RW Sets.
These RW sets contain data that was read from the current world state while simulating the transaction, as well as data that would have been written to the world state had the transaction been executed. The endorsing peers then sign these RW sets and send them back to the client application for use in the next phase of the transaction flow, as shown below:
At this phase, the client application submits the endorsed transactions and the RW sets to the ordering service. The ordering service will take the endorsed transactions and RW sets and orders them into a block and delivers the block to all committing peers.
The order of transactions needs 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 or Ethereum, where ordering occurs through mining, Hyperledger Fabric allows the organizations to choose the ordering mechanism that best suits that network.
Hyperledger Fabric provides three ordering mechanisms i.e. SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT). However, SOLO is used only for experimentation purposes and SBFT has not yet been implemented. Therefore, Kafka is the default ordering mechanism for production use. The Kafka mechanism provides a crash fault-tolerant solution to ordering.
At this final phase, the committing peers validate the transactions by checking that the RW sets still match the current world state. In addition, they need to ensure that Read data that existed during the simulation process is identical to the current world state.
After the committing peers validated the transactions, the transactions are then written to the ledger, and the world state is updated with the Write data from the RW Set. Committing peers are responsible for adding blocks of transactions to the blockchain and updating the world state. Lastly, the committing peers asynchronously notify the client application the results of the transactions.
I shall discuss channels, membership service provider and chaincode in another article.
