Ledger's synchronicity and consistence is maintained by the orderers. Consensus is met, before an update to the ledger is approved. Ledger is updated only upon approval by all the peers. This is part of transaction flow; and will be covered in detail in this section.

The following diagram shows the transaction flow :

The following are the stages of a transaction flow:

Proposal: The client application sends ledger-update-transaction to the peers on the channel. Referring to the preceding diagram, the client application, O1App1, sends (proposes) a transaction on Channel-C1. When the chaincode is installed and initiated, an endorsement policy is added to the channel configuration (CCon1). The endorsement policy for the channel (C1) defines that organization O1, and organization O2 must approve the transaction. Hence, when a transaction is proposed, it goes to the endorsing peers on channel (C1), which belongs to organization O1 and organization O2. Referring to the diagram, it goes to P1 and P2, as the peers are also endorsing peers for organizations O1 and O2.

Technically speaking, the application uses APIs, which result in the transaction proposal. The transaction proposal is akin to a request to execute the chaincode's functions so that ledger data can be read/updated. Here, applications use an SDK (Node, Python, or Java) and one of the APIs to propose such transactions. The SDK will take care of packaging the transaction proposal in an architecture format (such as a protocol buffer over gRPC) and applies a user's private keys to add a digital signature to the transaction proposal.

Endorsement (simulating the proposal): The client application sends a ledger-update-transaction to the peers on the channel. Such peers are the endorsing peers. Note that a peer can be an endorser as well as a committer. At this stage, orderers' nodes are not consulted and are not involved. The following are the steps involved:

1. The application generates a transaction proposal and sends it to the endorsing peers.
2. The channel will consult the endorsement policy to identify the endorsing peers and then route that transaction proposal request to the chosen endorsing peers:

I have used the word chosen, since chaincode's endorsement policy will dictate whether all endorsing peers on a channel need to endorse a transaction proposal request.

3. Each endorsing peer has a local copy of the ledger and chaincode. They will execute the chaincode based on the transaction proposal request, and will generate a transaction proposal response.
4. Each endorsing peer verifies that the transaction proposal is well formed and has not been submitted in the past.
5. The submitter's signature is verified by the MSP and authorizations are checked to ensure that the client application is authorized to perform a transaction (read/write) on the channel. Policies such as the write policy are defined during channel creation and help to determine a user's entitlement to perform/submit transactions to a channel.
6. Each endorser will generate a transaction proposal response. They will also sign the transaction proposal response with their private key (signing the response digitally). At this stage, there is no update to the ledger.
7. Each endorser will then send the proposal response to the application. For a transaction, the application will receive multiple proposal responses.
8. There may be inconsistency in the transaction proposal response sent to the application by various chosen endorsing peers, perhaps because different endorsing peers generated responses at different times, and the ledger state was different during those instances. In this case, the application can do the following:
   • Accept the responses to allow the transaction process to proceed to further steps
   • Reject the response and terminate the transaction process
   • Send another request for a more recent transaction proposal response

Technically, each endorser will use the transaction proposal inputs as input arguments to the chaincode. Each endorser takes the transaction proposal, and executes the proposed transaction using the chaincode present. These chaincode executions will not result in ledger updates. They just simulate the transaction. The endorser, while simulating the transaction, will get a current list of keys and values (the current state of the ledger) and a simulated list of keys and values (the to-be state of the ledger), which will be written to the ledger. Hence, there are two sets of keys and values (read and write sets). These sets of values, along with the endorsing peer's signatures, are added to the proposal response sent to the SDK, which will further parse the payload for the applications to consume.

Packaging the proposal response: The client application will receive endorsements from all the endorsers and, upon accepting the transaction proposal response, will send it to the orderer's nodes:

• From an orderer's node perspective, many applications will send it their respective transaction proposal responses.
• Orderers will sequence and package those transactions in blocks. It is these blocks that are the blocks in blockchain:
  • Orderers will wait for a certain amount of time to package all transactions within that time frame into a block, or, if the desired size of the block is satisfied, then the block will be ready for distribution.
• Orderers also don't have a local copy of the chaincode and, hence, they don't refer to chaincode (being judgmental) in defining blocks.
• Note: In HLF, the ordering of transactions is not important. However, whatever sequence they are added to the block in, they will be executed in that order.
• Note: A transaction in HLF is only present in one block, and not in multiple blocks. This means a transaction's position in the block is final and is assured at this stage.

Technically, each endorser will return its signed endorsement back to the client (through the SDK). We know that the endorser has obtained read and write set(s). These read and write sets are part of the signed proposal.

Verify and send for ordering: The client application will again participate in the transaction flow and will perform two activities—verify the proposal response and, for a ledger-update-transaction, the client will connect with an ordering service for further processing.

Verify the proposal response: The client application will verify the proposal response:

• If it was just a ledger-query-transaction, the client application will verify the proposal response and will collect its responses. It will not send it on to ordering services.
• If it is a ledger-update-transaction, then the application will verify whether all the endorsing peers, as specified in the endorsing policy, have endorsed the transaction, and whether they are all valid. The sequence is as follows:
  
  • The client application will first verify the endorsing peer signatures
  • Then, it compares the proposal responses from each of the endorsing peers to check whether the proposal responses are the same

