Hyperledger Fabric Architecture Part 1

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 Network

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.

  • Peers
  • Ordering service
  • Chaincode (aka smart contract)
  • Channels
  • Membership service provider

Peers

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).

Ordering Service

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.

The Transaction workflow

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.

  • Ordering
  • Validation and commitment

PHASE 1 TRANSACTION ENDORSEMENT

Transactions begin with client applications sending transaction proposals to the endorsing peers, as shown in the following diagram:

PHASE 2 TRANSACTIONS SIMULATION

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.

PHASE 3 ORDERING

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.

Phase 4 Transactions Validation

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.

Blockchain Architect

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store