This article is about Hyperledger Fabric (HF) concepts. The reason for making this article is because a lot of people still do not quite know where to start even do infrastructure side can be implemented very fast on Microsoft Azure or AWS.
Her is the high-level architecture of Hyperledger Fabric on Microsoft Azure Kubernetes Service
Hyperledger Fabric has so many features and concepts to understand that a lot of developers, including me who is just beginner, have a hard time understanding it.
On top of that, the documentation is not that great. Through this article, I would like to share how I understand Hyperledger Fabric.
Hyperledger Fabric is really hard and it will be difficult to understand and be proficient in a short time. There are so many components (Orderer, Peer, CA, channel, etc etc)
Following the developer, tutorials can help you get started but not enough to start a real project or service. If you want to use Hyperledger Fabric in a real-life project you would need a deeper understanding of it.
If you want to be able to utilize some of the other Fabric’s benefits you will have to understand the architecture of Hyperledger Fabric by reading the following case studies and white papers: https://www.hyperledger.org/resources/publications#white-papers
Once you understand architecture the next step is understanding the ReadSet & WriteSet.
For example, understanding how a chain code works. That should give you a better understanding of Fabric’s architecture.
Before we start, I would like to go over the fact that Hyperledger Fabric is a private blockchain. And I’ll quickly compare Hyperledger Fabric with Bitcoin/Ethereum.
As you know Bitcoin/Ethereum is the biggest public blockchain.
If I have to pick out the biggest difference between Fabric and the Bitcoin/Ethereum blockchain is that Bitcoin/Ehtereum blockchains run as a single program where Fabric has many task-specific components (programs) that work together.
With Bitcoin/Ethereum you only need to install one client program, such as the Bitcoin core or the Ethereum geth client.
It also saves the Bitcoin/Ethereum blockchain to your computer or the worldstate (in case of Ethereum). So in essence one program does it all.
However, in Hyperledger Fabric each task is a different program.
For example, the Orderer is for creating new blocks the Peer is for simulating and storing the blockchain.
Although the Orderer does store the blockchain as well for simplistic sake will separate their functions for now.
I think this is the biggest architectural difference between Fabric’s blockchain and public blockchains such as Bitcoin, Ethereum.
Another difference is the use of certification over private keys.
Bitcoin and Ethereum use a private key system that the user can create to send or receive money. Where Hyperledger Fabric uses a certification system to interact with the user and between each component.
Another way to explain the difference is private keys can be user-created therefore being decentralized whereas certifications are created by an admin, therefore, being centralized. In Hyperledger Fabric the admin is called the Certificate Authority (also a program).
The CA is responsible for issuing certifications to users or peers which can be used to interact with the peer, Orderder, channels, etc. and the last difference is that in Hyperledger Fabric you cannot change the key-value within a block multiple times.
For example Bitcoin or Ethereum, if you want to change a block’s value from 100 to 200, You just add 100 to the block. Then if you want to change it to 300, you add another 100. A block’s value can change multiple times with Bitcoin or Ethereum. In Hyperledger Fabric this is not as simple as it sounds. It is not that simple to add values to increment a block’s value. This is due to how Hyperledger Fabric’s architecture is built.
Because of this architectural difference, you need to think differently about how you would code your chaincode.
I will try to explain it in a simple way why Fabric was built this way.
Hyperledger Fabric has 3 major components the Peer, the Orderder and the App (user)The Peer stores the ledger (the blockchain) and World-state. The Peer also simulates transactions.
The Orderer takes all the transactions and creates the block only. It does not simulate transactions.
Again, the Peer simulates the transactions and the Orderer creates the blocks.
The App will be the end-user.
When a User creates a transaction, that transaction gets sent to the peers. When a User sends a transaction to the peer, the transaction does not become a block just yet.
The Peers will simulate the transaction to see if it is valid. Once valid the peers will confirm the validity of the transaction to the User. This is Hyperledger Fabric’s agreement system to simply put if 2 out of 3 agrees the transaction then the transaction is considered valid. 1. The User creates a transaction and asks the Peers for permission to give it to the Orderer 2.
If 2 out of 3 Peers agree, then the User is allowed to send the transaction to the Orderer 3. Then the User sends the transaction to the Orderer and asks it to be put into a block.
The Orderer collects all the User-generated transactions and checks if they are really endorsed by the Peers.
Again, the Orderer only checks for Peer endorsement and does not check the workings of the smart contract. Once the Orderer is happy with the transactions it will create a block and send the block to the Peers. The Peer will receive the block from the Orderer and create the chain while updating it’s world-state. This is the basics of Fabric’s transaction flow.
Again, the User creates the transaction and asks for the Peers’ endorsement. This is called the endorsement policy. The policy can be 2 out of 3, 2 out of 4 or even 1 out of 3 to agree on a transaction. The User then gathers the endorsed transactions and creates a Proposal Package which is then sent to the Orderer. The Orderer then checks the Peers signatures and creates the block which is then sent to the Peers.
With Bitcoin or Ethereum, all this process is done by one program (one node). Whereas in Fabric the Peer, the Orderer are separate programs.
Let’s take a look into the Ledger which has two main components.
The actual blockchain and the World State.
World State is the current status of the chain. Only the Peer has the World State of the chain. Both the Orderer and the Peer hold the blockchain but only the Peer uses the blockchain. The Orderer only holds the blockchain for reference purposes.
Endorsement, as mentioned before Fabric uses an endorsement policy to validate transactions. It’s a voting system where for example 2 out of 3 needs to agree on a transaction, also known as Byzantine fault tolerance
This is how Fabric essentially works under the hood 🙂
