github.com/darrenli6/fabric-sdk-example@v0.0.0-20220109053535-94b13b56df8c/docs/source/txflow.rst (about) 1 Transaction Flow 2 ================ 3 4 This document outlines the transactional mechanics that take place during a standard asset 5 exchange. The scenario includes two clients, A and B, who are buying and selling 6 radishes. They each have a peer on the network through which they send their 7 transactions and interact with the ledger. 8 9 .. image:: images/step0.png 10 11 **Assumptions** 12 13 This flow assumes that a channel is set up and running. The application user 14 has registered and enrolled with the organization’s certificate authority (CA) 15 and received back necessary cryptographic material, which is used to authenticate 16 to the network. 17 18 The chaincode (containing a set of key value pairs representing the initial 19 state of the radish market) is installed on the peers and instantiated on the 20 channel. The chaincode contains logic defining a set of transaction 21 instructions and the agreed upon price for a radish. An endorsement policy has 22 also been set for this chaincode, stating that both ``peerA`` and ``peerB`` must endorse 23 any transaction. 24 25 .. image:: images/step1.png 26 27 1. **Client A initiates a transaction** 28 29 What's happening? - Client A is sending a request to purchase radishes. The 30 request targets ``peerA`` and ``peerB``, who are respectively representative of 31 Client A and Client B. The endorsement policy states that both peers must endorse 32 any transaction, therefore the request goes to ``peerA`` and ``peerB``. 33 34 Next, the transaction proposal is constructed. An application leveraging a supported 35 SDK (Node, Java, Python) utilizes one of the available API's which generates a 36 transaction proposal. The proposal is a request to invoke a chaincode function 37 so that data can be read and/or written to the ledger (i.e. write new key value 38 pairs for the assets). The SDK serves as a shim to package the transaction proposal 39 into the properly architected format (protocol buffer over gRPC) and takes the user’s 40 cryptographic credentials to produce a unique signature for this transaction proposal. 41 42 .. image:: images/step2.png 43 44 2. **Endorsing peers verify signature & execute the transaction** 45 46 The endorsing peers verify (1) that the transaction proposal is well formed, 47 (2) it has not been submitted already in the past (replay-attack protection), 48 (3) the signature is valid (using MSP), and (4) that the 49 submitter (Client A, in the example) is properly authorized to perform 50 the proposed operation on that channel (namely, each endorsing peer ensures that 51 the submitter satisfies the channel's *Writers* policy). 52 The endorsing peers take the transaction proposal inputs as 53 arguments to the invoked chaincode's function. The chaincode is then 54 executed against the current state database to produce transaction 55 results including a response value, read set, and write set. No updates are 56 made to the ledger at this point. The set of these values, along with the 57 endorsing peer’s signature is passed back as a “proposal response” to the SDK 58 which parses the payload for the application to consume. 59 60 *{The MSP is a peer component that allows them to verify 61 transaction requests arriving from clients and to sign transaction results(endorsements). 62 The Writing policy is defined at channel creation time, and determines 63 which user is entitled to submit a transaction to that channel.}* 64 65 66 .. image:: images/step3.png 67 68 3. **Proposal responses are inspected** 69 70 The application verifies the endorsing peer signatures and compares the proposal 71 responses to determine if the proposal responses are the same. If the chaincode only queried 72 the ledger, the application would inspect the query response and would typically not 73 submit the transaction to Ordering Service. If the client application intends to submit the 74 transaction to Ordering Service to update the ledger, the application determines if the specified 75 endorsement policy has been fulfilled before submitting (i.e. did peerA and peerB both endorse). 76 The architecture is such that even if an application chooses not to inspect responses or otherwise 77 forwards an unendorsed transaction, the endorsement policy will still be enforced by peers 78 and upheld at the commit validation phase. 79 80 .. image:: images/step4.png 81 82 4. **Client assembles endorsements into a transaction** 83 84 The application “broadcasts” the transaction proposal and response within a 85 “transaction message” to the Ordering Service. The transaction will contain the 86 read/write sets, the endorsing peers signatures and the Channel ID. The 87 Ordering Service does not need to inspect the entire content of a transaction in order to perform 88 its operation, it simply receives 89 transactions from all channels in the network, orders them chronologically by 90 channel, and creates blocks of transactions per channel. 91 92 .. image:: images/step5.png 93 94 5. **Transaction is validated and committed** 95 96 The blocks of transactions are “delivered” to all peers on the channel. The 97 transactions within the block are validated to ensure endorsement policy is 98 fulfilled and to ensure that there have been no changes to ledger state for read 99 set variables since the read set was generated by the transaction execution. 100 Transactions in the block are tagged as being valid or invalid. 101 102 .. image:: images/step6.png 103 104 6. **Ledger updated** 105 106 Each peer appends the block to the channel’s chain, and for each valid transaction 107 the write sets are committed to current state database. An event is emitted, to 108 notify the client application that the transaction (invocation) has been 109 immutably appended to the chain, as well as notification of whether the 110 transaction was validated or invalidated. 111 112 **Note**: See the :ref:`swimlane` diagram to better understand the server side flow and the 113 protobuffers. 114 115 .. Licensed under Creative Commons Attribution 4.0 International License 116 https://creativecommons.org/licenses/by/4.0/