This document provides an overview of how transactions are conducted in the Hyperledger Fabric architecture, emphasizing the construction of transaction proposals by clients. It outlines the process involving endorsers who validate proposals before responses are generated and submitted to an ordering service, which organizes transactions into blocks for updating the ledger. The overview highlights key components such as proposal verification, endorsement policies, and the final appending of transactions to the blockchain.

1. www.cybrosys.comwww.blockchainexpert.uk
Hyperledger Fabric Architecture

2. Introduction
If you are new to hyperledger Fabric, read our previous blogs on hyperledger fabric.
• Introduction to Fabric
• Basic Terminologies of Fabric.
In this blog, let us look how an actual transaction is done in fabric. It would be easy to understand it
as a working example. In fabric architecture, every node will have a corresponding ‘Peer’ in the
network

3. • Consider two clients ‘A’ and ‘B’ engaging in a transaction.
• Here, ‘A’ trying to send a request to ‘B’, so the client application of ‘A’ will construct a transaction proposal using
an available API.

4. • A transaction proposal is nothing but a request to invoke a chaincode function, which is
responsible for performing a proposed transaction in a ledger. Every proposal attach a unique
signature for that particular transaction before sending the proposal to endorsers. A transaction
must satisfy a set of endorsement policies before it is added to the ledger

5. • Now let us see the steps involved in the transaction.
• After constructing transaction proposal in a correct format, client app sends this to all endorsers.
Let Peer ‘ A’ and Peer ‘B’ be the endorsers.

6. • The endorsing peers A and B on receiving the transaction proposal will verify the
following:
Check whether the transaction proposal is well-formed
Verify that the proposal is not submitted earlier
Check whether the signature attached to the proposal is valid
Check whether the submitter (here Client A) is authenticated to perform the proposed
transaction
• If it follows conditions, then the endorsing peers will invoke the specified functions of
chaincode and perform it against the current state of the ledger.

7. • But the result of this transaction is not updated to the ledger at this stage, instead, it is sent back
to the client app of ‘A’ as ‘proposal response’.
• An endorser signature is attached with proposal response. This is to inform that who endorsed
that transaction.

8. • On receiving proposal response, the client app analyzes the following
Check whether the response from all endorser are received
• This is accomplished by checking the endorser signatures of each response.
Check whether the endorsement policy is fulfilled
Check whether the response from all endorsers is same

9. • If all the conditions are satisfied, then the client app submit the transaction to ordering service to
update the ledger.
• The ordering service doesn’t inspect transaction, instead, it simply receives transactions from all
channels in the network, orders them and creates blocks of transactions.

10. • Then the ordering service sends the block to all peers on the channel.
• Each peer appends the block to the Blockchain ledger copy.
• An event is emitted, to notify the client application that the transaction has been immutably appended to
the chain