With the advent of technologies, the global market is equipped with ledgers that organizations and individuals alike must trust. In the previous blog, we widely discussed on the potentialities and functionalities of Hyperledger and their key frameworks. We saw Hyperledger is incubating and promoting enterprise-grade, open source business blockchain software, on top of which anyone can set up apps to meet cross-industry needs. For more assistance, surf Hyperledger: A revolutionary mission of Linux foundation.
Hyperledger Fabric is a platform for distributed ledger solutions designed to support pluggable implementations of different components and accommodate the complexity and intricacies that exist across the economic ecosystem. For more information glance An Introduction to Hyperledger Fabric.
This particular blog trolls you down much deeper into the Hyperledger fabric terminologies and their key functions. Here are the terminology listings explained below.
- State
- Transactions
- Ledger
- NODES
- Peer
- Ordering Service API
- Endorsement Policy
- Writers policy
State
Any real-world assets can be modeled using assets in the fabric. They are defined as a collection of key-value pair. The term ‘state’ represents the current key-value pair. And a change in the state is recorded as a transaction in the channel ledger. The state is maintained only by peer nodes and it is modeled as an element of mapping from the set of keys (K) to the set of V x N. It is described below.
K -> (V X N)
Where,
K => set of keys
V => set of values
N => an infinite ordered set of version numbers
A state is represented as
S( k )= (v, ver)
Generally,
v is denoted by S( k ).value &
ver by S( k ).version
These entries are manipulated by the chaincodes (or the applications) running on the blockchain through ‘put’ and ‘get’ operations.
Put(k,v) takes the blockchain state S and changes it to a new state S’ such that
S’( k)=( v, next( S( k ).version ))
Get method returns S( k )
The state change of the assets are recorded as transactions on a channel ledger
Let’s take an example to understand the concept
- Consider an asset ‘price’ which represent the price of 1 kg of apple.
- Here, key is ‘price’ and a different value can be set to this key ( i.e. prices of the apple)
For each changed value, we assign version number.
Suppose the current price of an apple is 50/kg. Then the current state is described as
S( ‘price’ )= (50,1)
Here, 50 is the value and 1 is the version number
If we change the price to 60/kg, then let us say an operation transaction is made. We can update the new value using put operation.
put( ‘price’, 60)
The operation changes the state of the asset as
S’( ‘price’ ) = ( 60,2)
If we call get an operation at this stage, it will output the above state
|
Transactions
As I explained earlier a transaction is a change in the state of a digital asset. Basically, there are two types of transactions in hyperledger.
1. Deploy transaction
Deploy transaction create a new chaincode by taking a program as the parameter. And it will install the chaincode on the fabric.
2. Invoke transactions
Invoke transaction is applied in the case of a previously deployed chaincode. It can invoke the ‘functions’ of a chaincode that is deployed on Blockchain. A successful invoke transaction executes the functions of a chaincode to perform some operations in Blockchain.
Ledger
So we know the State and Transaction, Ledger is closely associated with these two. The ledger records all transactions in the Blockchain channel. Or it is a sequential, immutable record of all transactions. The ledger contains both valid and invalid transactions. And as we explained earlier each transaction creates a new ‘Key’ value pair for an asset and it is stored in the ledger. An important thing in the fabric is that there will be one ledger per channel. And all the nodes in the channel keeps a copy of that ledger.
In the ledger, transactions are ordered into blocks. Blocks are constructed by the ordering service as a totally ordered hash chain of blocks. In the context of an ordered, Ledger is referred to as an Orderer Ledger. And in the context of a peer, the ledger is referred to as Peer Ledger. Peer Ledger differs from the Order Ledger in a way that peers locally maintain a bitmask which distinguishes valid transactions from invalid ones while Orderer ledger does not.
Nodes
Nodes are the communication entities of the blockchain
There are 3 types of nodes,
1. Client or submitting-client:
Let us say it is the end user of the fabric. A client must connect to a peer for communicating with the Blockchain. The client can communicate both with Peers and Orderers.
2. Peer:
Peer is basically a node that commits the transactions and maintains the state of the ledger. Peer keeps the copy of the ledger and they can take the role of an ‘Endorser’ also.
3. Ordering-service-node or order:
Orderer is a node that runs the communication service. The communication service provides a shared communication channel to clients and peers. The client can connect to single or multiple communication channels and communicate with other clients or peers.
Ordering Service API
Peers are connected to the communication channel through ordering service API. The Ordering service API has the following basic methods.
broadcast(blob): A client calls this method to broadcast a message over the channel
deliver(seqno, prevhash, blob): The ordering service calls this on the peer to deliver the message (blob) with the sequence number (seqno) and the hash of the most recently delivered blob (prevhash)
As an effective communication strategy, most of the time, the ordering service will group the ‘blobs’ and output the blocks within a single deliver event instead of outputting individual transactions.
Ordering service provides a Safe (consistency guarantees), Live (delivery guarantee) communication mechanism.
Endorsement Policy
Endorsement policy specifies the conditions to endorse a transaction. All the peers will have a pre-specified set of endorsement policies. The policy is specified by the deploy transaction at the time of installation of a specific chaincode. The policy can be parametrized and a transaction become valid only after it passed the endorsement conditions.
Writers policy
It is the channel specification rules for clients. The policy specifies which user is allowed to submit a transaction to a particular communication channel. It is defined at the time of channel creation.