Hyperledger Fabric – Transaction Flow in Block Chain

Hyperledger Fabric V1 Architecture

Membership Services is going to be providing the notion of identity for the users who are going to be transacting on the block chain. So, this identity is going to be a digital certificate and users are going to be using this digital certificate to signed that transaction and submit them to the block chain and the benefit of signing this transaction is 2 foot one they authenticate with the block chain that they are a legitimate user and 2 it also ensures that they get the right access privileges on the block chain for the transaction they are performing .

Like i mentioned we do have notions of access control, so certain users are allowed to perform certain transactions and if you do not have the right access then your transaction will get rejected. So your certificate is going to have all that information about you what privileges you can have what attributes you have and we use that to transact on the block chain.

Now how do the certificate where do the certificate come from you, it comes from traditional certificate party right.

Fabric implements a certificate authority so this is the fabric CA and this certificate authority is optional. So, it only all does is issued the certificate, so you go to the certificate authority and say ok I an Ntirawen I would give me a certificate and it will then issue this certificate saying this public key belongs to Ntirawen , Ntirawen has these following attributes and so on .So, that is the role of the certificate authority.

Nodes and Roles

Committing Peer : Maintains ledger and state. Commits transactions. May hold smart contract (chaincode).

Endorsing Peer : Specialized committing peer that receives a transaction proposal for endorsement, responds granting or denying endorsement. Must hold smart contract.

Ordering Node : Approves the inclusion of transaction blocks into the ledger and communicates with committing and endorsing peer nodes. Does not hold smart contract. Does not hold ledger.

Transaction Flow

Consensus is achieved using the following transaction flow :

Steps 1/7 : Propose Transaction

Application proposes transaction

Endorsement policy :

"E0, E1 and E2 must sign"
(P3, P4 are not part of the policy)

Client application submits a transaction proposal for Smart Contract A. It must target the required peers {E0, E1, E2}

Key:

Step 2/7 : Execute Proposed Transaction

Endorsers Execute Proposals

E0, E1 & E2 will each execute the proposed transaction. None of these executions will update the ledger
Each execution will capture the set of Read and Written data, called RW sets, which will now flow in the fabric.
Transactions can be signed & encrypted

Step 3/7 : Proposal Response

Application receives responses

Read-Write sets are asynchronously returned to application
The RW sets are signed by each endorser, and also includes each record version number
(This information will be checked much later in the consensus process)

Key :

Step 4/7 : Order Transaction

Responses submitted for ordering

Application submits responses as a transaction to be ordered

Ordering happens across the fabric in parallel with transactions submitted by other applications.

Key :

Step 5/7 : Deliver Transaction

Orderer delivers to committing peers

Ordering service collects transactions into proposed blocks for distribution to committing peers. Peers can deliver to other peers in a hierarchy (not shown) Different ordering algorithms available: