Blockchain – Transaction Journey into A Hyperledger Blockchain Network

This blog represents details on key types of components or building blocks of Hyperledger Blockchain Network and discusses details on the journey of transaction in the blockchain network. It also highlights the steps including diagrams on workflow/process flow related with endorse and commit transactions.

Types of Hyperledger Components

There are three types of components, each of them performing different functions, in Hyperledger. Node joining the Hyperledger Blockchain network will be free to take up one or more functions. Following represents these three classes of components:

• Endorsers: Nodes with “Endorser” functionality will simulate and sign or reject the transactions. A peer can be potentially an endorser for the chaincodes deployed to it.
• Consenters: Consenters, also termed as “Ordering service“, will run the PBFT (Practical Byzantine Fault Tolerance) consensus algorithm on the transactions and order these transactions appropriately in a block.
• Committers: Committer nodes receive the block of transactions from the ordering service (consenters) and write them to the ledger.

A node can join the Blockchain network as performing one or more functionality related with endorsers, ordering service (consenters) and committers.

Journey of Transaction in Hyperledger Blockchain Network

The following represents the journey of transaction in the Hyperledger Blockchain network:

• Application/client app uses the SDK to submit the endorsement proposal for a given transaction to one or more Endorser peer nodes. Note that chaincode get executed via endorsement proposal. Application/client app can send endorsement proposals to multiple endorsers to get “strong read” endorsement.
• Endorser node simulates the transaction, signs or rejects it and return the response to the client app
• Client app collects the endorsements and send the endorsed transactions to the Consenter node (ordering service)
• Consenter (ordering service) run the consensus algorithm on the transaction and appropriately create a block of one or more transactions.
• Consenter sends the block of transactions to peer nodes on the chain.
• Peer nodes including committer nodes write the block of transaction to the ledger.

Endorse Transactions

The following diagram represents the journey of transaction through Endorser:

In above diagram, make a note of some of the following:

• An endorser node comprise of ESCC (endorser system chain code). ESCC endorses a transaction. An ESCC can be associated with one or more chaincode. Peer calls ESCC with Proposal and read-write set. ESCC implements endorsement policy based on the input and returns EndorsedResult.
• Client SDK sends proposal to peer node(s)
• Peer node verifies the client signature.
• Peer node then simulate and collect read/write set
• Peer node then invokes ESCC with proposal and read/write set
• ESCC endorses or rejects the proposal.
• Peer node collects the endorsement (hash of proposal, read-write set, signature)
• Peer node returns the proposal response.
• Client SDK checks the endorsement policy and create a transaction appropriately.
• Client SDK sends the transaction (proposal response, endorsements) to the peer node
• Peer node relays the transaction to ordering service (consensus service)

Commit Transactions

The following diagram represents the sequence diagram for committer committing a block of transactions to the ledger.

In above diagram, make a note of some of the following:

• Committer comprise of a VSCC (Validator system chain code); VSCC validates the transactions according to endorsement policy.
• Committing a transaction involves validating each transaction read/write sets and endorsements
• Committer uses VSCC to validate the block/batch of transactions and commit the block to the ledger.