Send for ordering: At this stage, the client application sends the transaction message as a bundle (transaction proposal and a response) to the ordering service. This transaction message contains the following:

1. The two sets of keys and values (read and write sets)
2. The signatures of the endorsing peers
3. The channel ID for which the transaction is meant to be committed

Referring to the preceding diagram, O5 and O1 are orderers, and they are configured for Channel-C1. Hence, transaction messages meant for C1 will be broadcast to the O5 and O1 orderers. They will sequence the transaction message, order them, and create blocks of those transactions.

Technically, the ordering service receives such transaction messages from all the channels to which it is connected and configured. The ordering service will sequence and order these transactions (chronologically by channel) and will create transaction blocks (per channel). Orderers will never create a transaction, and will ensure that they offer guaranteed delivery. The orderer's class offers capabilities for the client applications to interact with the orderer's nodes. The orderer's nodes have two exposed APIs—broadcast () and deliver (), and its bidirectional streaming API with a gRPC streaming connection between the client application and orderers. The broadcast() API enables clients to send transaction messages to orderers, and the deliver() API allows clients/consumers to check with orderers regarding channel information and channel configurations.

Distribution: At this stage of the transaction process, orderers will distribute the block to peers. Peers are connected to orderers in the blockchain network. Orderers will distribute the block to each connected peer via P2P communication based on gossip protocol.

Gossip protocol: I would like to talk a little bit about the gossip protocol here, as distribution is the stage where the gossip protocol is used. Orderers need to distribute the transaction message to all peers. However, it is a burden to orderers and it sounds almost impossible to reach all the peers when a network is huge in size. The HLF framework has a solution for this. Orderers do not deliver messages to each peer. Orderers only deliver messages to peers that are configured as leader peers. For each organization, on a channel, there is a leader peer identified. Those leader peers will distribute those messages to other peers and suchlike. Peers then forward these messages to a randomly selected number of peers. This random number of peers is predetermined, and this forwarding continues until the message reaches all the peers. This entire process is defined as a broadcast, and the broadcast process relies on the gossip protocol to distribute transaction messages.

Peer bootstrapping: We just read that peers send messages to a predefined or predetermined list of peers. How does this determination happen? This happens via peer bootstrapping (also known as bootstrapping). When the blockchain network is established, each peer gets a bootstrap set of peers. After that, peers check for the alive status of the peer. If the bootstrap peer is dead, it will mark it as dead. However, it will check periodically whether it's alive/dead. If a peer is dead, and later becomes alive, it will have missed messages from the broadcast process. Hence, to get up to date, that peer will pull information, such as membership data (the alive and dead status of peers) and ledger data (blocks of transactions).

Validation and tagging: At this stage of the transaction process, peers will receive blocks from the orderers. They will validate them and tag them as valid or invalid:

• The peer will pick and process transactions from the block. The order of picking and executing transactions is the same order in which transactions are sequenced by the orderers. Peers do not execute chaincode for this step. Chaincode is only executed at the endorsement stage, which corroborates the fact that chaincode should only exist on endorsing nodes.
• When processing a transaction, each peer will verify that the transaction was endorsed according to the endorsement policy defined in the chaincode, which actually generated this transaction. This ensures that all the organizations that are meant to endorse a transaction have endorsed it, and have generated the same output.
• If it is verified, this means that it was endorsed correctly, and then the following happens:
  • The peer performs a consistency check. This check is to verify whether the current ledger state is compatible with the state of the ledger when the peer generated the transaction proposal update. If it is consistent, then the transaction is marked as valid. If it is not consistent, then it is not applied and the transaction is marked invalid and defined as a failed transaction. For example, a digital asset against which a transaction was proposed and a proposal response was generated was updated by another transaction. In this case, the state of the ledger at proposal response time and consistency time are different and, hence, it cannot be applied and is therefore marked as failed.
  • Once a peer validates all the transactions in the block, then all the transactions in the block that are not failed are committed to the ledger:
    • Failed transactions are not committed to the ledger, yet they are considered successful and are available for audit.

Technically, each peer will append the block to the chain of the channel, and only valid transactions are appended to the peer's local copy of the ledger (it's an append to the current world state).

Notifications: When a block gets committed to the ledger, peer, and chaincode, it generates the following events:

• The peers and chaincode generate the following events:
  • A peer generates: A block event and a transaction event. A block event contains the entire block content, while a transaction event highlights whether a transaction was validated or invalidated (marked as failed).
  • Chaincode generates: A chaincode event.
• Applications can subscribe to interesting events and can receive notifications. These notifications help applications to know about the final stage of the transaction.

The transaction flow defined previously clearly displays various participants involved in the transaction, from client applications to endorsers, orderers, committers, and leaders. This section also clearly highlights the powerful role of orderers in the blockchain network. Each peer validates the transaction and follows the sequence and order defined in the block by the orderers. Hence, it is the orderers that ensure consistency in the blockchain network. In addition, it ensures that the position of the transaction in the block never gets changed and, hence, induces immutability to the ledger in the blockchain network. If you re-read the transaction process defined previously, it is evident that all peers agree about the transactions and their contents. Orderers mediate this agreement process, which is called a consensus.