Teach yourself - Hyperledger Fabric : Hour 02:00 — Architecture Deep Dive

Hyperledger Feb 20, 2019 0 1061 Add to Reading List

Hello, thanks for taking your time to read this series. I believe, you have started from Hour 00:00, if not please do that before you proceed further.

Any applications you take, understanding core architecture is very important before you start coding. Since without knowing how basic works, you will end up loosing plenty of time in research & debugging. So in this article, we will focus on Hyperledger Fabric Architecture Principle!..

Basic Building Blocks of Hyperledger Fabrics are the following

System Architecture
Transaction Workflow
Endorsement Policies

Understanding these three, will give you a better idea how Fabric works. In Blockchain, multiple nodes speak to each other. Nodes are nothing but a system or instance or virtual machine.

Readers : So does that mean, should blockchain always execute in multiple machines?

Me : Not really, you can also setup blockchain in single nodes and test it out. but for production, it is not recommended to use single node systems, since single point of failure is very high.

System Architecture

Nodes

Nodes in Hyperledger can be classified into three basically,

Client — Represents a application which helps end user to submit the transactions
Peer — is of two types, “Committing Peers”, “Endorsing Peers”.
Ordering Service — It is very important component in node structure, it handles the communication broadcast between peers & client. In test mode, you can use “Solo” orderer whereas for production system always go with “Kafka”.

Blockchain DataStructure:

There are two elements(State, Ledger) , we call it as Blockchain DataStructure

State

The world state represents the current values of all ledger states. It’s extremely useful because programs usually need the current value of a ledger state and that’s always easily available. You do not need to traverse the entire blockchain to calculate the current value of any ledger state — you just get it directly from the world state.
State is maintained at “Peers”

Ledger

It contains all the transactions that are successful in state changes.
Ledger is maintained at “Peers” and optionally in “Orderers”

So mostly, when we want to retrieve the current status about a particular asset, then you always get that from “world state”, whereas if you want to get the history of transactions including current value you will end up querying the ledger.

Transaction WorkFlow

Ok, Let’s take this example, consider you are a famous magician & you want to perform a show in secure building. Mostly, as a visitor you should have your valid “ID” card right?, then you have to show that to Security @ “Security” gate. Once your ID gets validated then you will be allowed to enter into the building, but you have to get permission from management to perform roadshow. Once you get proper acknowledgement, then you will be allowed to perform the same, else you will be thrown out.

So the key part here is, ID.. In Permissioned network such as Hyperledger, without proper certificates user cannot enter into the network. These certificates we call it as ID and this certificate issuance will be handled by Membership Service Provider(in short — MSP)

Few components to understand here

Endorsing Peer
Ordering Service
Committing Peer
Client(Application)
Certificate Authority — to issue Token

Here, in hyperledger every participant should have valid token(ID — issued by MSP), through which they can access the network. So when a participant initiate the transactions(roadshow)proposal , this will be first validated by “Endorsing Peer”(Security), who will check whether participant has valid ID or not, will also check the “Endorsement” policy, whether this participant can really perform this transaction or not, those kind of checks will be performed here. After you pass this check, the transaction simulation will happen, here what would happen if your transaction executed, that will be the result. Here most important thing you should note, transaction simulation will not change the state of the data in the ledger. It will simply show the simulation results, this will be then cascaded back to the client with “Endorsing Peer” signature.

Client(Application) will again trigger the same with “transaction simulation result”, this time “Ordering Service” will receive these transactions along with other transaction in the network in chronological order & creates a transaction sequence, this will be then cascaded to “Committing peer”, who actually does the data insertion in Ledger & change the state accordingly.

So the committing peer is very important and it holds the “Ledger”. When you have multi-node system, you have to declare which node is endorser & which one is committing peer. Endorsing Peer can also act as Committing Peer, but Committing Peer cannot endorse! — KEEP IN MIND!

Reader: So how do I determine which node is endorser or committing peer?, do we have any configurable options?

Me: to extent you are right, all peers who have joined specific channel can act as committing peer. And those peers, got “Chaincode — smart contract” installed, can act as “endorsing peer”. you can also set it up in yaml file endorsingPeer=true— We will talk more about “Channel”, “Chaincode”, “Installation” etc in our upcoming series, but for now keep this tips in mind.

Here all the business logic will be written in programming languages such as “GO”, “Python”, “Java” and it is called “ChainCode” — SMART CONTRACT

So this is the flow in short…

i) Client initiates a transaction === By Application(Client)

ii) Endorsing peers verify signature & execute the transaction === By Endorsing Peers

iii) Proposal responses are inspected === By Application(Client)

iv) Client assembles endorsements into a transaction === By Application(Client) and it send this to “Ordering Service”

v) Transaction is validated and committed === By “Ordering Service” and it send this to “Committing Peer”

vi) Ledger updated === By “Committing Peer”

NOTE: Only for “Write” transactions the above flow executes fully, where as for “Query/Read” ledger, it stops at Step iii). Since once the data has been queried from the ledger, the application/client will consider the task is done.

For more details please check TxFlow

Endorsement Policies

To guarantee blockchain and security properties, the set of endorsement policies should be a set of proven policies with limited set of functions in order to ensure bounded execution time (termination), determinism, performance and security guarantees.

Hyperledger Fabric uses endorsement policies to define which peers should execute which transactions.

Example endorsement policies might be:

Peers A, B, C, and F must all endorse transactions of type T
A majority of peers in the channel must endorse transactions of type U
At least 3 peers of A, B, C, D, E, F, G must endorse transactions of type V

Check this article for more about “Endorsement Poilcy” by Kynan Rilee

So we have covered the basics building blocks of Hyperledger, as a developer/programmer/manager you must understand the transaction flow how it works in addition to blockchain datastructures. So re-study this article until you get clear picture of how the data flows.