How to do it...

In this section, we will review how a transaction is created on the Hyperledger Fabric network:

1. The Client Application submits a transaction proposal for smart contact A to the network. The endorsement policy requires three endorsers—E0, E1, and E2—to sign together.
2. The endorsers execute proposed transactions. At this time, three endorsers—E0, E1, E2—will each execute the proposed transaction independently. None of these executions will update the ledger. Each execution will capture the set of read and written (RW) data, which will now flow in the fabric network. All transactions should be signed and encrypted.
3. RW sets are asynchronously returned to the client application with a transaction proposal. The RW sets are signed by each endorser and will be processed later.
4. All transactions that returned from the Fabric network are submitted for ordering. The application can submit responses as a transaction to be ordered, and ordering happens across the Fabric in parallel with transactions submitted by other applications.
5.  Ordering Service collects transactions into proposed blocks for distribution to committing peers. This proposed blocks can then  be deliver to other peers in a hierarchy. There are two ordering algorithms available: SOLO (single node for development) and Kafka (crash-fault-tolerance for production). In the production system, it is suggested to use Kafka.
6. Committing peers validate the transactions. All committing peers validate against the endorsement policy and check whether RW sets are still valid for the current world state. World state is not update if there is invalid transctions but are retained on the ledger while validated transactions are applied to the world state.
7. Client applications can register to be notified on the status of transactions, to find out whether they succeed or fail, and when blocks are added to the ledger. Client applications will be notified by each peer to which they are independently connected.